不少人应该据说过设计模式(Design pattern),又或多或少的看过或用过设计模式,可是实际用在开发过程当中总有点爱莫能助的感受。那确定是对设计模式的理解有少量误差或者不够深刻。先不谈某种具体的模式,先来看看什么是设计模式?编程
从概论结合实际场景分析设计模式
设计模式是一套代码设计「经验的总结」。项目中「合理的」运用设计模式能够「巧妙的解决不少问题」。学习
经验的总结:抱着「代码虐我千百遍,我待代码如初恋」的心态,最终得出来的「套路」。spa
合理的:要对设计模式的使用场景有必定的认识后才使用,「不要滥用」。如:输出一句“hello world”,非要强行给加上各类模式。
问:“为何”,答:“总感受少了模式!”。设计
巧妙的解决了不少问题:被普遍应用的缘由。htm
为何要提倡“Design Pattern呢?根本缘由是为了代码复用,增长可维护性。那么怎么才能实现代码复用呢?对象
1988年,勃兰特·梅耶(Bertrand Meyer)在他的著做《面向对象软件构造(Object Oriented Software Construction)》中提出了开闭原则,它的原文是这样:“Software entities should be open for extension,but closed for modification”。继承
意思:软件模块应该对扩展开放,对修改关闭。接口
举例:在程序须要进行新增功能的时候,不能去修改原有的代码,而是新增代码,实现一个热插拔的效果(热插拔:灵活的去除或添加功能,不影响到原有的功能)。ip
目的:为了使程序的扩展性好,易于维护和升级。
意思:里氏代换原则是继承复用的基石,只有当衍生类能够替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也可以在基类的基础上增长新的行为。
举例:球类,本来是一种体育用品,它的衍生类有篮球、足球、排球、羽毛球等等,若是衍生类替换了基类的本来方法,如把体育用品改为了食用品(那么软件单位的功能受到影响),就不符合里氏代换原则。
目的:对实现抽象化的具体步骤的规范。
意思:针对接口编程,而不是针对实现编程。
举例:以计算机系统为例,不管主板、CPU、内存、硬件都是在针对接口设计的,若是针对实现来设计,内存就要对应到针对某个品牌的主板,那么会出现换内存须要把主板也换掉的尴尬。
目的:下降模块间的耦合。
使用多个隔离的接口,比使用单个接口要好。
举例:好比:登陆,注册时属于用户模块的两个接口,比写成一个接口好。
目的:提升程序设计灵活性。
1987年秋天由美国Northeastern University的Ian Holland提出,被UML的创始者之一[Booch]等普及。后来,由于在经典著做《 The Pragmatic Programmer》而广为人知。
意思:一个实体应当尽可能少的与其余实体之间发生相互做用,使得系统功能模块相对独立。
举例:一个类公开的public属性或方法越多,修改时涉及的面也就越大,变动引发的风险扩散也就越大。
目的:下降类之间的耦合,减小对其余类的依赖。
该原则由罗伯特·C·马丁(Robert C. Martin)于《敏捷软件开发:原则、模式和实践》一书中给出的。马丁表示此原则是基于汤姆·狄马克(Tom DeMarco)和Meilir Page-Jones的著做中的内聚性原则发展出的。
意思:一个类只负责一个功能领域中的相应职责,或者能够定义为:就一个类而言,应该只有一个引发它变化的缘由。
举例:该原则意思简单到不须要举例!
目的:类的复杂性下降,可读性提升,可维护性提升。
刚入行的时候,在想什么样的代码是好代码?看到不少前辈的文字都说好的代码要符合「高内聚,低耦合」,可是我听到这样的解释,是这样的
而如今对设计模式有了必定程度上的学习,感受懂了一些,小伙伴们大家学会了吗?
内聚是从功能角度来度量模块内的联系,一个好的内聚模块应当刚好作一件事。它描述的是模块内的功能联系;
耦合是软件结构中各模块之间相互链接的一种度量,耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及经过接口的数据。