2010年5月24日 星期一

Head First OOAD Ch5-1 tips

Nothing Ever Stays the Same : good design ....謎之音(喔三不五時可能就會改了lol)

經驗談, 有時候當設計了一個class被拿做某種用途(ex: 傳遞至前端的value object),但過了一陣子
可能又因為不同報表需求而調整,希望增加某些特性來提供功能,於是就又重新設計了一個很類似的東西出來用,像是過去曾經寫的 Fdmsa17sm , Fdmsa17smImport, 當面對這類的問題時,最好的方式就是乾脆將共通性的部分,向上抽離,抽成一個abstract base class(註: abstract class couldn't be an instance).

其實抽離成abstract class, 並不是只是把一些共通的東西抽出來進行封裝,避免資訊重複登打的dirty code,而是因為在系統分析時,並不需要一個實際(actual)的物件來完整描述細節,所以把已知的一些資訊給抽離封裝起來( into a  placeholder),而實做部份就等待開發階段依據不同的實做關係(extends or inherit)再行處理

# Abstract classes are placeholders for actual implementation classes.
# The abstract class defines behavior, and the subclasses implement that behavior.

# Whenever you find common behavior in two or more places, look to abstract that behavior into a class, and then reuse that behavior in the common classes.

UML圖解區

1. 線條上,實線指的是associatiation ,如果兩端沒有箭頭,表示在source class中並沒有 target class作為attribute,僅僅只是有ref到該target class.
2. 若為帶有箭號的實線,表示source class中 具有target class作為attribute,並可透過multiplicity得知數量.
3.以下為cla ss diagram資訊
   (1)class name是斜體,則表示該class為 abstract class.
   (2)The line with a diamond(空心的菱形實線) means aggregation.Aggregation is a special form of
        association, and means that one thing is made up ( in part) of another thing.
   (3)A line with an arrow that isn't colored(空心三角箭頭實線) in means generalization.(繼承)

---> 亂入一下 sort of silly (有點傻 ) <---
--->you maybe onto something (你也許不無道理) <---
--->consolidated (綜合) <---
--->nasty(討厭)<----

小結: 在本章節當中,雖然開始使用了abstract class的概念,但在面臨多個不同的sublcass時,仍需要處理多個因為不同的sub type, 而使的程式碼必須判斷不同型別,而有不同的解決方案 ( compare by instanceof  syntax) , 看起來是時候該使用interface了 !!!像面臨本章節的問題,正是說明了程式設計時應該 " Coding to the interface , not the implementation"

# Coding to an interface, rather than to an implementation, makes your sotware easier to extend.
# By coding an interface, your code will work with all of the interface's subclasses - even ones that haven't been created yet.

在uml中,宣告一個interface,需要以<>做標記並搭配斜體字體宣告class name.

OO Principal
#  by localizing the changes required for the behavior of an object to vary.
# Encapsulate what varies.
# Code to an interface rather than to an implementation.
# Each class in your application should have only one reason to change.
# Every class should attempt to make sure that it has only one reason to this, the death of many a badly designed piece of software.

沒有留言: