🐻白话对设计模式六大原则的理解

1,881 阅读2分钟

2020.06.11 本文可能存在误导,待我总结后更新

想到设计原则,猛地被一问,竟然答不上来。设计原则十分重要,对于小的app来说,每个页面或者功能不复杂,你会觉得设计模式没什么用,可一旦工程庞大起来,最后能救你的就是设计模式了。

抛转引玉,我先白话一遍对六大原则的理解:

来solo吧,需要各种观点碰撞。

设计模式的六大原则:

1. 单一职责:

简单来说:模块的划分要尽可能单一,类的职责最好要单一,函数的功能一定要单一

2.开放封闭原则:

  • 封闭底层和较底层逻辑

    • 如:lottie 中 动画是如何显示的,json是如何解析的,执行的

    • 如:GPUImage 中 滤镜链是如何执行的,shader是如何使用的

  • 开放具有扩展性的逻辑

    • 如:lottie 中 暴露的使用方法,组合方法,可自由扩展的方法、类、协议
    • 如:GPUImage 中 暴露的lookup滤镜、马赛克滤镜

我们发现一点:

封闭的东西是内部构造,一般情况下,使用者不必担心,也不必明白原理,也比较复杂 开放的东西是暴露的,一般情况下会多次使用,使用者通过api就能组合出来前边万化的结果

写SDK和模块的人应该对这个比较清晰,也适用于SDK和模块的设计

3.里式替换原则

搞继承关系时,要慎重。如果子类不能完整地实现父类的方法,或者父类的某些方法在子类中已经发生“畸变”,则建议断开父子继承关系 采用依赖、聚合、组合等关系代替继承

4.依赖倒置原则

高级模块A 不要对低级模块B的产生了严重依赖,生活没办法自理;其实高级依赖低级这是必然的,但别搞得高级模块对低级模块依赖特别大,高级模块也要有应对低级模块的异常的处理能力。

这个原则是开闭原则的基础,具体内容:针对接口编程,依赖于抽象而不依赖于具体

5.接口隔离原则

W的内部有很多私有方法、暴露给外界什么,外界就用什么

6.最少知识原则

类A或模块A提供的api不满足B的需求,需要反复组合,这时候就需要一个中间类C,用来协调A和B的关系,A开心,B也开心,C就是和事佬

总结

这些原则可以相互补救,原则并非是一层不变的,当软件架构出现设计不合理时,这些思想将指导你对当前架构进行整改补救。