设计模式 - 设计原则

目录

• 设计模式
  • 设计原则
    • 单一职责原则 SRP(Single Responsibilities Principle)
    • 接口隔离原则 ISP(Interface Segregation Principle)
    • 依赖倒置原则 DIP(Dependence Inversion Principle)
    • 里式替换原则 LSK(Liskov Substitution Principle)
    • 开闭原则 OCP(Open Close Principle)
    • 迪米特法则 DP (Demeter Principle)
  • UML
  • 设计模式类型
    • 建立型模式
    • 结构型模式
    • 行为型模式
    • JavaEE模式

---

设计模式

设计原则

在面向对象设计模式中存在的是五大原则和一个法则。

• 单一职责原则 SRP(Single Responsibilities Principle)
• 接口隔离原则 ISP(Interface Segregation Principle)
• 依赖倒置原则 DIP(Dependence Inversion Principle)
• 里氏替换原则 LSK(Liskov Substitution Principle)
• 开闭原则 OCP(Open Close Principle)
• 迪米特法则 DP (Demeter Principle)

单一职责原则 SRP(Single Responsibilities Principle)

# 1.单一职责原则
- 参考文档:https://baike.baidu.com/item/%E5%8D%95%E4%B8%80%E8%81%8C%E8%B4%A3%E5%8E%9F%E5%88%99/9456515?fr=aladdin

- 一个类只负责一项职责。

# 2.单一职责优势
- 下降类的复杂度，一个类只负责一个职责。这样写出来的代码逻辑确定要比负责多项职责简单得多。

- 提升类的可读性，提升系统的可维护性。

- 下降变动引发的风险。变动是必然的，若是单一职责原则遵照得好，当修改一个功能的时候能够显著下降对其余功能的影响。

须要说明的一点是，单一职责原则不仅是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。好比说单一职责原则不只仅适用于类，还适用于方法。

# 3.单一职责注意事项
一般状况下，咱们应当遵照单一职责原则，只有逻辑足够简单，才能够在代码级违反单一职责原则；只有类中方法数量足够少，能够在方法级别保持单一职责原则。

接口隔离原则 ISP(Interface Segregation Principle)

# 1.接口隔离原则
- 参考文档:https://baike.baidu.com/item/%E6%8E%A5%E5%8F%A3%E9%9A%94%E7%A6%BB%E5%8E%9F%E5%88%99/3104602?fr=aladdin

- 一个类对另外一个类的依赖应该创建在最小的接口上。

- 一个接口表明一个角色，不该当将不一样的角色都交给一个接口。没有关系的接口合并在一块儿，造成一个臃肿的大接口，这是对角色和接口的污染。

- “不该该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，若是强迫用户使用它们不使用的方法，那么这些客户就会面临因为这些不使用的方法的改变所带来的改变。

依赖倒置原则 DIP(Dependence Inversion Principle)

# 1.倒转依赖原则
- 参考文档:https://baike.baidu.com/item/%E4%BE%9D%E8%B5%96%E5%80%92%E7%BD%AE%E5%8E%9F%E5%88%99/6189149?fr=aladdin

- 程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就下降了客户与实现模块间的耦合。

- 高层模块不该该依赖低层模块，两者都应该依赖其抽象。

- 抽象不该该依赖细节，细节应该依赖抽象。

- 依赖倒转(倒置)的中心思想是面向接口编程。

- 依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类，细节就是具体的实现类。

- 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操做，把展示细节的任务交给他们的实现类去完成。

# 2.倒转依赖方式
- 接口传递

- 构造方法传递

- setter方式传递

# 3.倒转依赖注意事项
- 低层模块尽可能都要有抽象类或接口，或者二者都有，程序稳定性更好。

- 变量的声明类型尽可能是抽象类或接口, 这样咱们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化。

- 继承时遵循里氏替换原则。

里式替换原则 LSK(Liskov Substitution Principle)

# 1.里式替换原则
- 参考文档:https://baike.baidu.com/item/%E9%87%8C%E6%B0%8F%E6%9B%BF%E6%8D%A2%E5%8E%9F%E5%88%99/3744239?fr=aladdin

- 继承在给程序设计带来便利的同时,也带来了弊端。好比使用继承会给程序带来侵入性,程序的可移植性下降,增长对象间的耦合性,若是一个类被其余的类所继承,则当这个类须要修改时,必须考虑到全部的子类,而且父类修改后,全部涉及到子类的功能都有可能产生故障。

- 在使用继承时,遵循里氏替换原则,在子类中尽可能不要重写父类的方法。

- 里氏替换原则代表继承实际上让两个类耦合性加强了,在适当的状况下,能够经过聚合、组合、依赖 来解决问题。

- 重写父类的方法,可能会形成原有功能出现错误。因此父类和子类都继承一个更通俗的基类,原有的继承关系去掉,采用依赖、聚合、组合等关系代替。

开闭原则 OCP(Open Close Principle)

# 1.开闭原则
- 参考文档:https://baike.baidu.com/item/%E5%BC%80%E9%97%AD%E5%8E%9F%E5%88%99/2828775?fr=aladdin

-开闭原则规定“软件中的对象（类，模块，函数等等）应该对于扩展是开放的，可是对于修改是封闭的”。

- 当软件须要变化时,尽可能经过扩展软件实体的行为来实现变化,而不是经过修改已有的代码来实现变化。

- 编程中遵循其它原则,以及使用设计模式的目的就是遵循开闭原则。

迪米特法则 DP (Demeter Principle)

# 1.迪米特法则
- 参考文档:https://baike.baidu.com/item/%E8%BF%AA%E7%B1%B3%E7%89%B9%E6%B3%95%E5%88%99/2107000?fr=aladdin

- 迪米特法则(Law of Demeter)又叫做最少知识原则(The Least Knowledge Principle)，一个类对于其余类知道的越少越好，就是说一个对象应当对其余对象有尽量少的了解,只和朋友通讯，不和陌生人说话。英文简写为: LOD。

- 迪米特法则的核心是下降类之间的耦合。

- 因为每一个类都减小了没必要要的依赖，所以迪米特法则只是要求下降类间(对象间)耦合关系， 并非要求彻底没有依赖关系。

UML

# 1.UML
- 参考文档:https://baike.baidu.com/item/%E7%BB%9F%E4%B8%80%E5%BB%BA%E6%A8%A1%E8%AF%AD%E8%A8%80/3160571?fromtitle=UML&fromid=446747&fr=aladdin

- UML采用一组图形符号来描述软件模型，这些图形符号具备简单、直观和规范的特色，开发人员学习和掌握起来比较简单。

# 2.类图相关概念
- 依赖关系(Dependence)

- 泛化关系(generalization)

- 实现关系(Implementation)

- 关联关系(Association)

- 聚合关系(Aggregation)

- 组合关系(Composition)

设计模式类型

建立型模式

这些设计模式提供了一种在建立对象的同时隐藏建立逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例须要建立哪些对象时更加灵活。

建立型模式提供建立对象的机制， 可以提高已有代码的灵活性和可复⽤性。

- 工厂模式(Factory Pattern)
- 抽象工厂模式(Abstract Factory Pattern)
- 单例模式(Singleton Pattern)
- 建造者模式(Builder Pattern)
- 原型模式(Prototype Pattern)

结构型模式

这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象得到新功能的方式。

结构型模式介绍如何将对象和类组装成较⼤的结构， 并同时保持结构的灵活和⾼效。

- 适配器模式(Adapter Pattern)
- 桥接模式(Bridge Pattern)
- 过滤器模式(Filter、Criteria Pattern)
- 组合模式(Composite Pattern)
- 装饰器模式(Decorator Pattern)
- 外观模式(Facade Pattern)
- 享元模式(Flyweight Pattern)
- 代理模式(Proxy Pattern)

行为型模式

这些设计模式特别关注对象之间的通讯。

行为型模式负责对象间的⾼效沟通和职责委派。

- 责任链模式(Chain of Responsibility Pattern)
- 命令模式(Command Pattern)
- 解释器模式(Interpreter Pattern)
- 迭代器模式(Iterator Pattern)
- 中介者模式(Mediator Pattern)
- 备忘录模式(Memento Pattern)
- 观察者模式(Observer Pattern)
- 状态模式(State Pattern)
- 空对象模式(Null Object Pattern)
- 策略模式(Strategy Pattern)
- 模板模式(Template Pattern)
- 访问者模式(Visitor Pattern)

JavaEE模式

这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。

- MVC 模式(MVC Pattern)
- 业务表明模式(Business Delegate Pattern)
- 组合实体模式(Composite Entity Pattern)
- 数据访问对象模式(Data Access Object Pattern)
- 前端控制器模式(Front Controller Pattern)
- 拦截过滤器模式(Intercepting Filter Pattern)
- 服务定位器模式(Service Locator Pattern)
- 传输对象模式(Transfer Object Pattern)