初學者的JavaOOAD

標籤：

軟體工程三要素方法：完成軟體開發的各項任務的技術方法，為軟體開發提供 “如何做” 的技術 工具：為運用方法而提供的自動的或半自動的軟體工程的支撐環境 過程：為了獲得高品質的軟體所需要完成的一系列任務的架構，它規定了完成各項任務的工作步驟，如何將軟體工程方法與軟體工具相結合，合理、及時地進行軟體開發

 

 

Unified Modeling Language UML語言  一般我們用UML中的類圖

類圖關係如下：

實現關係是指介面及其實作類別之間的關係

泛化關係（Generalization）是指對象與對象之間的繼承關係

關聯關係（Association）是指對象和對象之間的串連，它使一個對象知道另一個對象的屬性和方法。

在Java中，關聯關係的代碼錶現形式為一個對象含有另一個對象的引用（關聯關係有單向關聯和雙向關聯。 ）

依賴 （Dependency） 關係是一種弱關聯關係。依賴關係在Java中的具體代碼錶現形式為B為A的構造器或方法中的局部變數、方法或構造器的參數、方法的傳回值，或者A調用B的靜態方法。 彙總（Aggregation）是關聯關係的一種特例，它體現的是整體與部分的擁有關係，即“has a”的關係。此時整體與部分之間是可分離的，它們可以具有各自的生命週期，部分可以屬於多個整體對象，也可以為多個整體對象共用，所以彙總關係也常稱為共用關係。 組合（Composition）也是關聯關係的一種特例，它同樣體現整體與部分間的內含項目關聯性，即“contains a”的關係。但此時整體與部分是不可分的，部分也不能給其它整體共用，作為整體的對象負責部分的對象的生命週期。這種關係比彙總更強，也稱為強彙總。 若要出去吹牛的話，第一個要記住這個：共23種設計模式

建立型模式，共五種：Factory 方法模式、抽象原廠模式、單例模式、建造者模式、原型模式。

結構型模式，共七種：適配器模式、裝飾器模式、代理模式、面板模式、橋接模式、組合模式、享元模式。

行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、

責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解譯器模式。

其實還有兩類：併發型模式和線程池模式。 如何衡量軟體設計品質首要的標準滿足軟體的功能需求滿足軟體功能需求的設計並不一定就是好的設計。好的設計可讀性：軟體的設計文檔是否輕易被其他程式員理解。可讀性差的設計會給大型軟體的開發和維護過程帶來嚴重的危害。可複用性：軟體系統的架構、類、組件等單元能否很容易被本項目的其它部分或者其它項目複用。可擴充性：軟體面對需求變化時，功能或效能擴充的難易程度。可維護性：軟體維護（主要是指軟體錯誤的修改、遺漏功能的添加等）的難易程度。內聚度、耦合度：高內聚，低耦合。 內聚度定義：表示一個應用程式的單個單元所負責的任務數量和多樣性。內聚與單個類或者單個方法單元相關。好的軟體設計應該做到高內聚。理想狀態下，一個代碼單元應該負責一個內聚的任務，也就是說一個任務可以看作是一個邏輯單元。一個方法應該實現一個邏輯操作，一個類應該代表一種類型的實體。內聚原則背後的主要原因是重用。遵循該規則的另一個優點是，當一個應用程式的某些方面需要做出改變時，我們能夠在相同單元中找到所有相關的部分。如果一個系統單元只負責一件事情，就說明這個系統單元有很高的內聚度；如果一個系統單元負責了很多不相關的事情，則說明這個系統單元是內聚度很低。內聚度的簡單判斷方法如果一個方法可以用簡單的“動詞+名詞”的形式來命名，或者如果一個類可以用準確的名詞來命名，那麼這樣的類或者方法就是內聚度較高的系統單元；反之，如果類或者方法的名字必須包含“和”、“或”等字樣才能準確反映其功能特性的話，這些類或方法的內聚度就一定不高。 耦合度表示類之間關係的緊密程度。耦合度決定了變更一個應用程式的容易程度。在緊密耦合的類結構中，更改一個類會導致其它的類也隨之需要做出修改。顯然，這是我們在類設計時應該避免的，因為微小的修改會迅速波動影響到整個應用程式。此外，找到需要修改的所有的地方是必須的，實際上就使得修改變得困難並且耗費時間。而在鬆散耦合的系統中，我們可以更改一個類，不需要修改其它類，而應用程式仍然能夠正常工作。 

設計原則名稱	設計原則簡介	重要性
單一職責原則	類的職責要單一，不能將太多的職責放在一個類中。	★★★★☆
開閉原則	軟體實體對擴充是開放的，但對修改是關閉的，即在不修改一個軟體實體的基礎上去擴充其功能。	★★★★★
裡氏替換原則	在軟體系統中，一個可以接受基類對象的地方必然可以接受一個子類對象。	★★★★☆
依賴倒轉原則	要針對抽象層編程，而不要針對具體類編程。	★★★★★
介面隔離原則	使用多個專門的介面來取代一個統一的介面。	★★☆☆☆
組合/彙總複用原則	在系統中應該盡量多使用組合和彙總關聯關係，盡量少使用甚至不使用繼承關係。	★★★★☆
迪米特法則	一個軟體實體對其他實體的引用越少越好，或者說如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用，而是通過引入一個第三者發生間接互動。	★★★☆☆

  

初學者的JavaOOAD