面向对象设计原则

  所有的设计模式都是对不同的可变性的封装，从而使系统在不同角度达到“开闭原则”的要求。
　　
　　在软件软件系统中，一个模块设计得好不好的最主要、最重要的标志，就是该模块在多大程度上将自己的内部数据和其他与实现有关的细节隐藏起来。一个设计得好的模块可以将它所有的实现细节隐藏起来，彻底地将提供给外界的API和自己的实现分隔开来。这样一来，模块与模块之间就可以仅仅通过彼此的API相互通信，而不理会模块内部的工作细节。
　　
　　
　　OO设计根本的指导原则是提高可维护性和可复用性。这些原则主要有：
　　1. 开闭原则
　　一个软件实体应该对扩展开放，对修改关闭。
　　在设计一个模块的时候，就当使这个模块可以在不被修改的前提下被扩展。换言之，就当可以在不必修改源代码的情况下改变这个模块的行为。
　　
　　如何做到既不修改，又可以扩展？
　　解决问题的关键在于抽象化：在Java语言里，可以给出一个或多个抽象Java类或Java接口，规定出所有的具体类必须提供的方法特征作为系统设计的抽象层。这个抽象层预见了所有的可能扩展，因此，在任何扩展情况下都不会改变。这就使得系统的抽象层不需要修改，从而满足了—对修改关闭。
　　同时，由于从抽象层导出一个或多个新的具体类可以改变系统的行为，因此系统的设计对扩展是开放的。
　　
　　开闭原则实际上是对“对可变性的封闭原则“：找到一个系统的可变因素，将之封装起来。这个原则意昧着两点：
　　1) 一个可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里面。同一种可变性的不同表象意昧着同一个继承等级结构中的具体子类。
　　继承就当被看作是封装变化的方法，而不应当被认为是从一般的对象生成特殊对象的方法。
　　2) 一种可变性不应当与另一种可变性混合在一起。（所有类图的继承结构一般不会超过两层，不然就意昧着将两种不同的可变性混合在了一起。）
　　
　　开闭原则是总的原则，其它几条是开闭原则的手段和工具。
　　
　　2. 依赖倒转原则
　　依赖倒转原则讲的是：要依赖于抽象，不要信赖于实现。
　　开闭原则是目标，而达到这一目标的手段是依赖倒转原则。
　　抽象层次包含的是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定，是必然性的体现；而具体层次则含有一些次要的与实现有关的算法和逻辑，以及战术性的决定，带有相当大的偶然性选择。具体层次的代码是会经常有变动的，不能避免出现错误。
　　抽象层次含有一个应用系统最重要的宏观商务逻辑，是做战略判断和决定的地方，那么抽象层次就应当是较为稳定的，应当是复用的重点；也应当是维护的重点。
　　在很多情况下，一个Java程序需要引用一个对象。这个时候，如果这个对象有一个抽象类型的话，应当使用这个抽象类型作为变量的静态类型。这就是针对接口编程的含义。
　　一般而言，在创建一个对象时，Java语言要求使用new关键词以及这个类本身。而一旦这个对象已经被创建出来，那么就可以灵活地使用这个对象的抽象类型来引用它。比如：List employees = new Vector()；因此，Java语言中创建一个对象的过程是违背“开闭原则”以及依赖倒转原则的（因为先生成了具体的类型，再使用抽象的引用），虽然在这个类被创建出来以后，可以通过多态性使得客户端依赖于其抽象类型。正是由于这个问题，设计模式给出了多个创建模式，特别是几个工厂模式，用于解决对象创建过程中的依赖倒转问题。
　　工厂模式将创建一个类的实例的过程封装起来，消费这个实例的客户端仅仅取得实例化的结果，以及这个实例的抽象类型。当然，任何方法都无法回避Java语言所要求的new关键字和直接调用具体类的构造子的做法（这违背了里氏代换原则）。简单工厂模式将这个违反“开闭原则”和依赖倒转原则的做法封装到了一个类里面，而工厂方法模式将这个违反原则的做法推迟到了具体工厂角色中。通过适当的封装，工厂模式可以净化大部分的结构，而将违反原则的做法孤立到易于控制的地方。
　　
　　联合使用Java接口和Java抽象类：声明类型的工作由Java接口承担，但是同时给出的还有一个Java抽象类，为这个接口给出一个缺省实现。如果一个具体类直接实现这个Java接口的话，它就必须自行实现所有的接口；相反，如果它继承自抽象类的话，它就可以省去一些不必要的方法，因为它可以从抽象类中自动得到这些方法的缺省实现。这其实就是缺省适配模式。
　　
　　依赖倒转的缺点：
　　1) 因为依赖倒转的缘故，对象的创建很可能要使用对象工厂，以避免对具体类的直接引用，此原则的使用还会导致大量的类。对不熟悉面向对象技术的工程师来说，维护这样的系统需要较好地面向对象的设计知识。
　　2) 依赖倒转原则假定所有的具体类都是会变化的，这也不总是正确的。有一些具体类可能相当稳定、不会发生变化，消费这个具体类实例的客户端完全可以依赖这个具体类型，而不必为此发明一个抽象类型。
　　
　　3. 里氏代换原则
　　任何基类可以出现的地方，子类一定可以出现。
　　开闭原则的关键步骤是抽象化。而基类与子类的继承关系就是抽象化的具体体现，里氏代换原则是对实现抽象化的具体步骤的规范。
　　
　　4. 合成/聚合复用原则
　　要尽量使用合成/聚合，而不是继承关系达到复用的目的。
　　合成/聚合原则要求我们首先考虑合成/聚合关系，里氏代换原则要求在使用继承时，必须确定这个继承关系符合一定的条件（继承是用来封装变化的；任何基类可以出现的地方，子类一定可以出现。）
　　
　　合成/聚合原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到得复用已有功能的目的。
　　
　　5. 迪米特原则
　　一个软件实体应当尽可能少的其他实体发生相互作用。模块之间的交互要少。这样做的结果是当系统的功能需要扩展时，会相对更容易地做到对修改的关闭。
　　一个对象应当对其他对象有尽可能少的了解。
　　
　　迪米特原则的具体操作：
　　1) 优先考虑将一个类设置成不变类。不变类易于设计、实现和使用。比如Java API中的String，BigInteger等类。
　　一个对象与外界的通信大体上分成两种，一种是改变这个对象的状态，另一种是不改变这个对象的状态的。如果一个对象的内部状态根本就是不可能改变的，那么它与外界的通信当然就大大地减少。
　　当涉及任何一个类的时候，都首先考虑这个类的状态是否需要改变。即便一个类必须是可变类，在给它的属性设置赋值方法的时候，也要保持吝啬的态度。除非真的需要，否则不要为一个属性设置赋值方法。
　　
　　2) 尽量降低一个类的访问权限。
　　3) 谨慎使用Serializable，一旦将一个类设置成Serializable，就不能再在新版本中修改这个类的内部结构，包括private的方法和句段。
　　4) 尽量降低成员的访问权限。
　　
　　6. 接口隔离原则
　　应当为客户端提供尽可能小的单独接口，而不要提供大的总接口。也即是使用多个专门的接口比使用单一的总接口要好。
　　接口隔离原则与迪米特都是对一个软件实体与其他的软件实体的通信限制。迪米特原则要求尽可能地限制通信的宽度和深度，接品隔离原则要求通信的宽度尽可能地窄。这样做的结果使一个软件系统在功能扩展过程当中，不会将修改的压力传递到其他对象。
　　
　　一个接口相当于剧本中的一种角色，而此角色在一个舞台上由哪一个演员来演则相当于接口的实现。因此，一个接口应当简单地代表一个角色，而不是多个角色。如果系统涉及到多个角色的话，那么每一个角色都应当由一个特定的接口代表。
　　
　　定制服务：如果客户端仅仅需要某一些方法的话，那么就应当向客户端提供这些需要的方法，而不要提供不需要的方法。（向客户端提供public接口是一种承诺，没有必要做出不必要的承诺，过多的承诺会给系统的维护造成不必要的负担。）

///////////////////

 

在java 设计模式中存在几个重要的设计原则：

1、里氏代换原则（LSP）

 里氏代换原则的严格表达是：

如果对每一个类型为T1的对象O1，都有类型为T2的对象O2，使得以T1定义的所有程序P在所有的对象O1都代换成O2时，程序P的行为没有变化，那么类型T2是类型T1的子类型。

2、依赖倒转原则（DIP）

依赖倒转原则的表述是：

抽象不应当依赖于细节；细节应当依赖于抽象。（Abstractions should not depend upon details. Details should depend upon abstractions）。他的另外一种表述是： 要针对接口编程，不要针对实现编程（Program to an interface, not an implement-action ）

3、接口隔离原则（ISP ）

使用多个专门的接口比使用单一的总接口要好。

4、合成/聚合复用原则（CARP）

成/聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新的对象一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。

这个原则还有另外一个表书：要尽量使用合成/聚合，尽量不要使用继承

5、迪米特法则（LOD）

 表书众多！

////////////////////////////

 

Java设计原则 <script></script>

 

1.       首先明确，对象间的通信，有两种方式，一种是隐式的，一种是显式的，所谓的显式，就是点对点的通信，所谓的隐式，就是广播，打个比方，老师叫学生，说：小明起来回答问题，ok，这是老师和小明的显示通信，老师又说了：哪个学生起来回答问题，OK，这个是老师与学生的隐式通信。

2.       明确了通信的原理后，我们还需要知道，显式和隐式都各有什么特点，ok，显式的是一对一的，效率高，但是固定了通信的对象，不够灵活，隐式的效率虽然比显式低，但是灵活度高。

3.       了解了以上的情况后，就可以进行具体的设计，一般来说，一个应用程序是可以分层的

呈现样式

功能细节

工作流程

组织结构

数据结构和算法             

自下而上，越来越容易变化，所以在越低层要使用显式通信，提高效率，高层要使用隐式通信，提高灵活性来适应变化。有了这样的需求，在高层，其实就是类的设计，在底层就是数据结构和算法的设计，数据结构和算法靠基础，类的设计靠经验的积累，但是我们还是可以寻找到一些类设计的规律

4.       遵循OCP原则，就是代码可增加，不可改变，按我们老师说的话，代码坏了，不是写坏的，是改坏的，我相信很多人有这种感觉，我也有，感受很深刻，所以，在旧系统扩展功能或者其他需求，都应该是尽量加代码，而不是修改源代码。

5.       理解类间关系也是很重要的，一般来说类间有5种关系，依赖<关联<聚合<组合<继承

小于号表示他们耦合度的对比，这里，要明确关系，依赖，是一个类的方法参数，用到另外一个类，或者方法内生成另外一个类对象，也就是临时对象，这样的两个类有依赖关系；关联，概念上的1对1、1对多、多对多的关系，比如1个老师对多个学生，但是老师不应该有学生的集合作为属性，也就是说他们是1对多的关联关系;聚合，是包含拥有的语义，对象间是松散的，部分可能属于多个整体，可以分布创建；组合是一个部分对象只能属于一个整体对象，整体没了部分自然就没了

6.       了解这些关系在你设计Class UML时是很有用的，在设计类时，优先考虑聚合，然后考虑继承，继承的最多层应该不超过3层，包括3层，所有的类设计，都是为了一个目标，就是封装变化！所以说面向对象的编程，就是面向接口的编程，永远在设计的时候，不要想着实现，这就是23种设计模式的起源，如果注意就会发现，这23种设计模式，都是基于抽象类和接口的，这就是面向接口，不在乎具体实现，将实现延迟到子类，封装变化，让业务逻辑随着变化而变化，方便快捷，达到面向对象的深层次设计，初学者会认为为什么要设计模式，为什么要那么复杂，实际上，你需要真实的体验去感受，而不是硬逼着自己去理解，自然而然的你就会理解了，但是需要经过失败，就比如我的项目，第一次非常完美，但是需求有变化的时候，我才发现编程好痛苦，没设计好是多么痛苦啊！呵呵 现在再看设计模式，感慨万千啊。