设计原则小记
发布日期:2022-04-05 00:52:15 浏览次数:3 分类:博客文章

本文共 1294 字,大约阅读时间需要 4 分钟。

设计原则大家都不陌生,现在简介下自己的简介

设计模式是设计原则的实现,所有设计原则最终都是为了 高内聚低耦合

设计原则共有7种 下面从理解、总结、场景三个角度简单阐述下自己简介

 

S 单一职责原则

理解:不同的类具备不同的职责,各司其职。做系统设计时,如果发现有一个类拥有了两种职责,那么就要问一个问题:可以将这个类分成两个类吗?如果真的有必要,那就分开,千万不要让一个类干的事情太多

总结:一个类只承担一个职责

场景:单个类 职责单一

0 开闭原则

理解:类、模块、函数,可以去扩展,但不要去修改。如果要修改代码,尽量用继承或组合的方式来扩展类的功能,而不是直接修改类的代码。当然,如果能保证对整个架构不会产生任何影响,那就没必要搞的那么复杂,直接改这个类吧。

总结:对类的的改动,最好用扩展而非修改的方式。(对已创建类,尽量避免改动—闭。取而代之的是继承或者扩展或者协议—开)

场景:单个类 对类的修改尽量避免本类的修改 用扩展或继承来达到修改的目的

L 里氏替换原则

理解:一个对象在其出现的任何地方,都可以用子类实例做替换,并且不会导致程序的错误。换句话说,当子类可以在任意地方替换基类且软件功能不受影响时,这种继承关系的建模才是合理的。 总结:子类可以扩展方法,但不应该重写父类的方法。

场景:继承 子类尽量不重写父类的方法 只是使用功能

I 接口隔离原则

理解:一个类实现的接口中,包含了它不需要的方法。将接口拆分成更小和更具体的接口,有助于解耦,从而更容易重构、更改。

总结:对象不应被强迫依赖它不使用的方法。 对我们来说主要是协议中方法注意opttion 标记。 非必要 不声明( 扩展:类.h文件中不需要外界知道的不暴露)

场景:协议 、类.h文件 避免臃肿

D 依赖倒置原则

理解:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。

总结:面向接口编程,提取出事务的本质和共性。通用方法或者基类(高层)尽量避免 依赖底层模块(具体业务)二者之间应该有中间件(抽象层/接口层)

场景:类与类之间 要发生关联的类 保证高层的 独立 重点在强调高低依赖

L 迪米特法则

理解:一个对象对另一个对象了解得越多,那么,它们之间的耦合性也就越强,当修改其中一个对象时,对另一个对象造成的影响也就越大。

总结:一个对象应该对其他对象保持最少的了解,实现低耦合、高内聚。低耦合高内聚

场景:类与类之间 跟D比较相似 (D强调的是高低的依赖问题,而这个就是强调类与类之间,该法则包含D)

C 组合/聚合复用原则

理解:合成/聚合复用原则就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过向这些对象的委派达到复用已有功能的目的。它的设计原则是:要尽量使用合成/聚合,尽量不要使用继承。

总结:就是说要少用继承,多用合成关系来实现。继承复用有一定的缺点:比如如果基类发生了改变,那么派生类的的实现就不得不发生改变。使用组合/聚合复用原则就解决了继承复用的缺点。也就是组件化

场景:各个组件高度独立 彼此能够相互组合

参考资料:

 

转载地址:https://www.cnblogs.com/lijianyi/p/11855218.html 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:iOS 获取webview高度小结
下一篇:iOS13 新特性小结

发表评论

最新留言

路过,博主的博客真漂亮。。
[***.116.15.85]2024年04月13日 00时16分20秒