设计模式笔记-面向对象设计原则

  |   0 评论   |   883 浏览

软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一,面向对象设计原则的就是为解决可维护性和可复用性这两个核心问题而总结出来的指导性原则。

7种面向对象设计原则

1.单一职责原则(Single Responsibility Principle, SRP)

一个类只负责一个功能领域中的相应职责,是实现高内聚、低耦合的指导方针,它是最简单但又最难运用的原则。

一个类(也可以是模块、方法等)承担的职责越多,这些职责就耦合到一起,被复用的可能性就越小,当其中一个职责发生变化可能会影响到这个类承担的其他职责。因此需要将不同职责分离开来,不同职责封装到不同的类,相同类型或者变化因素相同的职责封装到同一个类里面。设计的时候发现类的不同职责并将其分离,需要有较强的分析能力和实践经验,因此说是最简单但又最难运用的原则。

2.开闭原则(Open-Closed Principle, OCP)

软件实体应对扩展开放,而对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

软件实体可以是一个软件模块、一个由多个类组成的局部结构或者一个单独的类。
在软件生命周期中,需求随着实践推移不断变化,当面对新需求时应该可以非常方便的对系统进行扩展,而无需修改现有代码。

可以通过接口、抽象类定义系统的抽象层,再使用具体的实现类进行扩展。当系统需要修改具体行为时,只需要增加新的实现类来实现新的业务就可,而无需修改抽象层,达到在不修改已有代码的基础上扩展系统的功能要求,即开闭原则的要求。因此对系统进行抽象化设计,是开闭原则的关键。

当软件系统符合开闭原则时,就可以在具有适应性和灵活性的通知拥有较好的稳定性和持续性。

3.里氏代换原则(Liskov Substitution Principle, LSP)

所有引用基类对象的地方能够透明地使用其子类的对象。

里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士Barbara Liskov教授和卡内基·梅隆大学Jeannette Wing教授于1994年提出。

将一个基类对象替换成它的子类对象,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象。

里氏代换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象。

  1. 子类的所有方法必须在父类中声明,或子类必须实现父类中声明的所有方法。
  2. 尽量把父类设计为抽象类或者接口,让子类继承父类或实现父接口,并实现在父类中声明的方法,运行时,子类实例替换父类实例,我们可以很方便地扩展系统的功能,同时无须修改原有子类的代码,增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一
  3. Java语言中,在编译阶段,编译器会检查一个程序是否符合里氏代换原则,这是一个与实现无关的、纯语法意义上的检查,但Java编译器的检查是有局限的(注:不太理解这个局限)。

4.依赖倒转原则(Dependence Inversion Principle, DIP)

抽象不应该依赖于细节,细节应该依赖于抽象,即针对接口编程,而不是针对实现编程。

在程序代码中传递参数时或在关联关系中,尽量引用层次高的抽象层类,即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明,以及数据类型的转换等,而不要用具体类来做这些事情。

一个具体类应当只实现接口或抽象类中声明过的方法,而不要给出多余的方法,否则将无法调用到在子类中增加的新方法。

实现依赖倒转原则,就是针对抽象层编程,将具体实现类通过依赖注入(DependencyInjection, DI)方式注入到其他对象中,常用依赖入住的方式有构造注入,设值注入(Setter注入)和接口注入。

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

使用多个专门的接口,而不使用单一的总接口。
当一个接口太大时,需要将它分割成一些更细小的接口,使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色,不干不该干的事,该干的事都要干,不应该依赖那些它不需要的接口。

“接口”两种不同的含义:

1、当把“接口”理解成一个类型所提供的所有方法特征的集合的时候,这就是一种逻辑上的概念,接口的划分将直接带来类型的划分。可以把接口理解成角色,一个接口只能代表一个角色,每个角色都有它特定的一个接口,此时,这个原则可以叫做“角色隔离原则”。
2、把“接口”理解成狭义的特定语言的接口,那么ISP表达的意思是指接口仅仅提供客户端需要的行为,客户端不需要的行为则隐藏起来,应当为客户端提供尽可能小的单独的接口,而不要提供大的总接口。在面向对象编程语言中,实现一个接口就需要实现该接口中定义的所有方法,因此大的总接口使用起来不一定很方便,为了使接口的职责单一,需要将大接口中的方法根据其职责不同分别放在不同的小接口中,以确保每个接口使用起来都较为方便,并都承担某一单一角色。接口应该尽量细化,同时接口中的方法应该尽量少,每个接口中只包含一个客户端(如子模块或业务逻辑类)所需的方法即可,这种机制也称为“定制服务”,即为不同的客户端提供宽窄不同的接口。

6.合成复用原则(Composite Reuse Principle, CRP)

尽量使用对象组合,而不是继承来达到复用的目的。

在一个新的对象里通过关联关系(包括组合关系和聚合关系)来使用一些已有的对象,使之成为新对象的一部分;新对象通过委派调用已有对象的方法达到复用功能的目的。简言之:复用时要尽量使用组合/聚合关系(关联关系),少用继承。

通过组合/聚合关系或通过继承在不同的环境中复用已有的设计和实现,首先应该考虑使用组合/聚合,组合/聚合可以使系统更加灵活,降低类与类之间的耦合度,一个类的变化对其他类造成的影响相对较少;其次才考虑继承,在使用继承时,需要严格遵循里氏代换原则,有效使用继承会有助于对问题的理解,降低复杂度,而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度,因此需要慎重使用继承复用。

如果两个类之间是“Has-A”的关系应使用组合或聚合,如果是“Is-A”关系可使用继承。“Is-A"是严格的分类学意义上的定义,意思是一个类是另一个类的"一种”;而"Has-A"则不同,它表示某一个角色具有某一项责任。

7.迪米特法则(Law of Demeter, LoD)

又称为最少知识原则(LeastKnowledge Principle, LKP)
一个软件实体应当尽可能少地与其他实体发生相互作用

当软件系统其中某一个模块发生修改时,就会尽量少地影响其他模块,扩展会相对容易,这是对软件实体之间通信的限制,迪米特法则要求限制软件实体之间通信的宽度和深度。

迪米特法则可降低系统的耦合度,使类与类之间保持松散的耦合关系

迪米特法则要求我们在设计系统时,应该尽量减少对象之间的交互,如果两个对象之间不必彼此直接通信,那么这两个对象就不应当发生任何直接的相互作用,如果其中的一个对象需要调用另一个对象的某一个方法的话,可以通过第三者转发这个调用。简言之,就是通过引入一个合理的第三者来降低现有对象之间的耦合度。

在类的划分上,应当尽量创建松耦合的类,类之间的耦合度越低,就越有利于复用,一个处在松耦合中的类一旦被修改,不会对关联的类造成太大波及;在类的结构设计上,每一个类都应当尽量降低其成员变量和成员函数的访问权限;在类的设计上,只要有可能,一个类型应当设计成不变类;在对其他类的引用上,一个对象对其他对象的引用应当降到最低。

评论

发表评论