【正文】 int amp。pt )。void Serialize(CArchiveamp。 ar)。bool IsIn( CPoint amp。pt )。bool IsOn( CPoint amp。pt )。bool IsOn(CConnectPoint *pt)。int GetAdjustPoint()。private:void AdjustStartAndEnd()。void AdjustFocusPoint()。private:int m_AdjustPoint。 體現(xiàn)訪問者模式：選擇處理類考慮到本代碼的可擴展性，增加了這個類。這樣用戶可以在我公司定制流程圖?？梢远ㄖ贫喾N菱形，多種長方形處理類的代碼。那么不論用戶想處理公豬母豬多少斤可以出圈，或者是阿爾法貝塔剪枝問題都是沒問題的。怎么實現(xiàn)的呢，我們提供了一個重要的接口，這個借口是個 Index，可以指示我下一個選項是誰，也就是我選擇誰，比如我固定選擇第一個，或者如果加法我選左邊，減法我選右邊，再或者我根據(jù)我接收到的消息來進行選擇。他可以很復(fù)雜，那么就需要多一些方法，也可以很簡單。 29 public:LozengeDeal(void)。~LozengeDeal(void)。virtual bool IsInputRight()。virtual bool IsOutputRight()。virtual int highlightIndex()。virtual void setM_text(CGraph * Graph)。private:int input,output。 作為圖元部分的調(diào)整節(jié)點單獨作為一個類由于考慮到所有的節(jié)點都需要用到這么一個類，正如老師所說，可以組合不要繼承，于是這個不應(yīng)該放到父類里面，因為從邏輯上來講，他是我的組成部分。很正確。public:CConnectPoint()。virtual ~CConnectPoint()。public:void Draw(CDC *pdc)。void SetPoint(CPoint amp。pt)。CPoint GetPoint()。bool IsOn(CPoint amp。pt)。void SetType(bool type)。void Serialize(CArchiveamp。 ar)。private:CPoint m_Point。bool m_type。 30 6 面向?qū)ο蠹夹g(shù)分析 軟件復(fù)用（兩個地方體現(xiàn)） 圖元基類 設(shè)置了一個圖元基類，能夠使得圖元繼承自這個父類，由于圖元的共有代碼很多，比如類型屬性，比如文本內(nèi)容屬性，以及很多其他的方法，比如 getset 方法，還有很多共有的接口，比如調(diào)整位置，比如畫出來等等。所以這個繼承很重要，增加了代碼復(fù)用，也是多態(tài)的體現(xiàn)，因為圖元類存儲后取出來會向上轉(zhuǎn)化成父類，這時用接口中的方法，那么就會根據(jù)子類的代碼來實現(xiàn)，是很好的多態(tài)體現(xiàn)。 節(jié)點類作為單獨的一個類，成為圖元的組成部分調(diào)節(jié)圖元的時候，在關(guān)鍵點會畫出來小方塊，不同的圖元有不同的小方塊，那么我們可以單獨把這個方塊歸為一類。圖元都含有這個部分，但是又不能作為父類被繼承，作為組合關(guān)系也比繼承要符合邏輯。所以把這個實體抽象成圖元的部分，會大大增加代碼復(fù)用。 多態(tài)性（兩個地方體現(xiàn)）我認為多態(tài)就有使得軟件復(fù)用比例提高的功能，但是由于其他的比如繼承也有軟件復(fù)用的功能，所以就分開寫了。 圖元基類事實上圖元基類就是憑借多態(tài)這個作用增加了他的代碼復(fù)用程度。用一些方法不是虛函數(shù)，這是他的一部分復(fù)用優(yōu)點，同時又有虛函數(shù)在不同的圖元當中的個性化，呢么這就是借助于多態(tài)實現(xiàn)了接口的復(fù)用。從 COrray 當中取出來的指針會被強轉(zhuǎn)成父類，其中的一些方法比如畫出來的 Draw 方法，就是接口，如果調(diào)用父類對象指針的 Draw 方法，會直接調(diào)用子類的 Draw 方法。那么這就是不同的對象會以不同的行為響應(yīng)同一個消息。類似的還有移動，還有放大縮小，都是借由一個通用的父類實現(xiàn)的。 訪問者模式這個如同上面的圖元基類一樣，也是借由接口體現(xiàn)了多態(tài)性。每個長方形（運行）以及菱形（判斷）都有個單獨的體現(xiàn)了訪問者模式的部分類。這個類對于長方形圖元來講封裝了如何處理數(shù)據(jù)，對于菱 31 形圖元來講封裝了映射表，也就是哪一個控制流是我要選擇的。那么當用戶添加了一個圖元，并且輸入了文字之后，他的處理類就可以根據(jù)該文字實例化，如果要在一個流程圖中添加多種選擇圖元那么就需要寫多個菱形處理類，根據(jù)接收的文本對接口（長方形的處理接口，菱形的映射表接口）進行不同的實例化，用戶不需要關(guān)心我要把消息給誰，因為給的都是接口。那么這就是不同的對象會以不同的行為響應(yīng)同一個消息，也就是多態(tài)性的體現(xiàn)。 良好的封裝性（兩個地方體現(xiàn)） 分工明確（三個）圖元的的編輯功能是通過 View 對象實例化了 Doc 對象，通過 Doc 對象調(diào)用管理類，管理類調(diào)用圖元類，圖元類如果有必要（比如調(diào)整大?。┱{(diào)用關(guān)節(jié)點類來實現(xiàn)的?？梢娝麄兊鸟詈闲砸呀?jīng)最低。圖元的增加是通過 View 對象實例化了 Doc 對象，通過 Doc 對象調(diào)用 Factory 里面的方法生成了一個圖元，獲得其地址，再傳遞給管理類，讓管理類把這個地址作為元素，增加到數(shù)組中。其實相當于通過 Doc 對象進行了管理類與工廠類的消息傳遞。流程圖處理，是通過 View 對象實例化了 Doc 對象，通過 Doc 對象調(diào)用了管理類，管理類調(diào)用圖元類，圖元類調(diào)用他的部分，也就是圖元處理類，進行數(shù)據(jù)流的選擇，以及數(shù)據(jù)的處理。高亮是通過菱形的選擇決定的，箭頭有是否高亮的標志位，在進行數(shù)據(jù)處理的過程中會設(shè)置，之后直接畫就可以了。實例化是各個圖元會把自己的數(shù)據(jù)實例化，它的組成部分關(guān)節(jié)點會把自己的數(shù)據(jù)實例化，這也是通過Doc 類調(diào)用管理類，管理類再去逐個調(diào)用圖元類實現(xiàn)的。這樣封裝，自己的數(shù)據(jù)自己管理，大大降低了耦合性。通過對象的通信來交流信息，是封裝好了之后協(xié)同工作的必要步驟。所以本設(shè)計具有良好的封裝性。 成員變量全部采用 private 屬性采用 private 屬性，需要在使用該對象的時候調(diào)用其提供的 getset 方法才能讀寫數(shù)據(jù)，強迫程序員思考，我這個屬性要不要被讀取，是在實例化的時候一次性賦值，還是可以被后來修改，這樣進一步降低了耦合性，也降低了出錯的幾率。 良好的可擴展性 應(yīng)用了 CObArray現(xiàn)有圖元組織在圖元管理類中，并且利用了 CObArray 來存儲其指針，可以安全地增刪改指針數(shù)組，增加了擴展性。也就是說，我們的圖元可以想加多少個就加多少個。 32 應(yīng)用了訪問者模式可以看出來，在菱形圖元，以及長方形圖元的實體里面，都包含了一個專門的處理對象，而且可以有很多種處理對象，用戶可以在我們這里定制流程圖，可以處理多種復(fù)雜的流程圖數(shù)據(jù)流高亮顯示，只要處理類寫好。 良好的可維護性可維護性包含了之前的可擴展性，由于可擴展性是我們一個突出的優(yōu)點，于是單獨開辟一個小節(jié)。這里的可維護性指的是本代碼的方法分得很細，所以如果出了問題很容易 debug。而且用了CObArray 模板，減少了數(shù)組問題。而且類名的可讀性高。但是由于沒有專門做測試，所以具體的數(shù)值不能給出。 良好的健壯性由于建立在 MFC 框架下，以及用了 CObArray 模板，相當于用了大量成熟代碼，健壯性高于自己寫。 采用了工廠模式創(chuàng)建圖元這個功能用到了工廠模式，因為點擊生成圖元，很容易想到工廠模式，事實上一開始沒有用，后來課上老師介紹了，我覺得這個創(chuàng)建可以單獨分出去作為工廠模式，這樣降低了耦合性，同時提高了可擴展性，比如用戶提出我還要加一種圖元，你們沒有的，那么如果有個單獨的工廠類，會更加清晰。 采用了訪問者模式（兩個）老師上課講到了這個訪問者模式，我覺得是我需要的，因為我的處理以及選擇部分的確是變化很多。一張流程圖可能有多種選擇菱形，比如母豬大于多少斤出圈，公豬大于多少斤出圈，小豬出生體重多少健康?；蛘呤羌訙p乘除，以及小于多少，循環(huán)自加一，都可以放到一個流程圖里面，面對這樣復(fù)雜的需求，就需要不斷根據(jù)用戶再圖元上的輸入更換圖元實體中關(guān)于選擇，關(guān)于處理的部分。所以我們有兩個訪問者模式的類。 能夠采用組合絕不用繼承事實上這里用的是聚合，不過只是對象指針與真正對象的區(qū)別，關(guān)系到我不要了需要釋放空間， 33 這一維護管理，以及生存周期，但是邏輯上來講，還是整體與部分。用了兩個整體與部分的關(guān)系，一個是關(guān)節(jié)點作為圖元的部分，一個是訪問者模式的處理類是圖元的部分。不能把這些放到父類中給圖元繼承，因為能用組合就可實現(xiàn)部分的功能，只需要這個功能的話，拿過來用就可以。繼承會帶來麻煩，使得代碼冗余。 呢么整體部分的關(guān)系主要體現(xiàn)在下面四點： 關(guān)節(jié)點對象是圖元對象部分 菱形處理對象是菱形對象的部分 長方形處理對象是長方形圖元對象的部分 圖元對象是圖元管理對象的部分7 總結(jié)提高 劉甜總結(jié) 體會收獲本項目雖然并不大，但是包含了很多的面向?qū)ο笤O(shè)計的內(nèi)容，所以能夠把課程中學習的部分應(yīng)用到實踐當中。第六節(jié)內(nèi)容是我寫的，可以看到我引用了很多上課的內(nèi)容，因為很明顯的體驗就是，應(yīng)用這些（繼承，組成，工程模式，訪問者模式等等）的確是解決了書中說的軟件危機，你把它模塊化之后，抽象各種關(guān)系，就可以把一件不能夠完成的軟件變得可能；或者是大大增加了工程效率，以及可維護性，可擴展性。感覺學有所用。以前覺得代碼能力重要，現(xiàn)在覺得更重要的是設(shè)計能力。 遇到的問題以及解決方案（3 個重要的） draw 函數(shù)下的斷點不好調(diào)試，因為基本上是彈出來，然后就進入 draw，后來我想了幾種方法：可以在前面的數(shù)據(jù)都輸入完畢，比如畫圖完了，在增加斷點；先保存圖元，調(diào)試的時候打開，再調(diào)試。因為在我的設(shè)計中，雖然增加了訪問者模式的菱形處理類，并且限制了輸入圖元以及輸出圖元，但是我覺得應(yīng)該增加一個箭頭的處理類，用來判斷連接的兩個圖元是否合法，比如從結(jié)束指向開始的肯定是不合法的。 34 我發(fā)現(xiàn) CObArray 是個很好的模板，所以我把圖元不加區(qū)分的線性存儲。但是實際上流程圖是一個有向圖，可以再箭頭實體類當中增加他的起點以及終點圖元，然后增加一個方法，在管理類中，功能是獲取我的下一個箭頭，并且要求指出要第幾個箭頭。因為有可能一個圖元有很多箭頭。這么做的原因是考慮到用戶畫圖過程中不可能是一個真的圖，他有可能就放幾個圖元他就保存了?；蛘叻艂€箭頭保存，如果是用圖來存肯定不可以存。 林菁通過這次課程設(shè)計，讓我更加深刻地理解了面向?qū)ο蟮乃枷?，以及補充了以往知識的疏漏。此次課設(shè)，是一個較綜合的作業(yè)，所以，我們采取了先寫文檔，后編碼的方法。首先，進行需求分析，這是一個十分重要的過程，只有弄清楚了到底需要做什么，后續(xù)的工作才能順利進行。在此階段，我們也遇到了各種各樣的問題，通過小組成員的討論和與老師的積極溝通，問題得以解決。此次課設(shè)歷時 3 個星期，雖然時間有限，但也從中學習了不少知識，對類的抽象、封裝、繼承、多態(tài)有了更進一步的了解，更加熟練地掌握了 UML 的靜態(tài)建模、動態(tài)建模，真正地體現(xiàn)了學以致用。此課設(shè)選用 MFC，是由于小組成員對此都有一定程度的了解，之前的作業(yè)基本也都是基于 MFC 完成的。在編碼階段，也遇到了各種問題，為如何實現(xiàn)某一功能小組成員意見不一致等，但都通過討論、評估一一解決。課程設(shè)計是培訓學生運用本專業(yè)所學的理論知識和專業(yè)知識來分析解決實際問題的重要教學環(huán)節(jié)，不僅需要扎實的理論基礎(chǔ)，還注重我們的動手實踐能力。此次課設(shè)讓我明白了，遇到不懂的地方要及時請教以及主動查閱資料，及時解決問題，避免問題越積越多；只有認真鉆研，動腦思考，動手實踐，問題才能迎刃而解。 董寧 本次課程設(shè)計，收獲很多。我認為這次面向?qū)ο笳n程設(shè)計中涉及到的類很多也很雜，編程最復(fù)雜的是如何有效的將類抽象出來，高效的抽象類可以減少大量時間，并增強程序的嚴密性，層次分明的繼承則可以增加代碼的重復(fù)利用率。在這個學期內(nèi)，我們接觸完了基本的 c++和面向?qū)ο笏枷?，但動手時才發(fā)現(xiàn)自己還是剛剛?cè)腴T而已，不管是 c++的基本語法，還是面向?qū)ο蟮囊恍┧枷耄祭斫獾姆浅２煌笍?，造成了程序設(shè)計過程中走了很多彎路，但是完成后發(fā)現(xiàn)這是一個非常好的學習經(jīng)歷，一學期的理論知識的積累加上每周的小作業(yè)為課程設(shè)計打下來良好的基礎(chǔ)，加上最后這個課程設(shè)計的鞏固，使得我們得以窺探到 c++的廣袤和面向?qū)ο缶幊痰牟┐缶?。在課程設(shè)計的過程中，通過小組成員的明確分工和默契配合，我明白了用例圖、時序圖、活動圖、狀態(tài)圖等各種 UML 類圖的畫法，以及設(shè)計過程中的動態(tài)建模和靜態(tài)建模。雖然程序已經(jīng) 35 完成，符合預(yù)期的要求，但是這個題目我們還可以增廣出更多有用的功能，但是由于時間所迫，我們沒有編寫，存在種種不足，還需我們繼續(xù)學習彌補。 小組得分95 分，每個小組成員的貢獻百分比：劉甜：40%林菁：30%董寧：30%