結對專案地鐵出行路線規劃程式（續）

一、結對程式設計情況簡介

1. 結對程式設計小夥伴：石浩然：陳彥吉：

2. 結對程式設計大致流程：**複審-**除錯-模組化-ui開發設計-異常處理-單元測試。**如下：

3. 結對程式設計優缺點

4. 小夥伴們的優缺點

（以下部分來自隊伍公共部分）

二、設計方法

當開發乙個完整的程式時，可將程式的每個組成部分封裝在乙個模組中，每個模組盡量少地對外展示模組內部的資料與對資料的處理，以此提高**的復用性、可維護性。減少外界可見的資訊，以保持模組的獨立性，以此降低耦合。

從具體實現來說，我們確保某些成員變數和功能為private，並盡可能保證高層類只會呼叫底層類中特定的幾個可供外界訪問函式，而將其他方法封裝在內部，限制了高層類對底層類的呼叫。

遺憾地是，我們這次在這方面做的並不好。類中大部分成員都是public型別。由於時間關係和**結構上的問題，我們也沒有進行大規模的修改，只是盡量改了一些部分。以後在這方面一定要努力。（回想起了oo課上教主強調的所有屬性都必須為private。。。）

據隊友收集到的資料，介面設計共有六大原則。分別如下：

1.單一職責原則：根據實際需求劃分職責，盡量做到職責單一。

2.黎克特制替換原則：所有引用基類的地方必須能透明地使用其子類的物件。

3.依賴倒置原則：高層模組不應依賴底層模組，兩者都應依賴其抽象。抽象不應該依賴細節，細節應該依賴抽象。

4.介面隔離原則：介面盡量小，不要建立大介面，同時介面中方法盡量少，將介面隔離起來，將整體框架進行有效劃分。

5.最少知識原則：跟information hiding有異曲同工之妙，此原則的使用可以降低程式耦合。

6.開閉原則：乙個軟體實體如類、模組和函式應該對擴充套件開放，對修改關閉，程式設計前對不同的模組確立明確的邏輯分工，為變化預留位置。

上面這些原則好像已經把如何利用講的很清除了，我覺得實際應用中，第一條單一職責可以為模組化提供便利，然後黎克特制替換原則保證了繼承時的正確性，第四條則對我們的設計能力和程式設計能力提出了很高的要求，重點還是以後要多注意這些原則，多用才能會用。

盡可能全面地把握耦合度的高低，平衡好耦合和內聚程度，以確保可讀性、服用性、可維護性的提公升。不可一味強調低耦合，例如程式中發生變更概率很小的地方，不宜強行低耦合。還有程式中一些為大函式服務的小函式，小函式本身是依附大函式存在的，本身不會和其他模組建立過多的依賴關係，此時在耦合度上最好也做相應折衷。

三、design by contract與code contract

契約式程式設計：design by contract把類與被呼叫類之間的關係看作契約，規定了雙方的權力與義務，這一方法被認為是構建oo軟體系統方法的核心。

另外，我們通過一些知乎回答了解到的契約式設計：

1.目的：在設計程式時明確規定乙個模組單元在呼叫前後應當處於何種狀態，屬於一種設計風格或是語法規範。

2.思路：強調前置條件、後置條件和不變式，當違反這些操作時程式會丟擲異常。

3.優點是：契約式程式設計使**標準化、規範化，提高了程式工程化程度。同時，對於測試者，在我們這次作業中，我們通過在不滿足前置條件的情況下丟擲異常，便於測試者測試。

四、unit test

五、uml圖

六、演算法

程式中涉及上一次地鐵功能的演算法來自石浩然同學，他的演算法核心是只考慮換乘站，這樣就只有四十多個點，然後做各種dijkstra或者bfs效率就都很高，至於剩下的再進行處理就好。

程式實現了第一次中的-b、-c和-a功能，其中-a功能在ui中執行的同時，前台還可以完成-b和-c功能的查詢。這裡是運用了多執行緒處理。

程式ui我們是做了兩次，第一次是用winform做的，由於我們都是第一次寫ui，介面做的比較簡陋。功能基本完成後，又用wpf重新做了一次（這裡石浩然同學是主力），比之前winform漂亮很多。這裡附上幾張截圖。

結對專案 地鐵出行路線規劃程式（續）