Embed Size (px)
Citation preview
设计模式 - 精选
马云龙http://www.google.com/profiles/clouddragon.ma
http://twitter.com/mayunlong
目录
• 门面（外观）模式
• 观察者模式
• 访问者模式
• 中介者模式
• 装饰模式
• SRP 原则
• OCP 原则
门面模式 -Facade
• 门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。
• 适用场景：– 1 、为一些复杂的子系统提供一组接口
2 、提高子系统的独立性3 、在层次化结构中，可以使用门面模式定义系统的每一层的接口
• 我们的项目：登陆、注册
Facade- 类图
Facade- 代码示例
• Public interface Facade{– Public String antispam();// 过滤敏感词
– Public Object userSession();// 用户 session– /**– * 注册可封装 antispam 和 userSession 服务
– */– Public Integer regUser();
• }
门面模式的优点
• 优点：– 1 、它对客户屏蔽了子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便2 、实现了子系统与客户之间的松耦合关系3 、如果应用需要，它并不限制它们使用子系统类。因此可以在系统易用性与能用性之间加以选择
• 缺点：– 你必须为封装业务逻辑而特意的写很多的代码 ( 添加新的接口 ) 。
观察者模式 -Observer
• 观察者模式：观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
• 适用场景：– 1 、 对一个对象状态的更新，需要其他对象同步更新，而且其
他对象的数量动态可变。
2 、 对象仅需要将自己的更新通知给其他对象而不需要知道其他对象的细节。
• 我们的项目：系统消息 rss 订阅
Observer- 类图
Observer- 代码示例
• Public Interface Subject{– Public void addObserver(Observer o);– Public void delObserver(Observer o);– Public void notifyObservers();
• }• Public class SubjectImpl{
– ……– Public void increaceRank(){
• notifyObservers();// 通知观察者• }
• }
观察者模式的优点
• 优点：
1 、 Subject 和 Observer 之间是松偶合的，分别可以各自独立改变。 2 、 Subject 在发送广播通知的时候，无须指定具体的Observer ， Observer 可以自己决定是否要订阅 Subject的通知。 3 、 遵守常用设计原则，高内聚、低偶合。
• 缺点：– 广播链问题
– 异步处理问题
访问者模式 -Visitor
• 访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对稳定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。
• 适用场景：业务对象要遍历多个不同的对象；与迭代器模式的区别在于 visitor模式可遍历多个不同对象，但迭代器模式只能访问同类或同接口的对象。
•
• 我们的项目：数据统计
Visitor- 类图
Visitor- 代码示例
• Public interface Ivisitor{– Public void visit(Employee e);– Public void visit(Manager m);
• }
• Public class Employee{– …..– Public void accept(Ivisitor v){
• V.visitor(this);– };
• }
Visitor- 优缺点
• 优点：– 不用修改具体的元素类，就可以增加新的操作。主要是通过元素类的 accept 方法来接受一个 visitor 对象来
实现的。
• 缺点：– 不易频繁增加元素类，没增加一个元素类，就要在
Visitor 接口中写一个针对该元素的方法，而且还要修
改 Visitor 的子类。
中介者模式 -Mediator
• 中介者模式：中介者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。
• 适用场景：– 1 、一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系
结构混乱且难以理解。– 2 、一个对象引用其他很多对象并且直接与这些对象通信 ,导致难以复用该对象。
– 3 、想定制一个分布在多个类中的行为，而又不想生成太多的子类。
• 我们的项目： passport 、 profile 和 messageCenter 可尝试
Mediator- 类图
Mediator- 代码示例
• Public abstract class Mediator{– Protected ConcreateColleague1 c1;– Protected ConcreateColleague2 c2;– ……..
– // 中介者业务逻辑
– Public abstract void doSomething1();– Public abstract void doSomething2();
}
Mediator- 代码示例
• Public class ConcreateMediator extends Mediator{
– @Override– Public void doSomething1(){
• C1.selfMethod1();• C2.selfMethod2();
– }
– @Override– Public void doSomething2(){
• C1.selfMethod2();• C2.selfMethod1();
– }
• }
Mediator- 代码示例
• Public abstract class Colleague{– Protected Mediator mediator;– Public Colleague(Mediator mediator){
• this.mediator=mediator;
– }
– ……
• }
Mediator- 代码示例
• Public class ConcreateColleague extends Colleague{
– Public ConcreateColleague (Mediator mediator){• Super(mediator);
– }
– Public void selfMethod1(){….}– ……
– Public void depMethod(){• // 处理自己的业务逻辑• // 通过中介者处理的逻辑• Super.Mediator.doSomething1();
– }
• }
Mediator- 优缺点
• 优点：– 1 、它将各 colleague 解耦。 mediator 有利于各 colleague 间的松
耦合，你可以独立的改变和复用各 colleague 类和 mediator 类。2 、它简化了对象协议用 mediator 和各 colleague 间的一对多的交互来代替多对多的交互。一对多的关系更易于理解、维护和扩展。3 、它对对象如何协作进行了抽象将中介作为一个独立的概念并将其封装在一个对象中，使你将注意力从对象各自本身的行为转移到它们之间的交互上来。这有助于弄清楚一个系统中的对象是如何交互的。
• 缺点：– 它使控制集中化中介者模式将交互的复杂性变为中介者的复杂性。
因为中介者封装了协议，它可能变得比任一个 colleague都复杂。
这可能使得中介者自身成为一个难于维护的庞然大物。
装饰模式 -Decorator
• 装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。
• 适用场景：– 1 ）在不影响其他对象的情况下，以动态、透明的方式给单个对
象添加额外的责任2 ）为了避免类的数目爆炸，或者不能采用生成子类的方法进行扩展时
– 3 ）主要用在系统维护时
• 我们的项目：暂无
Decorator- 类图
Deractor- 代码示例
• Public abstract class SchoolReport{– Public abstract report();
– …..
• }• Public class FourthGradeSchoolReport extends
SchoolReport{– @Override– Public report(){….}
• }
Deractor- 代码示例
• Public abstract class Deractor{– Potected SchoolReport report;
– Public Deractor(SchoolReport report){• This.report=report;
– }– Public void report(){report.report();}
• }
Deractor- 代码示例
• Public class SortDecorator extends Decorator{– Public SortDecorator (SchoolReport report){
• Supert(report);
– }– Public void report(){
• // 一些装饰逻辑
• //调用原有逻辑
• Super.report();
– }– …….
• }
Deractor- 优缺点
• 优点：– 装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰
模式可以提供比继承更多的灵活性。
– 通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。
– 这种比继承更加灵活机动的特性，也同时意味着装饰模式比继
承更加易于出错。
• 缺点：• 使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使
得查错变得困难，特别是这些对象看上去都很相像。
原则 1-SRP
• 一个优良的系统设计，强调模块间保持低耦合、高内聚的关系，在面向对象设计中这条规则同样适用，所以面向对象的第一个设计原则就是：单一职责原则（ SRP ， Single Responsibility Principle ）。
• 单一职责，强调的是职责的分离，在某种程度上对职责的理解，构成了不同类之间耦合关系的设计关键，因此单一职责原则或多或少成为设计过程中一个必须考虑的基础性原则。
SRP-核心思想• SRP核心的思想是：
• 一个类，最好只做一件事，只有一个引起它变化的原因。
• 单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。
• 因此， SRP 原则的核心就是要求对类的改变只能是一个，对于违反这一原则的类应该进行重构，例如以 Façade 模式或 Proxy 模式分离职责，通过基本的方法 Extract Interface 、 Extract Class 和Extract Method 进行梳理。
原则 2-OCP
• 开放封闭原则（ OCP ， Open Closed Principle ）是所有面向对象原则的核心。
• 软件设计本身所追求的目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。其他的设计原则，很多时候是为实现这一目标服务的，例如以 Liskov替换原则实现最佳的、正确的继承层次，就能保证不会违反开放封闭
原则。
OCP-核心思想
• 核心的思想是：• 软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的
，而对修改是封闭的。
• 因此，开放封闭原则主要体现在两个方面：– 对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。
– 对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。
• 对于违反这一原则的类，应该进行重构来改善，常用于实现的设计模式主要有 Template Method 模式和 Strategy 模式。而封装变化，是实现这一原则的重要手段，将经常发生变化的状态封装为一个类。
• Thanks
