6. PO v.s OO
Traditional Development Object-Oriented Development
Method Procedure-Oriented Object-Oriented
Decomposition Algorithm Class
Life Cycle Top-Down Iterative & Incrementally
Maintainability Difficult Easy
Reusability Low High
Failure and Risk High Low
6
7. “▷ Consist of a group of cooperating objects.
▷ Objects exchange message, for the purpose of
achieving a common objective.
What is OOP?
7
Message
30. “
LSP
▷ Objects in a program should be
replaceable with instances of their
subtypes without altering the
correctness of the program.
(Liskov Substitution Principle)
30
32. “▷ A client should never be forced to
implement an interface that it doesn’t
use or clients shouldn’t be forced to
depend on methods they do not use.
ISP
(Interface Segregation Principle)
32
37. “How to create and manage and operate an
object effectively, this is always we’re talking
about. As below, those patterns give us some
principles and way of design.
Creational
▷ Simple Factory Pattern
▷ Abstract Factory Pattern
▷ Factory Pattern
▷ Builder Pattern
▷ Prototype Pattern
▷ Singleton Pattern 37
38. “How to design the static structure between
objects. How to finish the dependence of
inheritance and implement. That concerns the
program architecture is robust or not.
Structural
▷ Adapter Pattern
▷ Bridge Pattern
▷ Composite Pattern
▷ Decorator Pattern
▷ Facade Pattern
▷ Proxy Pattern 38
39. “
Behavioral
▷ Command Pattern
▷ Iterator Pattern
▷ Strategy Pattern
▷ Template Pattern
▷ Observer Pattern
The cooperation action between objects
become the final behavior. If objects co-operate
well not only effective but also let objects’
responsibility become clearly and flexibility.
▷ Mediator Pattern
▷ State Pattern
▷ Visitor Pattern
▷ Interpreter Pattern
39
First, process oriented considers about the “function”(procedure and action).
What do we need to do for finishing the “function”?
What’s the flow about the process?
According to those flows, we create the programming architecture and functions and modules.
如上應該定義的非常清楚了,因此當程序邊更時通常配合的資料必須跟著修改,如上DFD的範例:
程序導向的基本思維認為,資料是資料,如果沒有處理程序來處理的話,資料還是只是存在的靜態資訊,是獨立存在的。
所以一般程序導向的設計重心主要會在所需要的資料結構,例如:常應用在關聯式資料庫之實體關係模型(ER-Model),同常就是一種圖形表示法 + 正規化(Normalization) 產出的資料模型。因為程序導向著重於處理程序,以輸入/輸出為主體的方式思考所處裡的資料。
We consider “object” and “data” for starting creating the programming architecture.
OO is an abstraction concept(Chūshō gainen).
Cohesion(內聚Gyōshū):用白話文解釋,把執行某個功能所需用到的程式與資料都塞在某一個模組(function, class, package, etc)之中,使得該模組可被視為一個單獨的個體執行,那麼這個模組的 cohesion 就愈高。內聚,內聚,顧名思義就是把程式,資料這些有的沒的東西都『聚在一起』打包起來。
Coupling(耦合 カップリング):如果某個模組跟『其他人(另一個模組)』有關係(例如,使用 global variables 或是接受其他模組傳入的參數)那麼這兩個模組就彼此耦合。
而在談論物件導向的思維前先來談談傳統的模組化,模組化有哪些好處呢?模組化(モジュラー)可以
建立重複使用的處理程序
易於維護
減少錯誤發生,發生錯誤也易於Debug,也不至於引發更多錯誤。
容易擴充(拡張Kakuchō)
但模組化還是無法解決對資料的相依性(依存性Isonsei),可是何謂好的模組呢?這也是物件導向之所以會被發展出來的原因之一,通常一個好的模組應該具備如下兩個條件:
模組內 - 高內聚力(Cohesion)
模組間 - 低耦合度(Coupling)
因此在物件導向的『封裝』與『抽象化』等特性可以使應用程序與資料之間的相依性關係竟可能存在於物件 (類別) 的範圍之內。由於物件之間本身即有清楚的界線,因此非常例於產生低偶合度的模組,且抽象化也利於產生高內聚力的模組,即符合上述兩種特性。
The overried method must have the same datatype and same number of paramters.
An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program’s instructions.
Advantage as below.
Separating Error-Handling Code and from “Regular” code.
Error up call Stack.
Grouping and Differentiating Error Types.
Conclusion:
S.O.L.I.D might seem to be a handful at first, but with continuous usage and adherence to its guidelines, it becomes a part of you and your code which can easily be extended, modified, tested, and refactored without any problems.