{%hackmd lTq14m8-RK6cksBvQ0Rnrg %} # OOA/OOD/OOP [TOC] ## Object-Oriented 物件導向 @StanShih 現實世界有很多物件 「物件」,顧名思義就是一個物體。讓我們想想,當我們想要描述一個物體的時候,我們會怎麼描述?我們可以描述那個物體的長、寬、高、顏色、重量、形狀等。以上這些用來描述一個物體的東西,稱為該物體的「屬性」(property)。 除了物體的屬性之外,我們還會想到一個問題:「我們該如何使用這個物體?」例如,杯子可以用來裝水、喝水、砸碎等。我們稱這些功能「方法」(method)。 軟體不會實作這麼多物件, :::spoiler 引用 - https://zetria.tw/python/ded243b324 - https://world.waterballsa.tw/ ::: ## SOLID @StanShih SOLID 是個縮略詞,它代表 5 個重要的 OO design principles: - S 代表 Single Responsibility Principle (SRP),一個 class 應該只得一個改變的理由。 - O 代表 Open-Closed Principle (OCP),當新增功能應該不需要改動現有的 class,而是透過增加新的 class。 - L 代表 Liskov Substitution Principle (LSP),子類的 class 一定要可以在各方面都適合替代父類的 class。 - I 代表 Interface Segregation Principle (ISP),針對每個應用來制訂很多精細的 interface。 - D 代表 Dependency Inversion Principle (DIP),透過抽象 (abstract class, interface) 來間接指用 concrete class。 ## 物件導向分析(Object-Oriented Analysis, OOA) @Henry @ShenKuo 面向物件分析(OOA)是軟體開發生命週期中的關鍵階段,它的目標是詳細地理解問題領域並捕獲系統的需求,以為後續的面向對象設計(OOD)和面向物件程式設計(OOP)提供基礎。 1. 專案背景: * 在開始 OOA 階段之前,首先需要了解專案的上下文,包括專案的目標、範圍和重要性。 這有助於確保分析過程始終與專案的整體目標保持一致。 2. 需求收集和分析: * 利益相關方識別:識別專案的利益相關方,包括客戶、使用者、管理層等。 瞭解他們的期望和需求。 * 需求定義:收集和記錄系統的需求,包括功能需求(系統應該做什麼)和非功能需求(性能、可靠性、安全性等)。 * 用例分析:通過用例圖和用例規約來描述系統的功能需求。 用例圖顯示了系統與外部實體(使用者、系統、設備等)之間的互動,用例規約描述了每個用例的詳細行為。 * 問題領域建模:使用類圖、活動圖和狀態圖等工具,對問題領域中的實體、屬性、關係和行為進行建模。 類圖描述了問題領域的類和它們之間的關係,活動圖描述了系統中的過程,狀態圖描述了物件的狀態轉換。 * 數據建模:使用數據模型(通常是 ER 圖或關係模型)來描述系統中的數據結構和關係。 3. 確定問題領域的實體和關係: * 問題領域建模:使用類圖來標識問題領域中的實體和它們之間的關係。 每個類代表一個問題領域的概念,包括物件和概念性類別。 關係表示不同實體之間的關聯,如繼承、關 4. 需求規約: * 用例規約:用例規約詳細描述了每個用例的行為,包括輸入、輸出和流程。 這有助於確保需求被清晰地定義。 5. 用例建模: * 用例圖:繪製用例圖,顯示系統與外部實體之間的互動。 用例圖是使用者需求的可視 6. 資料建模: * 數據模型:創建數據模型,以描述系統中的數據結構和實體之間的關係。 7. 行為建模: * 活動圖:使用活動圖來描述系統中的各種過程和業務流程。 活動圖顯示了各個步驟和行為的順序。 * 狀態圖:使用狀態圖來描述物件的狀態和狀態之間的轉換。 這對於建模有限狀態機非常有用。 8. 驗證與驗證: * 與利益相關方的交互:與專案的利益相關方共同驗證和驗證需求 9. 產出物: * 需求文檔:詳細記錄了專案的需求,包括用例規約、類圖、活動圖、狀態圖等。 * 用例圖:用於可視化使用者需求和系統的外部互動。 * 類圖:描述問題領域中的實體、屬性和關係。 * 活動圖:詳細描述系統中的各種過程和流程。 * 狀態圖:描述物件的狀態和狀態轉換。 * 數據模型:描述系統中的數據結構。 ## 物件導向設計(Object-Oriented Design, OOD) @Amber 正確有效地構建出複雜系統的抽象結構,將物件導向分析後的結果,作為物件導向設計的模型,通常用於展示被設計系統的邏輯模型(業務邏輯如何設計),物理模型(系統如何劃分,層次如何劃分,如何部署……),靜態模型(構成系統的元素:類,介面)和動態模型(物件的呼叫……)。將OOA分析的結果作進一步的規範化整理,以便能夠被OOP直接接受。 1. 根據物件導向的方式,將系統分解成不同的模組,或者再次划分為子系統,直到划分到可設計的最小粒度為止 2. 使用不同的表示方法來展示被設計系統的邏輯模型(業務邏輯如何設計),物理模型(系統如何劃分,層次如何劃分,如何部署……),靜態模型(構成系統的元素:類,介面)和動態模型(物件的呼叫…… @Danny 面向對象設計(Object-Oriented Design,OOD)方法是OO方法中一箇中間過渡環節。其主要作用是對OOA分析的結果作進一步的規範化整理,以便能夠被OOP直接接受。 l 決定你要的類; l 給每個類提供完整的一組操作; l 明確地使用繼承來表現共同點。 由這個定義,我們可以看出:OOD就是“根據需求決定所需的類、類的操作以及類之間關聯的過程”。 OOD的目標是管理程序內部各部分的相互依賴。爲了達到這個目標,OOD要求將程序分成塊,每個塊的規模應該小到可以管理的程度,然後分別將各個塊隱藏在接口(interface)的後面,讓它們只通過接口相互交流。比如說,如果用OOD的方法來設計一個服務器-客戶端(client-server)應用,那麼服務器和客戶端之間不應該有直接的依賴,而是應該讓服務器的接口和客戶端的接口相互依賴。 ## 物件導向程式設計(Object-Oriented Programming, OOP) @GuanLun  介面(Interface):介面定義了一組方法的合同,但不包含實際的方法實現。類別可以實現一個或多個介面,以保證它們提供了介面中定義的方法。 多重繼承(Multiple Inheritance):多重繼承是一個OOP特性,允許一個類別同時繼承多個父類別的屬性和方法。不是所有的程式語言都支援多重繼承,因為它可能導致一些設計和命名衝突問題。 建構子和解構子(Constructor and Destructor):建構子是在物件創建時執行的方法,用於初始化物件的屬性。解構子是在物件被銷毀時執行的方法,通常用於釋放資源和清理工作。 訪問控制(Access Control):OOP語言通常提供不同的訪問修飾詞,如公共(public)、私有(private)和受保護(protected),以控制類別的成員對外部程式碼的可見性和訪問權限。 繼承 vs. 複合(Inheritance vs. Composition):選擇何時使用繼承和何時使用複合是一個重要的設計決策。繼承建立了一個「is-a」關係,而複合建立了一個「has-a」關係。通常,推薦使用複合來實現類別之間的關係,以降低耦合性。 設計原則(Design Principles):OOP遵循一些重要的設計原則,如單一職責原則(Single Responsibility Principle)、開放/封閉原則(Open/Closed Principle)和依賴反轉原則(Dependency Inversion Principle),以幫助編寫乾淨、可擴展和可維護的程式碼。 1. 繼承關係(Inheritance) 2. 實現關係(Implemention) 3. 依賴關係(Dependency) 4. 關聯關係(Association) 5. 聚合關係(Aggregation) 6. 組合關係(Composition) @Vincentl92 OOP 代表 "Object-Oriented Programming"(物件導向編程),是一種計算機編程方法,它以物件為基礎,將數據(稱為物件)和操作數據的函數(稱為方法)結合在一起。OOP 通常使用類別(Class)和物件(Object)的概念,這些類別定義了對象的特性(屬性)和行為(方法)。 以下是 OOP 的一些關鍵概念: 1. 類別(Class):類別是定義對象的模板或藍圖。它包含了對象的屬性和方法的定義。類別是一個抽象的概念,用於創建實際的對象。 2. 物件(Object):物件是根據類別創建的實例。它包含了類別中定義的屬性的值,並可以執行類別中定義的方法。 3. 封裝(Encapsulation):封裝是一個保護對象內部狀態的概念。它使物件的內部細節對外部不可見,只有通過公共介面(方法)才能訪問它們。 4. 繼承(Inheritance):繼承允許一個新的類別(子類別)基於現有的類別(父類別)來創建。子類別可以繼承父類別的屬性和方法,並可以擴展或重寫它們。 5. 多型(Polymorphism):多型允許不同的對象對相同的方法做出不同的響應。這意味著具有相同方法名的不同對象可以執行不同的操作。 6. 抽象(Abstraction):抽象是簡化複雜的現實問題的途徑,它可以為具體問題找到最恰當的類別定義,並且可以在最恰當的繼承級別解釋問題。 物件導向程式設計可以看作一種在程式中包含各種獨立而又互相呼叫的物件的思想,這與傳統的思想剛好相反:傳統的程式設計主張將程式看作一系列函數的集合,或者直接就是一系列對電腦下達的指令。物件導向程式設計中的每一個物件都應該能夠接受資料、處理資料並將資料傳達給其它物件,因此它們都可以被看作一個小型的「機器」,即物件。目前已經被證實的是,物件導向程式設計推廣了程式的靈活性和可維護性,並且在大型專案設計中廣為應用。此外,支持者聲稱物件導向程式設計要比以往的做法更加便於學習,因為它能夠讓人們更簡單地設計並維護程式,使得程式更加便於分析、設計、理解。反對者在某些領域對此予以否認。 當我們提到物件導向的時候,它不僅指一種程式設計方法。它更多意義上是一種程式開發方式。在這一方面,我們必須了解更多關於物件導向系統分析和物件導向設計(Object Oriented Design,簡稱OOD)方面的知識。許多流行的程式語言是物件導向的,它們的風格就是會透由物件來創出實例。 OOP 的優勢包括代碼的組織性、可重用性、可維護性和可擴展性。它有助於模擬真實世界中的實體和交互作用,並簡化了複雜系統的設計和實現。許多現代編程語言,如Java、C++、Python 和C#,都支援物件導向編程。
×
Sign in
Email
Password
Forgot password
or
Sign in via Google
Sign in via Facebook
Sign in via X(Twitter)
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
Continue with a different method
New to HackMD?
Sign up
By signing in, you agree to our
terms of service
.