软件的设计开发六大原则

要把软件做得非常灵活又要便于维护是一个很困难的事情。灵活的软件他的结构就复杂，维护起来就困难。有得必有失，关键就在于如何处理这两者，使得大于失。软件的设计开发应遵循以下六大原则： 
1. OCP 
全称：“Open-Closed Principle” 开放－封闭原则 
说明：对扩展开放，对修改关闭。 
优点：按照OCP原则设计出来的系统，降低了程序各部分之间的耦合性，其适应性、灵活性、稳定性都比较好。当已有软件系统需要增加新的功能时，不需要对作为系统基础的抽象层进行修改，只需要在原有基础上附加新的模块就能实现所需要添加的功能。增加的新模块对原有的模块完全没有影响或影响很小，这样就无须为原有模块进行重新测试。 
如何实现“开-闭”原则 
在面向对象设计中，不允许更改的是系统的抽象层，而允许扩展的是系统的实现层。换言之，定义一个一劳永逸的抽象设计层，允许尽可能多的行为在实现层被实现。 
解决问题关键在于抽象化，抽象化是面向对象设计的第一个核心本质。 
对一个事物抽象化，实质上是在概括归纳总结它的本质。抽象让我们抓住最最重要的东西，从更高一层去思考。这降低了思考的复杂度，我们不用同时考虑那么多的东西。换言之，我们封装了事物的本质，看不到任何细节。 
在面向对象编程中，通过抽象类及接口，规定了具体类的特征作为抽象层，相对稳定，不需更改，从而满足“对修改关闭”；而从抽象类导出的具体类可以改变系统的行为，从而满足“对扩展开放”。 
对实体进行扩展时，不必改动软件的源代码或者二进制代码。关键在于抽象。 

2. LSP 
全称：“Liskov Substitution Principle” 里氏代换原则 
说明：子类型必须能够替换它们的基类型。一个软件实体如果使用的是一个基类，那么当把这个基类替换成继承该基类的子类，程序的行为不会发生任何变化。软件实体察觉不出基类对象和子类对象的区别。 
优点：可以很容易的实现同一父类下各个子类的互换，而客户端可以毫不察觉。 

3. DIP 
全称：“Dependence Inversion Principle”依赖倒置原则 
说明：要依赖于抽象，不要依赖于具体。客户端依赖于抽象耦合。 
抽象不应当依赖于细节；细节应当依赖于抽象； 
要针对接口编程，不针对实现编程。 
优点：使用传统过程化程序设计所创建的依赖关系，策略依赖于细节，这是糟糕的，因为策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。 
怎样做到依赖倒置？ 
以抽象方式耦合是依赖倒转原则的关键。抽象耦合关系总要涉及具体类从抽象类继承，并且需要保证在任何引用到基类的地方都可以改换成其子类，因此，里氏代换原则是依赖倒转原则的基础。 
在抽象层次上的耦合虽然有灵活性，但也带来了额外的复杂性，如果一个具体类发生变化的可能性非常小，那么抽象耦合能发挥的好处便十分有限，这时可以用具体耦合反而会更好。 
层次化：所有结构良好的面向对象构架都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供一组内聚的服务。 
依赖于抽象：建议不依赖于具体类，即程序中所有的依赖关系都应该终止于抽象类或者接口。尽量做到： 
1、任何变量都不应该持有一个指向具体类的指针或者引用。 
2、任何类都不应该从具体类派生。 
3、任何方法都不应该覆写它的任何基类中的已经实现的方法。 

4. ISP 
全称：“Interface Segregation Principle” 接口隔离原则 
说明：使用多个专一功能的接口比使用一个的总接口总要好。从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。过于臃肿的接口是对接口的污染，不应该强迫客户依赖于它们不用的方法。 
优点：会使一个软件系统功能扩展时，修改的压力不会传到别的对象那里。 
如何实现接口隔离原则 
不应该强迫用户依赖于他们不用的方法。 
1、利用委托分离接口。 
2、利用多继承分离接口。 

5. CARP or CRP 
全称：“Composite/Aggregate Reuse Principle” 合成/聚合复用原则 or “Composite Reuse Principle”  合成复用原则  
说明：如果新对象的某些功能在别的已经创建好的对象里面已经实现，那么尽量使用别的对象提供的功能，使之成为新对象的一部分，而不要自己再重新创建。新对象通过向这些对象的委派达到复用已有功能的。 
简而言之，要尽量使用合成/聚合，尽量不要使用继承。 
优点： 
1) 新对象存取成分对象的唯一方法是通过成分对象的接口。 
2) 这种复用是黑箱复用，因为成分对象的内部细节是新对象所看不见的。 
3) 这种复用支持包装。 
4) 这种复用所需的依赖较少。 
5) 每一个新的类可以将焦点集中在一个任务上。 
6) 这种复用可以在运行时间内动态进行，新对象可以动态的引用与成分对象类型相同的对象。 
7) 作为复用手段可以应用到几乎任何环境中去。 
缺点: 
就是系统中会有较多的对象需要管理。 

6. LOD or LKP 
全称：“Law of Demeter” 迪米特原则 or “Least Knowledge Principle” 最少知识原则 
说明：对象与对象之间应该使用尽可能少的方法来关联，避免千丝万缕的关系。 
如何实现迪米特法则 
迪米特法则的主要用意是控制信息的过载，在将其运用到系统设计中应注意以下几点： 
1) 在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。 
2) 在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。 
3) 在类的设计上，只要有可能，一个类应当设计成不变类。 
4) 在对其它对象的引用上，一个类对其它对象的引用应该降到最低。 


还有个单一职责原则： 

SRP简介（SRP--Single-Responsibility Principle）：就一个类而言，应该只专注于做一件事和仅有一个引起它变化的原因 。所谓职责，我们可以理解他为功能，就是设计的这个类功能应该只有一个，而不是两个或更多。也可以理解为引用变化的原因，当你发现有两个变化会要求我们修改这个类，那么你就要考虑撤分这个类了。因为职责是变化的一个轴线，当需求变化时，该变化会反映类的职责的变化。 使用SRP注意点：1、一个合理的类，应该仅有一个引起它变化的原因，即单一职责； 
2、在没有变化征兆的情况下应用SRP或其他原则是不明智的； 
3、在需求实际发生变化时就应该应用SRP等原则来重构代码； 
4、使用测试驱动开发会迫使我们在设计出现臭味之前分离不合理代码； 
5、如果测试不能迫使职责分离，僵化性和脆弱性的臭味会变得很强烈，那就应该用Facade或Proxy模式对代码重构；SRP优点：消除耦合，减小因需求变化引起代码僵化。 


你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。 
-----Arthur J.Riel 
(1)所有数据都应该隐藏在所在的类的内部。 
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。p15 
(3)尽量减少类的协议中的消息。 
(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。 p16 
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。 
如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。 
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。p17 
(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。 p18 
(8)类应该只表示一个关键抽象。 
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 . 
(9)把相关的数据和行为集中放置。 
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。 
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。p19 
朝着稳定的方向进行依赖. 
(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。p23 
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。 
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。 
规划一个接口而不是实现一个接口。 
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。 
(15)对包含太多互不沟通的行为的类多加小心。 
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。 
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。 
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。 
(18)从你的设计中去除不需要的类。 
一般来说，我们会把这个类降级成一个属性。 
(19)去除系统外的类。 
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。 
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。 
(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。 
(22)尽量减少类的协作者的数量。 
一个类用到的其他类的数目应当尽量少。 
(23)尽量减少类和协作者之间传递的消息的数量。 
(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。 
(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积 
(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。 
(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。 


(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。 
当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。 
(29)让系统功能在窄而深的继承体系中垂直分布。 
(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。 
(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。 
(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中 
(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。 
(34)类必须知道它包含什么，但是不能知道谁包含它。 
(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系 
(36)继承只应被用来为特化层次结构建模。 
(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。 
(38)基类中的所有数据都应当是私有的，不要使用保护数据。 

类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。 
(39)在理论上，继承层次体系应当深一点，越深越好。 
(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6 
(41)所有的抽象类都应当是基类 
(42)所有的基类都应当是抽象类 
(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。 
(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。 
(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。 (46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。 (47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。 
(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。 


(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。 
(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。 
(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。 
(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。 
(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。 
(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。 
(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。 
(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？ 
(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。 
(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。 
(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。 
(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。 
(61)不要绕开公共接口去修改对象的状态。