一、设计模式本质
提高 软件的维护性、通用性和扩展性,并降低软件的复杂度;
二、设计模式的类型
根据设计模式的参考书 Design Patterns - Elements of Reusable Object-Oriented Software(中文译名:设计模式 - 可复用的面向对象软件元素) 中所提到的,总共有 23 种设计模式。这些模式可以分为三大类:创建型模式(Creational Patterns)、结构型模式(Structural Patterns)、行为型模式(Behavioral Patterns)。
- 创建型模式
这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式,而不是使用 new
运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
工厂模式(Factory Pattern)
抽象工厂模式(Abstract Factory Pattern)
单例模式(Singleton Pattern)
建造者模式(Builder Pattern)
原型模式(Prototype Pattern)
- 结构型模式
这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。
适配器模式(Adapter Pattern)
桥接模式(Bridge Pattern)
过滤器模式(Filter、Criteria Pattern)
组合模式(Composite Pattern)
装饰器模式(Decorator Pattern)
外观模式(Facade Pattern)
享元模式(Flyweight Pattern)
代理模式(Proxy Pattern)
- 行为型模式
这些设计模式特别关注对象之间的通信。
责任链模式(Chain of Responsibility Pattern)
命令模式(Command Pattern)
解释器模式(Interpreter Pattern)
迭代器模式(Iterator Pattern)
中介者模式(Mediator Pattern)
备忘录模式(Memento Pattern)
观察者模式(Observer Pattern)
状态模式(State Pattern)
空对象模式(Null Object Pattern)
策略模式(Strategy Pattern)
模板模式(Template Pattern)
访问者模式(Visitor Pattern)
三、设计模式七大原则
- 单一职责原则
目的:降低代码复杂度、系统解耦合、提高可读性
含义:对于一个类,只有一个引起该类变化的原因;该类的职责是唯一的,且这个职责是唯一引起其他类变化的原因。
解决:将不同的职责封装到不同的类或者模块中。 当有新的需求将现有的职责分为颗粒度更小的职责的时候,应该及时对现有代码进行重构。当系统逻辑足够简单,方法足够少,子类够少或后续关联够少时,也可以不必严格遵循你SRP原则,避免过度设计、颗粒化过于严重
- 里氏代换原则
目的:避免系统继承体系被破坏
含义:所有引用基类的地方必须能透明地使用其子类的对象。
解决:子类可以实现父类的抽象方法,但是不能覆盖父类的非抽象方法;子类中可以增加自己特有的方法;当子类覆盖或实现父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松;当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。如果子类不能完整地实现父类的方法,或者父类的一些方法在子类中已经发生畸变,则建议断开继承关系,采用依赖,聚合,组合等关系代替继承
- 依赖倒转原则
目的:避免需求变化导致过多的维护工作
含义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。
解决:面向接口编程,使用接口或者抽象类制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。
-
接口隔离原则
目的:避免接口过于臃肿
含义:客户端不应该依赖它不需要的接口,一个类对另一个类的依赖应该建立在最小的接口上。
解决:适度细化接口,将臃肿的接口拆分为独立的几个接口
- 迪米特法则
目的:降低类与类之间的耦合
含义:每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位。
解决:不发生依赖、关联、组合、聚合等耦合关系的陌生类不要作为局部变量的形式出现在类的内部
- 合成复用原则
目的:防止类的体系庞大
含义:当要扩展类的功能时,优先考虑使用合成/聚合,而不是继承。
解决:当类与类之间的关系是"Is-A"时,用继承;当类与类之间的关系是"Has-A"时,用组合
- 开闭原则
目的:提高扩展性、便于维护
含义:对扩展(提供方)开放,对修改(使用方)封闭。即系统进行扩展是被鼓励的,对现有系统代码进行修改是不被支持的。也就是说,当软件有新的需求变化的时候,只需要通过对软件框架进行扩展来适应新的需求,而不是对框架内部的代码进行修改。
解决:设计模式前面6大原则以及23种设计模式遵循的好,开闭原则自然遵守的好。对需求的变更保持前瞻性和预见性,就可以使抽象具有更广泛适用性,设计出的软件架构就能相对稳定。软件需求中易变的细节,通过从抽象派生出实现类来扩展。

1万+

被折叠的 条评论
为什么被折叠?



