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

曾经终败给现在 2023-06-30 08:56 10阅读 0赞

## 设计模式简介 ##

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

*  设计模式针对的都是面向对象的编程语言，如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 访问者模式