Head.First设计模式学习笔记

对象是什么?
--从概念层面讲,对象是某种拥有责任的抽象。
--从规格层面讲,对象是一系列可以被其他对象使用的公共接口。
--从语言实现层面讲,对象封装了代码和数据.

三大机制:
--封装,隐藏内部实现
--继承,服用现有代码
--多态,改写对象行为

设计原则:

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订阅的话,在广播通知的时候可能会有效率问题。(毕竟只是简单的遍历)

原文地址:https://www.cnblogs.com/zwl12549/p/1156856.html