软件设计模式，给你解决问题的标准答案，少走弯路

设计模式简介

软件设计模式，是前辈们在重复发生的特定问题中总结出的解决方案，具有一定的普遍性，可以反复使用。
目的是为了提高代码的可重用性、代码的可读性和代码的可靠性；是开发者们快速成长的捷径。
强烈建议大家对设计模式进行学习，并融入到项目当中去。

设计模式针对的都是面向对象的编程语言，如java/C#等。
设计模式适用于大型的项目或者框架开发，简单的项目就没必要强行使用了，不然反而适得其反。

每种设计模块式在解决某种问题的同时，也会纯在一些缺陷，就好比人无完人。
在实际使用的时候，要集合具体的需求，采用最适合的设计。

设计模式原则

1、单一职责原则(SRP)

我形象的叫他“术业有专攻原则”。
一个类应该专注于做一件或一类事情
单个类的功能不要太多太杂，要单一职责，前端人员就是搞前端的，别和他扯什么后端服务。

优点：

有利于提高代码的可读性和可维护新，每个类的代码篇幅不会过长，读的时候容易读，改的时候容易改。
有利于提高代码的重用，其他地方需要这个功能，直接把该类拿去用就行了，不用担心类太臃肿。
有利于降低需求变更导致的风险，单个需求变了，只需改动单个类，减少对其他的影响。

就好比生活中做一个正直的男人，只爱一个女人，不花心。
这样家庭里没有多少内部矛盾，事业上才有跟多的精力。

如果你同时交往了几十个女友，刚开始的时候肯定会很爽，时间一长你就不行了。
你的身体会被榨干，精力会被拖垮，有一天翻盘了，反倒觉得是解放了。

写代码也一样，开始的时候一通骚操作，写得也爽，只要功能完成了就完事大吉。
但是慢慢的，随着时间的积累，需求的变化，你就会越来越力不从心，恨不得将原来的代码推翻重写。

2、接口隔离原则(ISP)

我形象的叫他“言简意赅原则”。
一个类对另一个类的依赖应该建立在最小的接口上
尽量将臃肿的接口拆分成更小的和更具体的接口。
是不是和单一职责原则很相似？
他们都体现了封装的思想，但是单子职责注重的是功能，接口隔离注重的是约束，层面是不同的。

优点：

提高代码的灵活性，小接口可以更灵活的组合。
减少项目代码的冗余，小接口很方便重用。
提高代码的可维护性，有问题就找对应的接口解决。
降低代码的耦合性，减少对外交互。

注意：实际编程中注意把握尺度，不要定义得过小，否则造成接口数据量太多，就得不偿失了

就好比你别人让你报一下日期，然后你回答：
今天1月20日，农历大年三十；天气阴，最高温度23度，最低温度19度；紫外线弱，适合室外运动；最新资讯…
妈的，别人就问一下日期，你瞎比比一大堆，有问你天气了吗，让你读新闻了吗，浪费口舌。
问你日期，你回答几月几日就ok了，干脆利落，别婆婆妈妈的。
问你日期和天气时，你再回答几月几日，天气如何。

3、开放封闭原则(ASD)

我形象的叫他“增量原则”。
类的功能要可以扩展，而不可修改
你可以在原功能之上扩展新的功能，但是你不能给我把原有的方法给改了。对拓展开放，对修改封闭。

优点：

拥有一定的适应性和灵活性的同时具备稳定性和延续性
软件测试时只需要对扩展的功能进行测试就可以了。
提高软件的稳定性，因为原有功能没做改动。
提供了延续性，因为可以自行扩展新的功能。

就好比你媳妇晚上突然说想吃麻麻鱼，你可别把前面做好的白水萝卜给倒了。
家里又不缺那几个碗，你再做一道麻麻鱼满足媳妇就是了嘛。
不然媳妇吃着吃着觉得麻麻鱼味道太重了，想来口清淡的你还不得晕死过去。

写代码也一样，客户说今天要给开年终总结会，销售业绩统计功能需要改动一下。
你老老实实把销售业绩统计报表给改了，高高兴兴的通知用户使用。
第二天，客户说要调回以前的那些统计内容，你不晕死。
根据开发封闭原则，你重新扩展一个领导看的统计表不就得了，第二天客户要继续使用原统计报表也是ok的。

4、依赖倒置原则(DIP)

我形象的叫他“面向接口原则”。
高层不应依赖于低层；抽象不应依赖于细节
要面向接口编程，不要面向实现编程。实现尽量依赖抽象，不依赖具体实现。
优点：

可以降低类间的耦合性。
可以提高系统的稳定性。
可以减少并行开发引起的风险。
可以提高代码的可读性和可维护性。

就好比华为Mate 30的手机屏幕，有三星的、LG的、京东方的。
不同厂家生产的屏幕这么能用到同一款手机上呢？
只需要他们都按照同一套标准来接收显示信息就可以。
这里主板和显示屏两者中间的数据交互标准定义好了后，就可以各自做各自的了。
最终组装到一起后，嗯，正常使用。

代码开发也一样，前后台也有数据交互。
我们可以先定义好交互相关的接口文档，然后前后台就可以同时根据接口文档来进行开发。

5、里氏替换原则(LSP)

我形象的叫他“亲爹原则”。
所有父类存在的地方都能透明的使用其子类的对象
尽量不要重写或重载父类的方法，以免导致已有用过出错或混淆。
子类必须能够替换其父类。不能随便去继承不合适的，有多余方法或者属性的类。子类可以扩展父类的功能，但不能改变父类原有的功能。

优点：

增强程序的健壮性，版本升级时也可以保持非常好的兼容性。
在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑。

就好比父亲是一个白人，那他的孩子也肯定要是个白人，要是儿子是个黑人，那还不得闹离婚。
在闹人种歧视的时候，他们家男主和女主都能通过则他们家的孩子也能通过。

6、迪米特原则(LOD)

我形象的叫他“经纪人原则”。
一个软件实体应当尽可能少地与其他实体发生相互作用
一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用，通过引入一个合理的第三者来降低现有对象之间的耦合度。

优点：

可降低系统的耦合度，使类与类之间保持松散的耦合关系。
提高类复用率。
一个类被修改，不会对关联的类造成太大波。

就好比你是一个明显，你想专注的搞艺术创作。
但是还有很多粉丝见面会、商演、合作的事情，这些事情交给经纪人去处理就好了。
你就可以专心做自己该做想做的事情了。

过渡使用迪米特原则将产生大量的中转或跳转类
你说这个经纪人方式可以啊，我去卖个菜也请个经纪人把，滚…。

写代码也一样，你和同事A各写了一个类，有一天你同事A的类方法做了一下变动。
如果你直接调用了他的那个类，那就懵逼了，你也得跟着改代码，不然程序就要出问题。
如果你的类通过另外一个同事B的中转类调用的，那你就可以继续逛B站了，让同事B去处理这烂摊子。

设计模式分类

设计模式可以分为创建型、结构型、行为型三个类模式。

创建型模式

对类的实现化过程进行了抽象，能够使软件模块做到与对象的创建和组织无关。
主要包括以下模式：

Factory 工厂模式
AbstactFactory 抽象工厂模式
Builder 建造者模式
Singleton 单例模式
Protopye 原型模式

结构型模式

描述类和对象之间如何进行有效的组织，以形成良好的软件体系结构，主要的方式是使用继承关系来组织各个类，一个最容易的例子就是如何用多个继承组织两个以上的类，结果产生的类结合了父类所有的属性，结构型模式特别适用于和独立的类库一起工作。
主要包括以下模式：

Adapter 适配器模式
Brigde 桥接模式
Decorator 装饰模式
Composite 组合模式
Facade 外观模式
Flyweight 享元模式
Proxy 代理模式

行为型模式

描述类和对象之间如何交互及如何分配职责，实际上它所牵涉的不仅仅是类或对象的设计模式，还有它们之间的通信模式。
主要包括以下模式：

Template 模版模式
Commond 命令模式
Iterator 迭代器模式
Observer 观察者模式
Mediator 中介者模式
Memento 备忘录模式
Interpreter 解释器模式
State 状态模式
Strategy 策略模式
Chain of Responsibility 责任链模式
Visitor 访问者模式