Head First OOAD Ch8 tips

Design Principles

Principle #1 : The Open-Closed Principle ( OCP )

簡單的說就是一個允許變動的觀念(概念), 但是在變動時,你不需要去修改已經寫好的code.

定義: Classes should be open for extension ( subclass ?), and closed for modification ( ?? .. private ?)

在ch5當中的InstrumentSpec , 有兩個子類別繼承了他,在子類別中override的 method就是這樣的概念,父類別當中已有其動作之規範,為了能在子類別中有不同的表現與作為,於是透過此開放的繼承(open for extension), the OCP is about flexibility , and goes beyond just inheritance.

Principle #2 : The Don't Repeat Yourself Principle

不要重複的散置同樣的程式碼到不同的object...這個會造成惡夢?_?

 #DRY is really about ONE requirement in ONE place

 #DRY is about having each piece of information and behavior in your system

    in a single, sensible place.

Principle #3 : The Single Responsibility Principle (SRP)

SRP主要闡述的是"責任", 每個物件都應該在設計時完整的去對應他應該處理的事物

不要將風馬牛不相乾的東西 蝦湊一通在一起...每個物件都應該只focus在單一事物上

能切分的清楚點就清楚點

# You've implemented the Single Responsibility Principle correctly when each of your objects

   has only one reason to change.

亂入的問題....DRY & SRP...(這兩個到底差在哪?)

DRY,主要訴求是希望不要將重複的行為到處放,將他全數歸納到單一個物件裡頭,而SRP則是

在設計層面上,希望盡可能的讓每一個物件都只負責一件事情,以這樣的角度希望可以讓每個

物件都只對自己的行為負責,自然的也就將問題單純化,面對變更時可以單純的調整單一物件..

Principle #4 : The Liskov Substitution Principle ( LSP )

# The LSP is all about well-designed inheritance. When you inherit from a base class,you must be able to substitute your subclass for that base class without things going terribly wrong. Otherwise,

you've used inheritance incorrectly.

這看起來有點不是很清楚,what's Liskov (講真的字典真沒這個字-.-)

其實主要是講說如果以一個class繼承了父類別,必須在子類別中可以很明確的有其替代的意義,

也就是在子類別的成員中,必須讓每個method都具有其真實意義,否則會使的自父類別中繼承而來的成員變得一無是處..

以下舉一個濫用( misusing)繼承的例子說明會比較清楚...

------------------------------------------------------------------

Board class, then a 3DBoard extends the Board.

在原本的Board class當中有提供簡單的method,但在3D模組的環境下,那些原生的method(原本是平面的..不需要計算x,y,z座標)變得一無是處(原本是平面用途改為3D後需要加上一些空間計算方式),也不會再被用上(在空間中本來就不可能只查看平面的位置),像這樣的狀況就是違背了LSP的原則...

不過在以上的例子中很顯然的可以看到,這樣的直接繼承方式真的不是很理想= = 

最佳的選擇方式是 我們可以使用"代理 Delegate"

亂入的問題--> 我們何時該使用Delegate ?

# Delegation is when you hand over the responsibility for a particular task to another class or method.

在本例當中我們用3DBoard 去關聯Board ( ->實線箭頭*)

# Delegation is best used when you want to use another class's functionality, as is , without changing

   the behavior at all.

看起來好像用了delegation可以處理掉這樣的問題,那麼我們在前面章節中看到的composition
又是在什麼情形下適合出廠勒?

# When we reference a whole family of behaviors in a class, we're using composition(實心菱形).
用一個Pizza的例子來說明是最適切的了..用composition是表示所有參預的物件都可視為主體
物件的成份,也就是說當主體物件消失了,他的成份物件也會一併跟著消失..

# In composition, the object composed of other behaviors owns those behaviors.
   When the object is destroyed, so are all of its behaviors.
   The behaviors in a composition don't exist outside of the composition itself.

嗯 看起來delegate / compose 都講到了 那也該來複習一下Aggregate ( 空心的菱形)
# Aggregation : composition , without the abrupt(突然的) ending.
# Aggregation is when one class is used as part of another class, but still exists outside of that other
   class.
OK , 是時候要來作抉擇了 到底何實用Composition, 何時用Aggregation ?
#  To ask yourself, does the object whose behavior i want to use exist outside of the object that
    uses its behavior? 如果參預的class對於owner class而言是有意義的那就使用composition,
    反之則使用Aggregation

好的 本章即將進入尾聲...看到了很多的不同物件存取關係後可以發現到,使用繼承並非是
一個很好的物件處理方式,如果我們多使用delegation / composition / aggregation ,
那麼程式想邁向 flexible / easier maintain, extend / reuse 就不是夢了