设计模式 | 瞎说什么大实话

Posted 2021-04-25 肥犊大人

简单来讲，设计模式就是，对我们开发人员来讲，为了解决一些特定问题我们采用的通用方案。

这是前任，不对！是前人积累的开发经验，代码设计的总结，在工作中灵活应用，优化程序结构，站在巨人的肩膀上使得避免我们这些后辈们再踩坑、入坑。

说到底，还是为了代码更好的维护、扩展、有弹性，复用，可读

不然的话...

领导让你新增功能，还是继续搬砖，往上堆代码？

不然你让你的同事、或者刚来的小学弟、小学妹改你的代码怎么办？

面试官问你设计模式一脸懵懂？

软件工程中，设计模式(design pattern)是对软件设计中普遍存在(反复出现) 的各种问题，所提出的解决方案。这个术语是由埃里希·伽玛等人 在1990年代从建筑设计领域引入到计算机科学的

在设计我们的程序结构时，就像建筑设计师在设计他既将要建的大楼，要考虑如何打地基、房子的结构设计、用料......等，总不能盖了一半，拆了再建...(不过可以增加就业、增加GDP)

设计模式中有几大原则

单一原则

能切菜，又能装手机的是什么鬼！！！

降低类的复杂度，一个类负责一项职责；

提高可读性，可维护性，降低变化出bug的风险

通常应当遵循单一原则，但如果逻辑简单，方法可以处理多个职责

封装变化

既有共同点，又有不同点，要怎么封装使用？

封装变化部分和不会变化部分，类之间的依赖关系中，对比它们的异同点，把变化的部分从中独立出来

高内聚、低耦合

高内聚是指一个模块里面的内容有很强的相关性

低耦合是指不同模块之间减少他们的相关性，尽量保持单一原则，避免一个模块出错也引起另一个模块的出错

开闭原则

对提供者扩展代码开放，对使用者修改代码关闭

依赖倒置原则

  

   目录和正文的关系

中心思想是面向接口编程，使用接口或抽象类的目的是，制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

细节依赖于抽象，抽象不依赖于细节，以抽象为基础搭建的架构比以细节为基础的架构要更加稳定

里氏替换原则

里氏替换原则在1988年，由麻省理工学院的以为姓里 的女士提出的。

如果对每个类型为T1的对象t1，都有类型为T2的对象t2，使得以T1定义的所有程序 P在所有的对象t1都代换成t2时，程序P的行为没有发生变化，那么类型T2是类型T1 的子类型

里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题

使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法

最少知道法则

一个对象应该对其他对象保持最少的了解

类与类关系越密切，耦合度越大，其中一个改动，很可能引起另一个变化

对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内

保持简单原则

简单、高效让人好理解、又不影响性能，才是编程的魅力。simple is power！

下图是23种设计模式

好了，今天就到这了

下次再来讲讲设计模式种的具体模式

喜欢我就关注我吧