首页 > 代码库 > OO原则
OO原则
设计模式的最终目标:建立弹性的设计,高复用,可以维护,可以应对变化。(设计模式可以认为是良好的OO设计经验)
常用的面向对象设计原则包括7个,这些原则并不是孤立存在的,它们相互依赖,相互补充。
设计原则名称 | 设计原则简介 |
单一职责原则 (Single Responsibility Principle, SRP) | 类的职责要单一,不能将太多的职责放在一个类中 |
开闭原则 | 软件实体对扩展是开放的,但对修改是关闭的,即在不修改一个软件实体的基础上去扩展其功能 |
里氏代换原则 | 在软件系统中,一个可以接受基类对象的地方必然可以接受一个子类对象 |
依赖倒转原则 | 要针对抽象层编程,而不要针对具体类编程 |
接口隔离原则 | 使用多个专门的接口来取代一个统一的接口 |
合成复用原则 | 在系统中应该尽量多使用组合和聚合关联关系,尽量少使用甚至不使用继承关系 |
迪米特法则 | 一个软件实体对其他实体的引用越少越好,或者说如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,而是通过引入一个第三者发生间接交互 |
- 封装变化。把会变化的部分取出并“封装”起来,好让其他部分不受到影响。
- 多用组合,少用继承。(利用继承设计子类的行为,是在编译时静态决定的,而且所有的子类都会继承到相同的行为。然而,如果能够利用组合的做法扩展对象的行为,就可以在运行时动态地进行扩展。通过动态地组合对象,可以写新的代码添加新的功能,而无须修改现有代码。既然没有改变现有代码,那么映入BUG或产生意外副作用的机会将大幅度减少。)
- 针对接口编程,不要针对实现编程。
- 为交互对象之间的松耦合设计而努力。
- 类的设计应该对扩展开放,对修改关闭。(组合思想的进一步应用)
- 要依赖抽象,不要依赖具体类。(依赖倒置原则,变量不可以持有具体类的应用,不要让类派生自具体类,不要覆盖基类中已实现的方法。)
- 最少只是原则:之和你的密友谈话。不要让太多的类耦合在一起,免得修改系统中的一部分,会影响到其他部分。如果多个类之间相互依赖,那么这个系统就会变成一个易碎的系统,它需要许多维护成本,也会因为太复杂而不容易被其他人了解。
- 单一责任原则。一个类应该只有一个引起变化的原因。根据类设计的开闭原则,我们知道要避免类内的改变,因为修改代码很容易造成许多的错误。如果有一个类具有两个改变的原因,那么这会使得将来该类的变化几率上升,而当它真的改变时,你的设计中同时有两个方面将会受到影响。
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。