对于OO（面向对象）系统的设计而言，在支持可维护性的同时，提高系统的可复用性是一个至关重要的问题。
如何提高系统的可维护性和可复用性，是OOD（面向对象开发）需要解决的核心问题之一。
在OOD中，可维护性的复用是以设计原则为基础的。
常用的OOD原则有以下几个：
开闭原则里式替换原则依赖倒转原则接口隔离原则迪米特法则合成复用原则单一职责原则这些设计原则首先都是面向复用的原则，遵循这些设计原则可以有效地提高系统的复用性，同时提高系统的可维护性。
1、开闭原则是面向对象的可复用设计的第一块基石，它是最重要的面向对象设计原则。开闭原则由Bertrand Meyer于1988年提出。
其定义如下： 开闭原则(Open-Closed Principle, OCP)：一个软件实体应当对扩展开放，对修改关闭。 即软件实体应尽量在不修改原有代码的情况下进行扩展。
此处的实体可以指一个软件模块、一个由多个类组成的局部结构，或者一个独立的类乃至一个方法。
2、应用开闭原则可以扩展已有的系统，并为之提供新的行为，以满足对软件的新需求，使变化中的系统具有一定的适应性和灵活性。
对于已有的软件模块，特别是重要的抽象层模块不能再修改，这就使得变化中的系统有一定的稳定性和延续性。3、开闭原则，一般通过在原有模块中添加抽象层（例如接口或抽象类）来实现，它也是其他面向对象开发原则的基础，其他原则是实现开闭原则的具体措施。
4、为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。
在Java、C#等编程语言中，可以为系统定义一个相对稳定的抽象层，而将不同的实现行为移至具体的实现层中完成。
在很多面向对象编程语言中都提供了接口、抽象类等机制，可以通过它们定义系统的抽象层，再通过具体类来进行扩展。如果需要修改系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。
1、里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士Barbara Liskov教授和卡内基·梅隆大学Jeannette Wing教授于1994年提出。 其基本思想是：一个软件实体如果使用的是一个基类对象，那么一定适用于其子类对象，而且觉察不出基类对象和子类对象的区别。即把基类都替换成它的子类，程序的行为没有变化。反过来则不一定成立，如果一个软件实体使用的是一个子类对象，那么它不一定适用于基类对象。
举个例子，定义一个方法：public void doSomething(List list)，这个方法的形参类型为List接口，那么它可以传递实现了List接口的子类对象，如ArrayList、LinkedList等子类对象都可以作为形参传递。
反之，如果方法定义为：public void doSomething(ArrayList list)，那么这个方法只能传递ArrayList的实例或子类对象作为形参，List接口则不适用此形参了。
2、 里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
3、如何运用里式替换原则？答案是：尽量将一些需要扩展的类或者存在变化的类设计为抽象类或者接口，并将其作为基类，在进行程序中尽量使用基类对象/接口对象进行编程。
由于子类继承基类/实现接口，并实现其中的方法，程序运行时，子类对象可以替换基类对象，如果需要对类的行为进行修改，可以扩展基类，增加新的子类，而无需修改该基类对象的代码。
1、依赖倒转原则定义如下： 依赖倒转原则(Dependency Inversion Principle, DIP)：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
2、在程序代码中传递参数或组合（或聚合）关系时，尽量使用抽象层次高的基类/接口，即使用接口和抽象类进行变量类型声明、参数类型声明和返回类型声明，以及数据类型的转换等，不要用具体的类来做这些事情。同时，为了确保该原则的应用，一个具体类应当只实现接口和抽象类声明的方法，不要给出多余的方法，否则，将无法调用在子类中增加的新方法。
举个例子，在集合框架编码中，使用接口对象来声明变量类型，List list=new ArrayList()，List list=new LinkedList()。这种通过接口对象声明变量，就是【依赖倒置原则】的应用。
3、在引入抽象层后，系统将具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改配置文件，而无须修改原有系统的源代码，在不修改的情况下来扩展系统的功能，满足开闭原则的要求。
1、组合/聚合复用原则(Composition/Aggregate Reuse Principle, CARP)，又称为合成复用原则，其定义如下： 合成复用原则(Composite Reuse Principle, CRP)：尽量使用对象组合，而不是继承来达到复用的目的。
2、合成复用原则就是在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用功能的目的。简言之：复用时要尽量使用组合/聚合关系（关联关系），少用继承。 在面向对象设计中，可以通过两种方法在不同的环境中复用已有的设计和实现，即通过组合/聚合关系或通过继承，但首先应该考虑使用组合/聚合，组合/聚合可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少；其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。
3、通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实现细节暴露给子类，由于基类的内部细节通常对子类来说是可见的，所以这种复用又称“白箱”复用，如果基类发生改变，那么子类的实现也不得不发生改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；而且继承只能在有限的环境中使用（如类没有声明为不能被继承）。
1、接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。每个接口应该承担一个相对独立的角色，不多不少，不干不该干的事情，该干的事情都要干。
2、据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。这里的“接口”往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的“接口”定义，有严格的定义和结构，比如Java语言中的interface。对于这两种不同的含义，ISP的表达方式以及含义都有所不同：
(1) 当把“接口”理解成一个类型所提供的所有方法特征的集合的时候，这就是一种逻辑上的概念，接口的划分将直接带来类型的划分。可以把接口理解成角色，一个接口只能代表一个角色，每个角色都有它特定的一个接口，此时，这个原则可以叫做“角色隔离原则”。
(2) 如果把“接口”理解成狭义的特定语言的接口，那么ISP表达的意思是指接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。在面向对象编程语言中，实现一个接口就需要实现该接口中定义的所有方法，因此大的总接口使用起来不一定很方便，为了使接口的职责单一，需要将大接口中的方法根据其职责不同分别放在不同的小接口中，以确保每个接口使用起来都较为方便，并都承担某一单一角色。接口应该尽量细化，同时接口中的方法应该尽量少，每个接口中只包含一个客户端（如子模块或业务逻辑类）所需的方法即可，这种机制也称为“定制服务”，即为不同的客户端提供宽窄不同的接口。
3、在使用接口隔离原则时，我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即可，不应该强迫客户依赖于那些它们不用的方法。
1、最少知识原则又称为迪米特法则(LeastKnowledge Principle, LKP)。
其定义如下：一个软件实体应当尽可能少地与其他实体发生相互作用。
这样，当一个模块修改时，就会尽量少地影响其他的模块，扩展会相对容易。
2、最少知识原则要求我们在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。
3、最少只是原则的主要用途是：控制信息的过载。
将最少知识原则运用到系统设计时，要注意以下几点：
在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，越有利于复用。在类的结构设计上，每个类都应该尽量降低其属性和方法的访问权限。在类的设计上，只要有可能，一个类型应当设计成不变类。在对其他类的引用上，一个对象对其他对象的引用应该降到最低。1、单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
2、单一职责原则告诉我们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。
3、单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。
