设计模式是高层次的、抽象的解决方案模板。其实追溯设计模式,应该归功于早在20世纪70年代建筑大师Christopher Alexander.当然那时候引入不是解决软件开发领域的。时到今天,GOF(四人组),我叫为“四人帮”了,前后收录了23种设计模式,并归纳为3大类:(用1到5级来显示我们在开发项目过程中的使用频度)
根据范围可分为类模式和对象模式两种
(1)创建型模式:处理对象构造和引用,包括:
简单工厂模式(Simple Factory);(4级)
工厂方法模式(Factory Method);(5级)
抽象工厂模式(Abstract Factory);(5级)
创建者模式(Builder);(2级)
原型模式(Prototype);(3级)
单例模式(Singleton)。(4级)
严格来说,简单工厂模式不是GoF总结出来的23种设计模式之一,简单工厂模式是学习其他模式的基础。
(2)结构型模式:处理对象之间的关系以及它们之间如何进行交互形成更大的复杂对象
在解决了对象的创建问题之后,对象的组成以及对象之间的依赖关系就成了开发人员关注的焦点,因为如何设计对象的结构、继承和依赖关系会影响到后续程序的维护性、代码的健壮性、耦合性等。
外观模式(Facade);(5级)
适配器模式(Adapter);(4级)
代理模式(Proxy);(4级)
装饰模式(Decorator);(3级)
桥接模式(Bridge);(3级)
组合模式(Composite);(4级)
享元模式(Flyweight)。(1级)
(3)行为型模式:处理对象之间的通讯,特别是责任和算法方面
在对象的结构和对象的创建问题都解决了之后,就要处理对象的行为了。如果对象的行为设计的好,它们之间的协作效率就会提高。
模板方法模式(Template Method); (3级)
观察者模式(Observer); (5级)
状态模式(State); (3级)
策略模式(Strategy); (4级)
职责链模式(Chain of Responsibility);(2级)
命令模式(Command); (4级)
访问者模式(Visitor); (1级)
中介者模式(Mediator); (2级)
备忘录模式(Memento); (2级)
迭代器模式(Iterator); (5级)
解释器模式(Interpreter)。 (1级)
设计模式的宗旨在于可以重用解决方案。模式是描述复杂问题的解决方案的有效形式。
范围\目的
|
创建型模式
|
结构型模式
|
行为型模式
|
类模式
|
工厂方法模式
|
(类)适配器模式
|
解释器模式
模板方法模式
|
对象模式
|
抽象工厂模式
建造者模式
原型模式
单例模式
|
(对象)适配器模式
桥接模式
组合模式
装饰模式
外观模式
享元模式
代理模式
|
职责链模式
命令模式
迭代器模式
中介者模式
备忘录模式
观察者模式
状态模式
策略模式
访问者模式
|
****************************************************************************************************************************************************************************************
下面谈谈Robert Martin的S.O.L.I.D原则,这是针对面向对象设计的最佳实践。
(具体内容大家可以网上搜索一下或者参考之前我推荐给大家的书本《ASP.NET设计模式》(有点深度)和《设计模式》(比较系统化)一书)
a、单一职责原则(SRP):类的职责要单一,不能将太多的职责放在一个类中
类的职责主要包括两个方面:数据职责和行为职责,数据职责通过其属性来体现,而行为职责通过其方法来体现
b、开放封闭原则(OCP):软件实体对扩展是开放的,但对修改是关闭的,即在不修改一个软件实体的基础上去扩展其功能
一个软件实体应当对扩展开放,对修改关闭。也就是说在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,即实现在不修改源代码的情况下改变这个模块的行为
c、里氏替换原则(LSP):在软件系统中,一个可以接受基类对象的地方必然可以接受一个子类对象
在软件中如果能够使用基类对象,那么一定能够使用其子类对象。把基类都替换成它的子类,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类的话,那么它不一定能够使用基类。
d、接口分离原则(ISP):使用多个专门的接口来取代一个统一的接口
使用多个专门的接口,而不使用单一的总接口。每一个接口应该承担一种相对独立的角色,不多不少,不干不该干的事,该干的事都要干
e、依赖倒置原则(DIP):要针对抽象层编程,而不要针对具体类编程
代码要依赖于抽象的类,而不要依赖于具体的类;要针对接口或抽象类编程,而不是针对具体类编程。
实现开闭原则的关键是抽象化,并且从抽象化导出具体化实现。
如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要手段。
f、依赖注入(DI)和控制反转(IoC)原则
g、迪米特法则:
一个软件实体对其他实体的引用越少越好,或者说如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,而是通过引入一个第三者发生间接交互。
一个软件实体应当尽可能少的与其他实体发生相互作用。这样,当一个模块修改时,就会尽量少的影响其他的模块,扩展会相对容易,这是对软件实体之间通信的限制,它要求限制软件实体之间通信的宽度和深度。
》》》》》》》》》》以下参考文献是《设计模式》
迪米特法则分析
(1)狭义的迪米特法则:可以降低类之间的耦合,但是会在系统中增加大量的小方法并散落在系统的各个角落,它可以使一个系统的局部设计简化,因为每一个局部都不会和远距离的对象有直接的关联,但是也会造成系统的不同模块之间的通信效率降低,使得系统的不同模块之间不容易协调。
(2)广义的迪米特法则:指对对象之间的信息流量、流向以及信息的影响的控制,主要是对信息隐藏的控制。信息的隐藏可以使各个子系统之间脱耦,从而允许它们独立地被开发、优化、使用和修改,同时可以促进软件的复用,由于每一个模块都不依赖于其他模块而存在,因此每一个模块都可以独立地在其他的地方使用。一个系统的规模越大,信息的隐藏就越重要,而信息隐藏的重要性也就越明显。
h、合成复用原则:在一个新的对象里通过关联关系(包括组合关系和聚合关系)来使用一些已有的对象,使之成为新对象的一部分;新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简言之:要尽量使用组合/聚合关系,少用继承
****************************************************************************************************************************************************************************************
❤永葆一颗纯洁、宽容平和、仁慈谦卑和意气风发的心!
态度决定一切 努力改变命运