軟件構造Lab3+心得

實驗要求:
在這次實驗中,要求我們面向可維護性和可擴展性編程,面向至少三個有一定相似程度但又不完全相同的應用設計一套通用的ADT,完成幾個不同場景的應用。
個人心得:
1.從哪下手???
在實驗指導書上,我覺得給了我們一些之後面向這種抽象程度比較高的ADT的設計的一些啓發,我把這種方法叫做維度拆分。具體說來就是我們需要對各個應用場景做分析,可以這樣去考慮,假如我不需要抽象出共用的ADT,就是針對某個應用場景去爲它設計一套ADT,那麼這個ADT究竟應該怎樣設計,就比如,本次實驗中的航班管理計劃項,很自然,會去想,需要關於飛機的描述,需要關於機場的描述,需要起始時間的描述,需要關於狀態的描述等等,那麼就可以把這個再去往其它的比如課程比如高鐵的計劃項上作映射,看看哪些是計劃項的共有屬性,再看看這些屬性中在不同的應用場景中有什麼不同,就像實驗指導手冊中給的那個表一樣,這樣理清楚頭緒會給之後的設計提供很多的幫助和參考。

在這裏插入圖片描述
2.關於設計???
維度拆分完之後,我們需要爲其設計一個大致的設計方案,我們可以採用實驗指導書上給的實驗方案(後幾種比較好一些),也可以綜合某幾種靈活設計,在這裏不想對這幾種設計方案再多說些什麼,想要說一些體會,
(1):既然是關於可複用性的設計,在設計的時候就應該考慮好以後可能會怎麼變化,怎麼複用,爲以後的拓展留出餘地。
(2):既然是關於可複用性的設計,在實現的時候就應該就應該面向可複用實現,不要怕麻煩,現在的麻煩是爲了以後改變的方便。
(3):關於”委託“和“繼承”,繼承在使用起來個人感覺不如委託方便,委託有一種“拿來主義,爲我所用”的感覺,而繼承有一種“不管你願不願意,都需要繼承”的感覺,儘管你可以在原有的基礎之上做出改變以適應自身需求,但比較麻煩,而且還有LSP原則的限制。
(4):關於一系列設計模式,在上課的時候覺得講的設計模式很多,但是在實驗中理解,才發現有很多設計模式都是基於接口的,其能增強可變性的原因都是因爲接口統一不同實現的能力。
(5):儘量爲每個類都重寫equals和hashCode方法,尤其是你不確定它會不會被加入到集合類這樣的數據結構當中。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章