01-8、JavaSE知识点总结_面向对象的设计原则
简介
Java中面向对象的设计原则共七种
设计模式的六大原则
加载有点慢,但是每种原则都举的有例子
开闭原则(Open-Closed Principle)
- 对扩展开放,对修改关闭
- 当我们写完的代码,不能因为需求变化就修改。我们可以通过新增代码的方式来解决变化的需求。如果每次需求变动都去修改原有的代码,那原有的代码就存在被修改错误的风险,当然这其中存在有意和无意的修改,都会导致原有正常运行的功能失效的风险,这样很有可能会展开可怕的蝴蝶效应,使维护工作剧增
- 说到底,开闭原则除了表面上的可扩展性强以外,在企业中更看重的是维护成本
- 所以,开闭原则是设计原则的第一大原则,它的潜台词是:控制需求变动风险,缩小维护成本
依赖倒转原则(Dependence-Inversion Principle)
- 要针对接口编程,不要针对实现编程
- 如果A中使用到了B,那么尽量让B实现某个接口,然后A中使用接口,不与B实现类发生关联关系
- 换一种说法,代码要针对接口或抽象类编程,而不是针对具体类编程
- 依赖倒置的潜台词是:面向抽象编程,解耦 调用 和 被调用者
里氏代换原则(Liskov Substitution Principle)
- 尽量不要重写父类的方法,尽量不要重载父类的方法
- 子类必须能够替换基类,否则不应当设计为其子类
- 子类只能去扩展基类,而不是隐藏或覆盖基类
- 里氏替换原则是对开闭原则的扩展,它表明我们在创建基类的新的子类时,不应该改变基类的行为
- 当我们设计程序模块时,我们会创建一些类层次结构,然后我们通过扩展一些类来创建它们的子类。我们必须确保子类只是扩展而没有替换父类的功能,否则当我们在已有程序模块中使用它们时将会产生不可预料的结果。里氏代换原则表明当一个程序模块使用基类时,基类的引用可以被子类替换而不影响模块的功能
单一职责原则(Single-Responsibility Principle)
- 一个类只负责一项职责
- 如果有多个原因去改变一个类,那么应该把这些引起变化的原因分离开,把这个类分成多个类,每个类只负责处理一种改变。当做出某种改变时,只需要修改负责处理该改变的类。当我们去改变一个具有多个职责的类时可能会影响该类的其他功能
接口隔离原则(Interface Segregation Principle)
- 将大的接口打散成多个小接口,让系统解耦,从而容易重构,更改和重新部署
- 接口隔离原则可以让一个软件系统功能扩展时,修改的压力不会传到别的对象那里
- 接口隔离原则表明客户端不应该被强迫实现一些他们不会使用的接口,应该把肥胖接口中的方法分组,然后用多个接口代替它,每个接口服务于一个子模块
- 如果已经设计成了胖接口,可以使用适配器模式隔离它。像其他设计原则一样,接口隔离原则需要额外的时间和努力,并且会增加代码的复杂性,但是可以产生更灵活的设计。如果我们过度的使用它将会产生大量的包含单一方法的接口,所以需要根据经验并且识别出那些将来需要扩展的代码来使用它
迪米特法则(Law Of Demeter)
- 一个对象应该对其他对象保持最少的了解
- 只与你直接的朋友通信,而避免和陌生人通信
- 要求尽量的封装,尽量的独立,尽量的使用低级别的访问修饰符,这是封装特性的典型体现
- 一个类如果暴露太多私用的方法和字段,会让调用者很茫然。并且会给类造成不必要的判断代码。所以,我们使用尽量低的访问修饰符,让外界不知道我们的内部。这也是面向对象的基本思路。这是迪米特原则的一个特性,无法了解类更多的私有信息
- 迪米特原则还要求类之间的直接联系尽量的少,两个类的访问,通过第三个中介类(中间层解耦)来实现
- 迪米特法则有可能造成的一个后果就是,系统中存在的大量的中介类,这些类只所以存在完全是为了传递类之间的相互调用关系,这在一定程度上增加系统的复杂度
- 迪米特原则的潜台词是:不和陌生人说话,有事去中介
合成复用原则(Composite Reuse Principle)
- 合成复用原则又叫组合/聚合复用原则,它要求在软件复用时,要尽量先使用组合或者聚合等关联关系来实现,其次才考虑使用继承关系来实现