苏州企业网站设计企业,自主网站,西安网站制作顶尖,大屏手机网站本文是阅读《设计模式之美》的总结和心得#xff0c;跳过了书中对面试和工作用处不大或不多的知识点#xff0c;总结总共分为三章#xff0c;分别是面对对象编程范式、设计原则和设计模式。 设计模式是代码设计时的一些经验总结。相比于设计模式#xff0c;设计原则更抽象。… 本文是阅读《设计模式之美》的总结和心得跳过了书中对面试和工作用处不大或不多的知识点总结总共分为三章分别是面对对象编程范式、设计原则和设计模式。 设计模式是代码设计时的一些经验总结。相比于设计模式设计原则更抽象。
单一职责原则SRP
一个类或模块只负责完成一个职责。 例如某个类既包含对订单的一些操作又包含对用户的一些操作。而订单和用户是两个独立的业务领域模型将两个不相干的功能放到同一个类中就违反了单一职责原则。
开闭原则OCP
开闭原则告诉我们在设计功能模块的时候要留扩展点在未来进行需求变更时不需要改动代码的整体结构新的代码能够灵活地插入到扩展点完成需求变更从而实现代码的最小化改动。 同时新增代码要比修改原有代码引入新 bug 的概率更小基本所有的行为型设计模式都提供了扩展点。
里氏替换原则LSP
子类对象能够替换到程序中父类对象出现的任何地方并且保证程序原有的逻辑行为不变和正确性不被破坏。 里氏替换原则乍一看好像和多态特性没有什么区别因为多态的定义就是在程序运行的过程中我们可以用子类替换父类并调用子类的方法。里氏替换原则规定子类除了可以替换父类之外子类不能违反父类对输入、输出和异常的约定比如父类中的方法注释中注明方法不会抛出异常返回值不会为 null而子类重写父类方法后会抛出 RuntimeException 异常并且返回值可能为 null。这就违反了里氏替换原则子类替换父类后可能给程序引入错误。还有一种场景子类完全改变了父类的代码逻辑如父类中是按时间排序子类中却按大小排序。这也是违反里氏替换原则的。
接口隔离原则ISP
客户端不应该被强迫依赖它不需要的接口。 接口隔离原则和单一职责原则关系密切满足单一职责原则的类不一定满足接口隔离原则因为单一职责原则关注类自身实现的业务职责是否单一而接口隔离原则关注客户端如果客户端依赖的接口可以访问到它不需要的方法说明客户端被强迫依赖了它不需要的接口此时我们需要继续对接口细分让接口满足接口隔离原则。
依赖反转原则DIP
高层模块不要依赖底层模块高层模块和底层模块应该通过抽象互相依赖。 提到依赖反转我们会联想到控制反转IOC和依赖注入DI。控制反转讲的是原来由程序员手动控制的模板代码变成由框架控制这里说的模板代码可以是程序流程的控制、对象的创建等。因此控制反转并不是一种具体的实现技巧而是一种比较笼统的设计想法一般用来指导框架的设计。依赖注入是指不通过 new 的方式在类内部创建依赖的类对象而是将依赖的类对象在外部创建好之后通过构造函数、函数参数等方式传递给类使用。
KISS原则
KISS原则的英文描述是Keep It Simple and Stupid。中文释义是保持代码简单和愚蠢。 我们知道代码的可读性是衡量代码质量的两个重要标准。而 KISS 原则就是保持代码可读和可维护的重要手段。代码足够简单也就意味着容易读懂bug 比较难隐藏即使出现 bug修复也比较简单。 对于如何写出满足 KISS 原则的代码有两个方面
不要重复造轮子首先考虑使用已有类库。不要过度设计。尽量避免使用一些 “奇技淫巧”比如位运算复杂的条件语法等。
DRY 原则
DRY 原则Don’t Repeat Yourself翻译成中文是不要编写重复的代码。 满足 DRY 原则其实间接让我们提高了代码的复用性因为代码复用性高重复的代码自然就少了。
迪米特原则LoD
迪米特原则又称为最少知识原则。它规定不应该存在直接依赖关系的类之间不要有依赖有依赖关系的类之间尽量只依赖必要的接口。 迪米特原则表述的后半部分其实就是接口隔离原则。这条原则能够帮助我们实现代码的 “高内聚低耦合”。 “高内聚” 用来指导类本身的设计指的是相近的功能应该放在同一个类中不相近的功能不要放在同一个类中。 “低耦合” 用来指导类之间依赖关系的设计。指的是在代码中类之间的依赖关系要简单、清晰。即使两个类有依赖关系一个类的代码的改动不会或很少导致依赖类的代码的改动。
