文章出處

對象是什么?
--從概念層面講,對象是某種擁有責任的抽象。
--從規格層面講,對象是一系列可以被其他對象使用的公共接口。
--從語言實現層面講,對象封裝了代碼和數據.

三大機制:
--封裝,隱藏內部實現
--繼承,服用現有代碼
--多態,改寫對象行為

設計原則:

1、封裝變化。找出應用中可能需要變化之處,把他們獨立出來,不要和那些不需要變化的代碼混在一起。

2、針對接口編程,而不是針對實現編程。(針對接口編程的真正意思是:針對超類型(supertype)編程,關鍵就在于多態)

舉例說明:

假設有一個抽象類Animal,有兩個具體的實現(Dog與Cat)繼承Animal。

image

“針對實現編程”的做法:Dog d = new Dog();d.bark();

“針對接口編程”的做法:Animal animal = new Dog();animal.makeSound();

                                或者:Animal animal = getAnimal();animal.makeSound();

3、多用組合,少用繼承。

原因:

       a、繼承會使類無限膨大,可能會使類變得臃腫。

       b、子類可能會繼承父類中那些無用甚至有害的方法。

       c、組合比繼承更靈活,可以實現在執行中動態改變對象的功能。

4、為了交互對象之間的松耦合設計而努力。

5、類應該對修改關閉,對擴展開放。

6、要依賴抽象,不要依賴具體類。
解釋:不要讓“高層組件”依賴“低層組件”,而且,不管“高層組件”還是“低層組件”,兩者都應該依賴于抽象。
避免違反該原則的幾個方針:
1)、變量不可以持有具體類的引用。
如果使用new,就會持有具體類的引用,可以使用工廠來避開這種引用。
2)、不要讓類派生自具體類。
如果派生自具體類,就會依賴具體類,可以派生自抽象或接口。
3)、不要覆蓋基類中已實現的方法。
如果覆蓋基類中已實現的方法,那么基類就不是一個真正適合被繼承的類。基類中已實現的方法應該被所有子類所共享。


設計模式:

設計模式--在軟件設計過程中某一類常見問題的一般性解決方案.
面向對象設計模式-描敘了面向對象設計過程中,特定場景下,類與相互通信對象之間常見的組織關系.

1.策略模式--定義了算法家族,分別封裝起來,讓它們之間可以相互替換,此模式讓算法的變化,不會影響到使用算法的客戶

策略模式的結構 (源自呂震宇 博客)
       


      這個模式涉及到三個角色:

 

  • 環境(Context)角色:持有一個Strategy類的引用。
  • 抽象策略(Strategy)角色:這是一個抽象角色,通常由一個接口或抽象類實現。此角色給出所有的具體策略類所需的接口。
  • 具體策略(ConcreteStrategy)角色:包裝了相關的算法或行為。


最初的策略模式是有缺點的,客戶端必須知道所有的策略類,并自行決定使用哪一個策略類。這就意味著客戶端必須理解這些算法的區別,以便適時選擇恰當的算法類。換言之,策略模式只適用于客戶端知道所有的算法或行為的情況

2.觀察著模式--定義了對象之間一對多依賴,這樣一來,當一個對象改變狀態時,它的所有依賴者都會收到通知并自動更新.

實現觀察者模式的方法不止一種,但以包含Subject和Observer接口的類設計的做法最為常見
《Head.First設計模式》的學習筆記(3)--觀察者模式(長空新雁的.Net世界)

設計模式隨筆系列:氣象站的故事-觀察者模式(Observer)[原] 

Subject(被觀察的對象接口)  

l         規定ConcreteSubject的統一接口;

l         每個Subject可以有多個Observer

ConcreteSubject(具體被觀察對象)

l         維護對所有具體觀察者的引用的列表;

l         狀態發生變化時會發送通知給所有注冊的觀察者。

Observer(觀察者接口)

l         規定ConcreteObserver的統一接口;

l         定義了一個update()方法,在被觀察對象狀態改變時會被調用。

ConcreteObserver(具體觀察者)

l         維護一個對ConcreteSubject的引用;

l         特定狀態與ConcreteSubject同步;

l         實現Observer接口,通過update()方法接收ConcreteSubject的通知。

怎么樣,現在總該有點感覺了吧?下面還有一個順序圖,再體會體會~

 

       呵呵!還沒想明白,為什么官方的東西總是看不懂,看來是沒當官的命啦!其實觀察者模式十分簡單,現實生活中的例子更是隨處可見,就比如看電視:某個觀眾就是一個標準的ConcreteObserver(具體觀察者,都符合統一的Observer接口,即都要通過電視收看節目的觀眾),電視節目就是Subject(被觀察對象接口,這里體現為無線電視信號)了,不同的頻道的節目是不同的ConcreteSubject(不同頻道有不同的節目),觀眾可以自由決定看電視(registerObserver)或不看電視(removeObserver),而電視節目的變化也會在自動更新(notifyObservers)所有觀眾的收看內容。怎么樣?這回明白了吧!

       另外觀察者模式也叫發布-訂閱模式(Publishers + Subscribers = Observer Pattern,跟看電視一樣,訂閱報紙也是一個很直觀的例子,有人發布(Publish = Subject)報紙,有人訂閱(Subscribe = Observer)報紙,訂閱的人可以定期收到最新發布的報紙,訂閱人也可以隨時退訂。

觀察者模式的應用場景:

1、  對一個對象狀態的更新,需要其他對象同步更新,而且其他對象的數量動態可變。

2、  對象僅需要將自己的更新通知給其他對象而不需要知道其他對象的細節。

觀察者模式的優點:

1、  SubjectObserver之間是松偶合的,分別可以各自獨立改變。

2、  Subject在發送廣播通知的時候,無須指定具體的ObserverObserver可以自己決定是否要訂閱Subject的通知。

3、  遵守大部分GRASP原則和常用設計原則,高內聚、低偶合。

觀察者模式的缺陷:

1、  松偶合導致代碼關系不明顯,有時可能難以理解。(廢話)

2、  如果一個Subject被大量Observer訂閱的話,在廣播通知的時候可能會有效率問題。(畢竟只是簡單的遍歷)


不含病毒。www.avast.com
arrow
arrow
    全站熱搜
    創作者介紹
    創作者 AutoPoster 的頭像
    AutoPoster

    互聯網 - 大數據

    AutoPoster 發表在 痞客邦 留言(0) 人氣()