wordpress查看自己网站的ip量,做网站要不要交税,dw怎样制作网页,wordpress怎么跳转到别的域名文章目录 开闭原则里氏替换原则依赖倒置原则单一职责原则接口隔离原则迪米特原则总结 开闭原则
核心就一句话#xff1a;对扩展开放#xff0c;对修改关闭。
针对的目标可以是语言层面的类、接口、方法#xff0c;也可以是系统层面的功能、模块。当需求有变化的时候#… 文章目录 开闭原则里氏替换原则依赖倒置原则单一职责原则接口隔离原则迪米特原则总结 开闭原则
核心就一句话对扩展开放对修改关闭。
针对的目标可以是语言层面的类、接口、方法也可以是系统层面的功能、模块。当需求有变化的时候尽量不要动已经存在的核心代码而是围绕核心代码做扩展升级。所以在最开始的代码设计阶段就应该适当考虑以后可能存在的扩展点预留一定的可扩展空间。
遵循这条设计原则就是要保证新增特性的时候尽量不影响已有的功能提高系统的稳定性。
但是从长远来看系统迭代发展到一定阶段早期的设计和实现未必能满足现阶段的需求有可能还会成为阻碍前进的障碍。这个时候就要考虑系统重构了不要再顾虑开闭原则不破不立。
里氏替换原则
里氏替换主要是讲继承和多态的设计原则设计父子关系的时候必须确保父类特性完全适用于子类。
通俗的解释就是子类可以在父类的基础上新增和扩展功能但绝对不要改变父类的基础本意。也就是说子类可以新增独属于子类的方法和功能也可以扩展细化父类提供的方法和功能但就是不要违背父类的意志。
设计继承最根本的目的是为了运行时能够多态替换其基础就是父子类具有相同的特性父类出现的地方可以被子类替代。
依赖倒置原则
讲的是分层系统设计层与层之间如何依赖的问题。
在以前的设计架构中通常做法是高层模块依赖底层模块先对底层模块进行独立设计和实现然后让高层模块引入底层模块完成相关功能。慢慢的就会发现其中一些问题
底层模块的独立性更高但是底层模块发生变动很有可能会影响到高层模块高层模块的复用性更高别的地方引入高层模块就必须级联引入底层模块这会使复用变的复杂
为了解决这些问题就提出了依赖倒置原则反过来让底层模块依赖高层模块。由高层模块定义出抽象层接口由底层模块实现这些接口。
也就是说高层模块和底层模块都依赖于抽象层接口这样做的好处
高层模块只需依赖于抽象层接口复用将会变的简单底层模块不会被级联引入底层模块也只依赖于抽象层接口高层模块不变的情况下替换底层模块将会变的容易
各种数据库驱动设计就是一个典型的依赖倒置原则应用。
单一职责原则
这里是讲编程颗粒度的问题小到一个类和接口大到一个功能模块都应该有且仅有一类变化因素如果有很多不同的变化因素就应该拆分颗粒度直至它的变化因素唯一这就是单一职责。
如果一个颗粒度有太多的变化因素可能会存在一些问题
职责太多职责之间可能会相互影响任何一个职责变化都可能引发其它职责随之变化牵一发而动全身外界使用这个颗粒度就必须引入全部职责无论是否需要这会造成职责冗余还加深了非必要的联系
单一职责的核心就是颗粒度拥有合适的职责提高代码实现的内聚性和灵活性。原则比较容易理解但是想要拆分出适合的颗粒度还是很考验开发人员的分析设计能力和相关重构经验的。
接口隔离原则
核心思想就是要面向接口编程不要面向实现编程。
无论是小功能还是大模块都应该隐藏内部的代码实现对外提供访问接口通过接口声明它可以做的事情功能之间、模块之间都通过接口进行交流。
这样做的好处就是内部实现代码是高内聚的可以灵活调整和变通只要接口层是稳定不变的关联方就是无感知的也就无需随之调整。
接口代表概念和逻辑是抽象的通常来讲概念和逻辑是明确的概念和逻辑的代码实现方式是千变万化的。所以做系统设计的时候首先要明确相关概念和逻辑先用抽象层完成系统架构再去依赖抽象层进行代码实现。
迪米特原则
形象的说法只与你的朋友交谈不要跟陌生人说话。
朋友是指熟悉可信任的对象小到某个类和接口大到功能模块系统彼此可以直接调用和交流的都是朋友。
如果两个对象之间有交流的需求但是又无法直接交流或者不适合直接交流就应用引入一个第三方作为中介专门负责两边的沟通和联系。好处就是两边的模块都能保持各自的独立性彼此的差异由中介去兼容和解决。
迪米特原则是系统间解耦的一种好思路但是凡事都要有个度过犹不及如果引入了太多第三方中介必然会增加系统链路之间的节点和长度降低系统性能和稳定性并且消息泄漏风险也会大幅增加。
总结
六大设计原则是前辈们总结出来的指导思想合理灵活的运用能帮助我们构建出优秀的系统。但千万不要唯命是从每个系统都有自己的重点和独特之处结合实际情况完成设计和实现取舍有度适合自己的才是最好的。
