软件设计开发原则
1、 单一职责原则
一个方法只做一件事。
描述
我们在平时维护项目时,总会深入具体执行函数修改代码,有的函数非常庞大做了很多的事,这个时候改动的地方将会非常的多,我们还要去考虑改动的地方有没有其他业务的关联,非常危险。
单一职责原则就是指导我们将项目中的业务抽象出来,根据各个职责将函数和对象拆分为更小的颗粒度,这样在维护的时候可以保证尽可能少的深入函数修改代码,还更有利于代码的复用。
在项目中也不一定所有的职责都要拆分,如果一个职责和另外一个职业有依赖关系,其中一个职责改变总会引起另一个的变化,此时然他们纠缠在一起也是一个不错的选择,所以我们在使用的时候根据具体的场景灵活运用。
实例模式
在设计模式中符合单一原则的模式:
2、 最少知识原则
只和最亲密的主体联系。
描述
在平时开发中会创建大量的对象、方法、变量等,随着项目的迭代越来越多的对象之间可能会产生错综复杂的联系,一个对象改变可能会引起其他相关联的对象也发生改变。最少知识原则就是我们在使用这些创建的对象时尽可能的减少当前对象和其他对象之间的联系,如果不是必须要联系的,就直接不联系。如果必须要深度联系的可以引入第三方对象承担这些对象间的通信。
有些时候即使模块间需要通信也会采用封装的方式将他们隔离开来,只暴露出有限的api可以进行通信,将所有的内部细节、变量等全部隐藏,其他对象不需要了解内部是怎么实现的同时还避免了内部变量对其他对象造成污染。
实例模式
在设计模式中符合单一原则的模式:
3、 开放封闭原则
软件中的模块、对象、函数等可以被扩展,但是不可修改。
描述
在平时开发中经常会遇到需要在一个函数之中增加自己逻辑的需求,最直接的方式当然是直接进入到函数中进行修改,但是直接在原函数中直接修改代码并添加大量的逻辑是一件很危险的事,可能会引起特定场景下才能复现的问题,所以最好的方式应该是不修改原来的任何代码,通过函数引用替换的方式来扩展我们的代码。
在函数中还有许多有if else判断语句,每增加一种场景就需要进入函数中修改才能增加当前场景下的代码,这样同样也是非常危险的,我们应该找出变化的地方,然后根据场景将不同的逻辑封装为不同的函数,这样在增加新场景的时候我们只需要增加改场景下函数即可,而不用去修改原来的代码。
事实上我们不可能将所有变化做到完全封闭和开放,总有许多逻辑需要深入去修改,但是我们可以尽可能的 挑选出最容易发生变化的地方,然后抽象出来封闭这些变化。当在不可避免发生修改的时候,尽量修改那些相对容易修改的地方。
实例模式
在设计模式中符合单一原则的模式:
上面几种软件开发原则,就像是一种根据经验总结出来的指导,即使完全不使用上述原则也完全不耽误我们对需求的实现,但是用了这些原则不但会增加我们抽象结构的能力,更加易于维护和扩展我们的项目。但是也要注意指导它不是规则也不是公式,他们不能适用于所有的开发场景,我们更多的是借鉴他们的思想,在合适的场景下灵活的使用不同的原则,而不是生搬硬套。