面向对象设计六大原则

最新推荐文章于 2024-09-12 11:24:14 发布

Coding-lover

最新推荐文章于 2024-09-12 11:24:14 发布

阅读量2.5k

点赞数

分类专栏：设计模式

设计模式专栏收录该内容

45 篇文章 0 订阅

订阅专栏

面向对象设计的原则是面向对象思想的提炼,它比面向对象思想的核心要素更具可操作性,但与设计模式相比,却又更加的抽象,是设计精神要义的抽象概括。形象地将,面向对象思想像法理的精神,设计原则则相对于基本宪法,而设计模式就好比各式各样的具体法律条文了。

面向对象设计原则有 6 个:开放封闭原则,单一职责原则,依赖倒置原则,Liskov 替换原则,迪米特法则和接口隔离原则或合成/聚合复用原则(不同资料略有不同,这里对7个都做了整理)。

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

There should never be more than one reason for a class to change. 什么意思呢?

所谓单一职责原则就是一个类只负责一个职责,只有一个引起变化的原因。

如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化会削弱或抑制这个类完成其他职责的能力,这个耦合会导致脆弱的设计。

软件设计真正要做的许多内容,就是发现职责并把这些职责相互分离;如果能够想到多于一个动机去改变一个类,那么这个类就具有多于一个职责,就应该考虑类的分离。
以调制解调器为例如下图:

从上述类图里面我们发现有四个方法 Dial(拨通电话),Hangup(挂电话),Receive(收到信息),Send(发送信息),经过分析不难判断出,实际上 Dial(拨通电话)和 Hangup(挂电话)是属于连接的范畴,而 Receive(收到信息)和 Send(发送信息)是属于数据传送的范畴。这里类包括两个职责,显然违反了 SRP。
这样做有潜在的隐患,如果要改变连接的方式,势必要修改 Modem,而修改 Modem 类的结果导致凡事依赖 Modem 类可能都需要修改,这样就需要重新编译和部署,不管数据传输这部分是否需要修改。
因此要重构 Modem 类,从中抽象出两个接口,一个专门负责连接,另一个专门负责数据传送。依赖 Modem 类的元素要做相应的细化,根据职责的不同分别依赖不同的接口。如下图:

这样以来,无论单独修改连接部分还是单独修改数据传送部分,都彼此互不影响。
总结单一职责优点:
降低类的复杂性,
提高可维护性
提高可读性。

降低需求变化带来的风险。需求变化是不可避免的,如果单一职责做的好,一个接口修改只对相应的实现类有影响,对其它的接口无影响,这对系统的扩展性和维护性都有很大的帮助。

2 里氏替换原则(Liskov Substitution Principle LSP)

里氏替换原则是面向对象设计的基本原则之一。任何基类可以出现的地方,子类一定可以出现。LSP 是继承复用的基石,只有当子类可以替换基类,软件单位的功能不受影响时, 基类才能真正的被复用,而子类也可以在基类的基础上增加新的行为。
Liskov 提出了关于继承的原则:Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.‐‐‐‐继承必须确保超类中所拥有的性质在子类中仍然成立。2002 年,软件工程大师 Robert C. Martin 出版了一本《Agile Software DevelopmentPrinciples Patterns and Practices》,在文中他把里氏代换原则最终简化为一句话:“Subtypes must be substitutable for their base types”也就是说子类必须能够替换成他们的基类。

事实上，当一个类继承了另外一个类，那么子类就拥有了父类中可以继承下来的属性和操作。理论上来讲，此时使用子类型去替换掉父类型，应该不会出现问题。

但是，很不幸的是，在某些情况下是会出现问题的。比如，如果子类型覆盖了父类型的某些方法，或者是子类型修改了父类型某些属性的值，那么原来使用父类型的程序可能会出现错误，因为在运行期间，从表面上看，它调用的是父类型的方法，需要的是父类型方法实现的功能，但是在实际运行调用的却是子类型覆盖的实现的方法，而该方法和父类型的方法并不一样，于是导致错误的产生。
里氏替换原则讲的是基类和子类的关系,只有这种关系存在的时候里氏替换原则才能成立。里氏替换原则是实现开放封闭原则的具体规范。开放原则要求对扩展开放，扩展的一个实现手段就是使用继承；而里氏替换原则是保证子类型能够正确替换父类型，只有能正确替换，才能实现扩展，否则扩展了也会出现错误。
我们大家都打过 CS 的游戏,用枪射击杀人,如下类图:

枪的主要职责是射击,如何射击在各个具体的子类中定义。注意在类中调用其他类时务必调用父类或接口,如果不能掉话父类或接口,说明类的射击已经违反了 LSP 原则。
如果我们有一个玩具手枪,该如何定义呢?我们先在类图 2-1 上增加一个类 ToyGun, 然后继承于 AbstractGun 类,修改后的类图如下:

玩具枪是不能用来射击的,杀不死人的,这个不应该写 shoot 方法,在这种情况下业务的调用类就会出现问题。为了解决这个问题,ToyGun 可以脱离继承,建立一个独立的父类,为了做到代码可以服用,可以与 AbstractGun 建立关联委托关系,如下图:

因此,如果子类不能完整地实现父类的方法,那么建议断开父子继承关系,采用依赖,聚合, 组合等关系代替继承。
子类可以有自己的属性或方法。
覆盖或实现父类的方法时输入的参数可以放大。

覆盖或实现父类的方法时输出结果可以被缩小。这是什么意思呢,父类的方法返回值是一个类型 T,子类相同的方法(覆写)的返回值为类型 S,那么根据里氏替换原则就要求 S 必须小于等于 T,也就是说要么 S 和 T 是同一个类型,要么 S 是 T 的子类型。
采用里氏替换原则的目的就是增加程序的健壮性,需求变更时也可以保持良好的兼容性和稳定性,即使增加子类,原有的子类可以继续运行。在实际项目中,每个子类对应不同的业务含义, 使用父类作为参数,传递不同的子类完成不同业务逻辑。

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

所谓依赖倒置原则就是要依赖于抽象,不要依赖于具体。简单的说就是对抽象进行编
程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。
面向过程的开发,上层调用下层,上层依赖于下层,当下层剧烈变化时,上层也要跟着变化,这就会导致模块的复用性降低而且大大提高了开发的成本。
面向对象的开发很好的解决了这个问题,一般的情况下抽象的变化概率很小,让用户程序依赖于抽象,实现的细节也依赖于抽象。即使实现细节不断变化,只要抽象不变,客户程序就不需要变化。这大大降低了客户程序域实现细节的耦合度。
比如一个合资汽车公司现在要求开发一个自动驾驶系统,只要汽车上安装上这个系统,就可以实现无人驾驶,该系统可以在福特车系列和本田车系列上使用。面向过程的结构图:

实现代码如下:

public class HondaCar {
	public void Run() {
		Console.WriteLine("本田车启动了!");
	}

	public void Turn() {
		Console.WriteLine("本田车拐弯了!");
	}

	public void Stop() {
		Console.WriteLine("本田车停止了!");
	}
}

public class FordCar {
	public void Run() {
		Console.WriteLine("福特车启动了!");
	}

	public void Turn() {
		Console.WriteLine("福特车拐弯了!");
	}

	public void Stop() {
		Console.WriteLine("福特车停止了!");
	}
}

public class AutoSystem {
	public enum CarType {
		Ford, Fonda
	}

	private HondaCar hondcar = new HondaCar();
	private FordCar fordcar = new FordCar();
	private CarType type;

	public AutoSystem(CarType carType) {
		this.type = carType;
	}

	public void RunCar() {
		if (this.type == CarType.Fonda) {
			hondcar.Run();
		} else if (this.type == CarType.Ford) {
			fordcar.Run();
		}
	}

	public void StopCar() {
		if (this.type == CarType.Fonda) {
			hondcar.Stop();
		} else if (this.type == CarType.Ford) {
			fordcar.Stop();
		}
	}

	public void TurnCar() {
		if (this.type == CarType.Fonda) {
			hondcar.Turn();
		} else if (this.type == CarType.Ford) {
			fordcar.Turn();
		}
	}
}

显然这个实现代码也可满足现在的需求。
但是如何现在公司业务规模扩大了,该自动驾驶系统还要把吉普车也兼容了。这些就需要修改 AutoSystem 类如下:

public class AutoSystem {
	public enum CarType {
		Ford, Fonda, Jeep
	}

	private HondaCar hondcar = new HondaCar();
	private FordCar fordcar = new FordCar();
	private Jeep jeep = new Jeep();
	private CarType type;

	public AutoSystem(CarType carType) {
		this.type = carType;
	}

	public void RunCar() {
		if (this.type == CarType.Fonda) {
			hondcar.Run();
		} else if (this.type == CarType.Ford) {
			fordcar.Run();
		} else if (this.type == CarType.Jeep) {
			jeep.Run();
		}
	}

	public void StopCar() {
		if (this.type == CarType.Fonda) {
			hondcar.Stop();
		} else if (this.type == CarType.Ford) {
			fordcar.Stop();
		} else if (this.type == CarType.Jeep) {
			jeep.Stop();
		}
	}

	public void TurnCar() {
		if (this.type == CarType.Fonda) {
			hondcar.Turn();
		} else if (this.type == CarType.Ford) {
			fordcar.Turn();
		} else if (this.type == CarType.Jeep) {
			jeep.Turn();
		}
	}
}

通过代码分析得知,上述代码也确实满足了需求,但是软件是不断变化的,软件的需求也是变化的,如果将来业务又扩大了,该自动驾驶系统还有能实现通用、三菱、大众汽车,这样我们不得不又要修改AutoSystem类了。这样会导致系统越来越臃肿,越来越大, 而且依赖越来越多低层模块,只有低层模块变动,AutoSystem类就不得不跟着变动,导致系统设计变得非常脆弱和僵硬。
导致上面所述问题一个原因是,含有高层策略的模块,如AutoSystem模块,依赖于它所控制的低层的具体细节的模块(如FordCar和HondaCar)。如果能使AutoSystem 模块独立于它所控制的具体细节,而是依赖抽象,那么我们就可以服用它了。这就是面向对象中的“依赖倒置”机制。如下类图:

实现代码如下:

public interface ICar {
	void Run();
	void Stop();
	void Turn(); 
}
public class HondaCar:ICar {
	public void Run() { 
		Console.WriteLine("本田车启动了!"); 
	} 
	public void Turn() { 
		Console.WriteLine("本田车拐弯了!"); 
		} 
	public void Stop() { 
		Console.WriteLine("本田车停止了!"); 
	}
}
public class FordCar :ICar {
	public void Run() { 
		Console.WriteLine("福特车启动了!"); 
	} 
	public void Turn() { 
		Console.WriteLine("福特车拐弯了!"); 
	} 
	public void Stop() { 
		Console.WriteLine("福特车停止了!"); 
	}
}
public class Jeep:ICar {
	public void Run() { 
		Console.WriteLine("福特车启动了!"); 
	} 
	public void Turn() { 
		Console.WriteLine("福特车拐弯了!"); 
	} 
	public void Stop() { 
		Console.WriteLine("福特车停止了!"); 
	}
}
public class AutoSystem {
	private ICar car;
	public AutoSystem(ICar car) {
		this.car = car; 
	}
	public void RunCar() {
		this.car.Run(); 
	}
	public void StopCar() {
		this.car.Stop(); 
	}
	public void TurnCar() {
		this.car.Turn(); 
	}
}

现在Autosystem系统依赖于ICar这个抽象,而与具体的实现细节HondaCar:和FordCar无关,所以实现细节的变化不会影响AutoSystem.对于实现细节只要实现ICar即可。即实现细节依赖于ICar抽象。
综上所述:一个应用中的重要策略决定及业务正是在这些高层的模块中。也正是这些模块包含这应用的特性。但是,当这些模块依赖于低层模块时,低层模块的修改比较将直接影响到他们,迫使它们也改变。这种情况是荒谬的。（很多人觉得，层次化调用的时候，应该是高层调用“底层所拥有的接口”，这是一个典型的误解。事实上，一般的高层模块包含对业务功能的处理和业务决策选择，应该被重用，是高层模块去影响底层的具体实现）
应该是处于高层的模块去迫使那些低层的模块发生改变。处于高层的模块应优先于低层的模块。无论如何高层模块也不应该依赖于低层模块。而且我们想能够复用的是高层的模块,只有高层模块独立于低层模块时,复用才有可能。（因此，这个底层的接口应该是高层提出，然后由底层去实现的。也就是说底层的接口的所有权在高层模块，因是一种所有权的倒置。）
总之,高层次的模块不应该依赖于低层次的模块,它们都应该依赖于抽象。抽象不应该依赖于具体,具体应该依赖于抽象。

倒置接口所有权，这就是著名的hollywood（好莱坞）原则；不要找我们，我们会联系你。

4 迪米特法则

迪米特法则(Law of Demeter)又叫最少知识原则(Least Knowledge Principle LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。(只和你的朋友谈话。)
对面向对象来说,一个软件实体应当尽可能的少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识,而其局限于那些与本单位密切相关的软件单位。（这个原则用来指导我们在设计系统时，因该尽量减少对象之间的交互，对象只能和自己的朋友谈话，也就是只和自己的朋友交互，从而松散类之间的耦合。通过松散类之间的耦合来降低来降低类之间的相互依赖，这样在修改系统的某一个部分的时候，就不会影响其他其他部分，从而使得系统具有更好的可维护性。）
迪米特法则的目的在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖,因此, 很容易使得系统的功能模块相互独立,相互之间不存在依赖关系。应用迪米特法则有可能造成的一个后果就是,系统中存在的大量的中介类,这些类只所以存在完全是为了传递类之间的相互调用关系‐‐‐这在一定程度上增加系统的复杂度。
设计模式中的门面模式(Facade)和中介模式(Mediator)都是迪米特法则的应用的例子。
狭义的迪米特法则的缺点:
在系统里面造出大量的小方法,这些方法仅仅是传递间接的调用,与系统的商业逻辑无关。
遵循类之间的迪米特法则会使一个系统的局部设计简化,因为每一个局部都不会和远距离的对象有之间的关联。但是,这也会造成系统的不同模块之间的通信效率降低,也会使系统的不同模块之间不容易协调。
广义的迪米特法则在类的设计上的体现:

优先考虑将一个类设置成不变类.

尽量降低一个类的访问权限。

尽量降低成员的访问权限。

那么究竟哪些对象才能被当作朋友呢？最小指导原则提供了一些指导。

当前对象本身。

通过方法的参数传递进来的对象。

当前对象创建的对象。

当前对象的实例变量所引用的对象。

方法内所创建或实例化的对象。

总之，最小指导原则要求我们的方法调用必须保持在一定界限范围之内，尽量减小对象的依赖的关系。

下面的代码在方法体内部依赖了其他类,这严重违反迪米特法则

public class Teacher {
	public void commond(GroupLeader groupLeader) {
		List<Girl> listGirls = new ArrayList<Girl>();
		for (int i = 0; i < 20; i++) {
			listGirls.add(new Girl());
		}
		groupLeader.countGirls(listGirls);
	}
}

方法是类的一个行为,类竟然不知道自己的行为与其他类产生了依赖关系,这是不允许的。正确的做法是:

public class Teacher {
	public void commond(GroupLeader groupLeader) {
		groupLeader.countGirls();
	}
}

public class GroupLeader {
	private List<Girl> listGirls;

	public GroupLeader(List<Girl> _listGirls) {
		this.listGirls = _listGirls;
	}

	public void countGirls() {
		System.out.println("女生数量是:" + listGirls.size());
	}
}

5 开放封闭原则(OpenClosed Principle OCP)

Software entities(classes,modules,functions etc) should open for extension ,but close for modification.
什么意思呢?

所谓开放封闭原则就是软件实体应该对扩展开发,而对修改封闭。开放封闭原则是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化,降低耦合,而开放封闭原则正是对这一目标的最直接体现。
开放封闭原则主要体现在两个方面: 对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。

对修改封闭,意味着类一旦设计完成,就可以独立其工作,而不要对类尽任何修改。

为什么要用到开放封闭原则呢?

软件需求总是变化的,世界上没有一个软件的是不变的,因此对软件设计人员来说,必须在不需要对原有系统进行修改的情况下,实现灵活的系统扩展。

如何做到对扩展开放,对修改封闭呢?

实现开放封闭的核心思想就是对抽象编程,而不对具体编程,因为抽象相对稳定。让类依赖于固定的抽象,所以对修改就是封闭的;而通过面向对象的继承和多态机制,可以实现对抽象体的继承,通过覆写其方法来改变固有行为,实现新的扩展方法,所以对于扩展就是开放的。
对于违反这一原则的类,必须通过重构来进行改善。常用于实现的设计模式主要有 Template Method 模式和 Strategy 模式。而封装变化,是实现这一原则的重要手段,将经常变化的状态封装为一个类。
以银行业务员为例

没有实现 OCP 的设计:

import com.sun.security.ntlm.Client;

public class BankProcess {
	// 存款
	public void Deposite() {
	}

	// 取款
	public void Withdraw() {
	}

	// 转账
	public void Transfer() {
	}
}

public class BankStaff {
	private BankProcess bankpro = new BankProcess();

	public void BankHandle(Client client) {
		switch (client.Type) {
		// 存款
		case "deposite":
			bankpro.Deposite();
			break;
		// 取款
		case "withdraw":
			bankpro.Withdraw();
			break;
		// 转账
		case "transfer":
			bankpro.Transfer();
			break;
		}

	}
}

这种设计显然是存在问题的,目前设计中就只有存款,取款和转账三个功能,将来如果业务增加了,比如增加申购基金功能,理财功能等,就必须要修改 BankProcess 业务类。我们分析上述设计就不能发现把不能业务封装在一个类里面,违反单一职责原则,而有新的需求发生,必须修改现有代码则违反了开放封闭原则。
从开放封闭的角度来分析,在银行系统中最可能扩展的就是业务功能的增加或变更。对业务流程应该作为扩展的部分来实现。当有新的功能时,不需要再对现有业务进行重新梳理, 然后再对系统做大的修改。
如何才能实现耦合度和灵活性兼得呢?
那就是抽象,将业务功能抽象为接口,当业务员依赖于固定的抽象时,对修改就是封闭的,而通过继承和多态继承,从抽象体中扩展出新的实现,就是对扩展的开放。
以下是符合 OCP 的设计:

首先声明一个业务处理接口

public interface IBankProcess {
	void Process(); 
}
public class DepositProcess : IBankProcess {
	public void Process() {
		//办理存款业务
		Console.WriteLine("Process Deposit"); 
	}
}
public class WithDrawProcess : IBankProcess{
	public void Process() {
		//办理取款业务
		Console.WriteLine("Process WithDraw"); 
	}
}
public class TransferProcess : IBankProcess {
	public void Process() {
		//办理转账业务
		Console.WriteLine("Process Transfer"); 
	}
}
public class BankStaff {
	private IBankProcess bankpro = null; 
	public void BankHandle(Client client) {
		switch (client.Type) {
			//存款 
			case "Deposit":
				bankpro = new DepositUser(); break;
				//转账
			case "Transfer":
				bankpro = new TransferUser(); break;
				//取款
			case "WithDraw":
				bankpro = new WithDrawUser(); break;
			}
			bankpro.Process(); }
		}
}

这样当业务变更时,只需要修改对应的业务实现类就可以,其他不相干的业务就不必修改。当业务增加,只需要增加业务的实现就可以了。

设计建议:
开放封闭原则,是最为重要的设计原则,Liskov 替换原则和合成/聚合复用原则为开放封闭原则提供保证。
可以通过 Template Method 模式和 Strategy 模式进行重构,实现对修改封闭,对扩展开放的设计思路。
封装变化,是实现开放封闭原则的重要手段,对于经常发生变化的状态,一般将其封装为一个抽象,例如银行业务中 IBankProcess 接口。
拒绝滥用抽象,只将经常变化的部分进行抽象。

6 接口隔离原则(ISP)

接口隔离原则认为:"使用多个专门的接口比使用单一的总接口要好"。因为接口如果能够保持粒度够小, 就能保证它足够稳定,正如单一职责原则所标榜的那样。多个专门的接口就好比采用活字制版,可以随时拼版拆版,既利于修改,又利于文字的重用。而单一的总接口就是雕版印刷,显得笨重,实现殊为不易;
一旦发现错字别字,就很难修改,往往需要整块雕版重新雕刻。

所谓接口隔离原则，指的是，不应该强迫客户依赖于他们不用的方法。

这个原则用来处理那些比较“庞大”的接口，这种接口通常会有较多的方法操作声明，设计到很多的职责。客户在使用这样的接口的时候，通常会有很多他不需要的方法，这些方法对于客户来讲，就是一种接口污染，相当于强迫用户在一大堆“垃圾方法”中去寻找他需要的方法。

因此，这样的接口应该被分离，应该按照不同的客户需要来分离成为针对客户的接口。这样的接口中，只包含客户需要的操作声明，这样既方便了客户的使用，也可以避免因误用接口而导致的错误。

分离接口的方式，除了直接进行代码的分离之外，还可以使用委托来分离接口，在能够支持多重继承的语言中，还可以采用多重继承的方式进行分离。

例一:
参考下图的设计,在这个设计里,取款、存款、转帐都使用一个通用界面接口, 也就是说,每一个类都被强迫依赖了另两个类的接口方法,那么每个类有可能因为另外两个类的方法(跟自己无关)而被影响。拿取款来说,它根本不关心“存款操作”和“转帐操作”,可是它却要受到这两个方法的变化的影响。

那么我们该如何解决这个问题呢?参考下图的设计,为每个类都单独设计专门的操作接口,使得它们只依赖于它们关系的方法,这样就不会互相影了!

例二:

使用多个专门的接口还能够体现对象的层次,因为我们可以通过接口的继承,实现对总接口的定义。例如,.NET 框架中 IList 接口的定义。

public interface IEnumerable{
	IEnumerator GetEnumerator();
}
public interface ICollection : IEnumerable{
	void CopyTo(Array array, int index);
	// 其余成员略
 }
public interface IList : ICollection, IEnumerable{
 	int Add(object value);
 	void Clear();
 	bool Contains(object value);
 	int IndexOf(object value);
 	void Insert(int index, object value);
 	void Remove(object value);
 	void RemoveAt(int index);
	// 其余成员略
}

如果不采用这样的接口继承方式,而是定义一个总的接口包含上述成员,就无法实现 IEnumerable 接口、 ICollection 接口与 IList 接口成员之间的隔离。假如这个总接口名为 IGeneralList,它抹平了 IEnumerable 接口、ICollection 接口与 IList 接口之间的差别,包含了它们的所有方法。现在,如果我们需要定义一个 Hashtable 类。根据数据结构的特性,它将无法实现 IGeneralList 接口。因为 Hashtable 包含的 Add() 方法,需要提供键与值,而之前针对 ArrayList 的 Add()方法,则只需要值即可。这意味着两者的接口存在差异。我们需要专门为 Hashtable 定义一个接口,例如 IDictionary,但它却与 IGeneralList 接口不存在任何关系。正是因为一个总接口的引入,使得我们在可枚举与集合层面上丢失了共同的抽象意义。虽然 Hashtable 与 ArrayList 都是可枚举的,也都具备集合特征,它们却不可互换。
如果遵循接口隔离原则,将各自的集合操作功能分解为不同的接口,那么站在 ICollection 以及 IEnumerable 的抽象层面上,可以认为 ArrayList 和 Hashtable 是相同的对象。在这一抽象层面上,二者是可替换的,如图 2-9 所示。这样的设计保证了一定程度的重用性与可扩展性。从某种程度来讲,接口隔离原则可以看做是接口层的单一职责原则。

倘若一个类实现了所有的专门接口,从实现上看,它与实现一个总接口的方式并无区别;但站在调用者的角度,不同的接口代表了不同的关注点、不同的职责,甚至是不同的角色。因此,面对需求不同的调用者, 这样的类就可以提供一个对应的细粒度接口去匹配。此外,一个庞大的接口不利于我们对其进行测试,因为在为该接口实现 Mock 或 Fake 对象时,需要实现太多的方法。
概括地讲,面向对象设计原则仍然是面向对象思想的体现。例如,单一职责原则与接口隔离原则体现了封装的思想,开放封闭原则体现了对象的封装与多态,而 Liskov 替换原则是对对象继承的规范,至于依赖倒置原则,则是多态与抽象思想的体现。在充分理解面向对象思想的基础上,掌握基本的设计原则,并能够在项目设计中灵活运用这些原则,就能够改善我们的设计,尤其能够保证可重用性、可维护性与可扩展性等系统的质量属性。这些核心要素与设计原则,就是我们设计的对象法则,它们是理解和掌握设计模式的必备知识。

7 组合/聚集复用原则

组合/聚合复用原则(Composite/Aggregate Reuse Principle CARP).组合和聚合都是对象建模中关联(Association)关系的一种.聚合表示整体与部分的关系,表示“含有”,整体由部分组合而成,部分可以脱离整体作为一个独立的个体存在。组合则是一种更强的聚合,部分组成整体,而且不可分割,部分不能脱离整体而单独存在。在合成关系中,部分和整体的生命周期一样,组合的新的对象完全支配其组成部分,包括他们的创建和销毁。一个合成关系中成分对象是不能与另外一个合成关系共享。
组合/聚合和继承是实现复用的两个基本途径。合成复用原则是指尽量使用合成/聚合, 而不是使用继承。
只有当以下的条件全部被满足时,才应当使用继承关系。
1 子类是超类的一个特殊种类,而不是超类的一个角色,也就是区分“Has‐A”和“Is‐A”. 只有“Is‐A”关系才符合继承关系,“Has‐A”关系应当使用聚合来描述。
2 永远不会出现需要将子类换成另外一个类的子类的情况。如果不能肯定将来是否会变成另外一个子类的话,就不要使用继承。
3 子类具有扩展超类的责任,而不是具有置换掉或注销掉超类的责任。如果一个子类需要大量的置换掉超类的行为,那么这个类就不应该是这个超类的子类。
错误的使用继承而不是合成/聚合的一个常见原因是错误地把“Has‐A”当成了 “Is‐A”.”Is‐A”代表一个类是另外一个类的一种;而“Has‐A”代表一个类是另外一个类的一个角色,而不是另外一个类的特殊种类。
我们需要办理一张银行卡,如果银行卡默认都拥有了存款、取款和透支的功能,那么我们办理的卡都将具有这个功能,此时使用了继承关系: