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

本文主要是介绍软件设计模式，给你解决问题的标准答案，少走弯路，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

设计模式简介

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

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

这篇关于软件设计模式，给你解决问题的标准答案，少走弯路的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---