优雅的设计模式之旅-开闭原则

本文主要是介绍优雅的设计模式之旅-开闭原则，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

开篇致词

最近有很多小伙伴私信问我，如何能书写出高逼格让人一看就觉得是一个好程序员写得代码呢？什么样得代码是标准得代码呢？怎样成为团队中代码标准呢？…等等咨询一些前端代码书写方面得问题，因此我们我们开始设计模式之旅。

心态

++好的代码像粥一样,都是用时间熬出来的++

背景介绍

在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据 7 条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。我们将在下面的几节中依次来介绍这 7 条原则，本节首先介绍开闭原则。

开闭原则

什么是开闭原则？

• 全称:开闭原
• 简称:ocp(Open Closed Principle)
• 定义: 软件实体(项目中划分出的模块,类与接口,方法…等等)应该是可拓展的

怎么理解开闭原则中的开闭？

• 开-> 即对软件实体的拓展是开放的
  对于某个模块的功能时可以进行拓展的。当需求改变，我们只需对其扩展即可满足于新的需求
  举个例子
  比如"砖"是我们已经封装好的类，这个类我们不需要改变他的形态与结构，我们只是根据需求来建高楼或者建围墙。所以可以认为"砖"是对扩展的需求是开放的。
• 闭-> 即对软件实体中的更改是封闭的
  对模块进行扩展时，不必改动模块的源代码或者二进制代码。如果说这个模块已经明确的定义，稳定高效的被多个其他模块使用，那么关系这个模块，提供接口供替它模板使用。
  举个例子
  比我我们的笔记本是由CPU，主板，内存等构成的，他们并不是紧紧耦合在一起的。如果是紧紧耦合在一起相当于串联，那么一出坏了真个都不好使都需要重新购买电脑显然是不合理的。所以当我们的内存坏掉的时候，我们只需要更还内容就可以重新使用类似与并联当前节点损坏并不影响其他节点。

开闭原则的含义？

• 当应用的需求发生改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求

开闭原则的作用及其意义(为什么要遵循开闭原则)？

开闭原则是面向对象程序设计的终极目标，他是软件实体拥有一定的实用性和灵活性的同时具备稳定性和延续性.

• 对软件测试的影响
  软件遵循开边原则的话，软件测试只需要对拓展的代码进行测试就可以了，因为原油的测试代码仍然能够正常运行
• 可以提高代码的可复用性
  粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。
• 可以提高软件的可维护性
  遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护

开闭原则的实现(怎么实现开闭原则)

抽象约束

设计原则和面向对象编程思想其实是相辅相成的，起都会由抽象、封装、继承、多态。抽象是对一组事物的通用描述，没有具体的实现，也就表示他可以有非常多的可能性，可以随需求的变化而变化。因此，通过接口或者抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其中三层含义:

• 通过接口或者抽象类约束扩散，对扩展进行边界限定，不允许出现在接口或者抽象类中不存在的公共方法。
• 参数类型，引用对象尽量使用接口或抽象类，而不是实现类，这主要是仙仙里氏替换原则的一个要求(后期文章更新)
• 抽象层尽量保持稳定，一旦确定就不要修改

元数据控件模块行为

编程是一个苦力活，同样程序员也是一个很会偷懒的工种。优秀的程序员会尽量使用元数据来控制程序，减少重复开发。什么是元数据？用来描述环境和数据的数据，通俗的来说就是配置参数，参数可以从文件中获得，也可以在数据库中获得

团队项目约定

在一个团队中，建立项目标准很重要的，因为标准是所有开发人员都必须遵守的约定，对于项目来说，约定优于配置。这比通过接口或抽象类进行约束效率更高，而对于扩展性没有一丝的影响。

深刻理解封装变化

对变化封装包括两层含义(同样不能因为抽样而抽象，坏的抽象比不抽象更难受)

• 将相同的变化封装到一个接口或者抽象类中
• 将不同的变化封装到不同的接口或抽象类中，不应该有两个不同变化出现在同一个接口或抽象类中。封装变化，也就是受保护的变化，找出预计有变化或者不稳定的点，我们为这些变化点创建稳定的接口

面对开发(使用场景)

• 需求：商品列表中，如果是男装类型，商品背景色使用蓝色 ，点击之后弹出男装价格；如果是女装，商品背景色使用红色，点击后弹出女装品牌。

普通代码(面向过程开发)

if (commodity.type === ‘男装‘) {commodity.css(background, blue); 
} else { commodity.css(background, red); } 
// 点击事件的函数中 
if (commodity.type === ‘男装‘) { // 弹出价格 alert(commodity.price); 
} else { // 弹出品牌alert(commodity.brand); 
}

• 需求的改动: 产品小妹妹跑过来告知添加一种商品类型，童装，商品背景色使用黄色，点击之后弹出童装的销量。

if (commodity.type === ‘男装‘) { commodity.css(background, blue); 
} else if (commodity.type === ‘女装‘) {// 修改点1 增加女装类型判断 commodity.css(background, red); 
} else { // 修改点2 增加童装html渲染处理 commodity.css(background, yellow); 
} 
// 点击事件的函数中 
if (commodity.type === ‘男装‘) {// 弹出价格 alert(commodity.price); 
} else if (commodity.type === ‘女装‘) { // 修改点3 增加女装类型判断 // 弹出价格 alert(commodity.brand);
} else { // 修改点4 增加童装点击处理 // 弹出销量 alert(commodity.sales); 
}

已上代码的写法国估计会有很多的小伙伴去这样书写,其实小伙伴们心理也很慌，第一觉得代码没有技术度，第二再新增需求呢我依旧这么加判断么？第三怎么能做到不用怎么修改代码 让自己轻松一些呢？

那么我们就来看看按照这样的需求写一个符合开闭原则的代码让大家感受一下

// 抽象封装getManager
function getManager(commodity){if (commodity.type === ‘男装‘) return MaleManager; if (commodity.type === ‘女装‘) return FemaleManager;
}
let MaleManager = { Settingbackground: function () { commodity.css(background, blue); }, Prompt: function () { // 弹出价格 alert(commodity.price); } 
}; 
let FemaleManager = { Settingbackground: function () { commodity.css(background, red); }, Prompt: function () { // 弹出品牌 alert(commodity.brand);} 
};

OK,代码量好像多了，多了几个对象和方法。。。但是大家有没有觉得代码的可阅读性有所提高，逼格程度方面是不是比上面的看着好一点；好那么现在可爱的产品妹妹又来提需求了–>“要求加一个童装”

// 抽象封装getManager
function getManager(commodity){if (commodity.type === ‘男装‘) return MaleManager; if (commodity.type === ‘女装‘) return FemaleManager;if (commodity.type === ‘童装‘) return ChildManager;
}
let MaleManager = { Settingbackground: function () { commodity.css(background, blue); }, Prompt: function () { // 弹出价格 alert(commodity.price); } 
}; 
let FemaleManager = { Settingbackground: function () { commodity.css(background, red); }, Prompt: function () { // 弹出品牌 alert(commodity.brand);} 
};
let ChildManager = { Settingbackground: function () { commodity.css(background, yellow);}, Prompt: function () { // 弹出销量 alert(commodity.sales); } 
};

我们可以看到，对于业务中原有的男装女装的需求我们不需要进行修改，因此我们进行了封闭处理，同时我们需要扩展一个童装，按照开闭原则设计后的代码，修改点只有一处，修改的地方也可以预判，修改路由方法getManager即可（此处修改其实可以避免）；然后新增一个童装manager即可。

总结

其实写代码还是我的那句标语：好的代码像粥一样,都是用时间熬出来的!因此当我们接到业务需求的时候一定要学会多思考，认真的思考的时候再去书写代码；对于业务我们一定要开好需求会，认真的了解业务需求，进而方便自己更好的抽象分析业务，也便于我们在封装的时候更清楚的知道那是是变化的那些是不变的 那些是封闭的那些是要拓展的…设计模式是一个化妆包都是程序员就要看你怎么化妆了…

为了帮助大家让学习变得轻松、高效，给大家免费分享一大批资料，帮助大家在成为全栈工程师，乃至架构师的路上披荆斩棘。在这里给大家推荐一个前端全栈学习交流圈：??947552909.,或者?wx:fxq1221623?欢迎大家进群交流讨论，学习交流，共同进步。

有些人对学习充满激情，但是缺少方向，而在浩瀚的知识海洋中看似无边无际，此时最重要的是要知道哪些技术需要重点掌握，避免做无用功，将有限的精力及状态发挥到最大化。

最后祝福所有遇到瓶颈且不知道怎么办的前端程序员们，祝大家在往后的工作与面试中一切顺利。

这篇关于优雅的设计模式之旅-开闭原则的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---