面向对象基本原则Word下载.docx

1、这里类包括两个职责，显然违反了SRP。这样做有潜在的隐患，如果要改变连接的方式，势必要修改Modem，而修改Modem类的结果导致凡事依赖Modem类可能都需要修改，这样就需要重新编译和部署，不管数据传输这部分是否需要修改。因此要重构Modem类，从中抽象出两个接口，一个专门负责连接，另一个专门负责数据传送。依赖Modem类的元素要做相应的细化，根据职责的不同分别依赖不同的接口。如下图：这样以来，无论单独修改连接部分还是单独修改数据传送部分，都彼此互不影响。总结单一职责优点：降低类的复杂性，提高可维护性提高可读性。降低需求变化带来的风险。需求变化是不可避免的，如果单一职责做的好，一个接口修改只

2、对相应的实现类有影响，对其它的接口无影响，这对系统的扩展性和维护性都有很大的帮助。2里氏替换原则（LiskovSubstitutionLSP）里氏替换原则是面向对象设计的基本原则之一。任何基类可以出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当子类可以替换基类，软件单位的功能不受影响时，基类才能真正的被复用，而子类也可以在基类的基础上增加新的行为。Liskov提出了关于继承的原则：Inheritanceensurethatanypropertyprovedaboutsupertypeobjectsalsoholdssubtypeobjects.-继承必须确保超类中所拥有的性质在子类

3、中仍然成立。2002年，软件工程大师RobertC.Martin出版了一本AgileSoftwareDevelopmentPrinciplesPatternsandPractices，在文中他把里氏代换原则最终简化为一句话：“Subtypesmustsubstitutabletheirbasetypes”也就是说子类必须能够替换成他们的基类。里氏替换原则讲的是基类和子类的关系，只有这种关系存在的时候里氏替换原则才能成立。里氏替换原则是实现开放封闭原则的具体规范。这是因为：实现开放封闭原则的关键是抽象，而继承关系又是抽象的一种具体实现。我们大家都打过CS的游戏，用枪射击杀人，如下类图：枪的主要职

4、责是射击，如何射击在各个具体的子类中定义。注意在类中调用其他类时务必调用父类或接口，如果不能掉话父类或接口，说明类的射击已经违反了LSP原则。如果我们有一个玩具手枪，该如何定义呢？我们先在类图2-1上增加一个类ToyGun，然后继承于AbstractGun类，修改后的类图如下：玩具枪是不能用来射击的，杀不死人的，这个不应该写shoot方法，在这种情况下业务的调用类就会出现问题。为了解决这个问题，ToyGun可以脱离继承，建立一个独立的父类，为了做到代码可以服用，可以与AbstractGun建立关联委托关系，如下图：因此，如果子类不能完整地实现父类的方法，那么建议断开父子继承关系，采用依赖，聚合

5、，组合等关系代替继承。子类可以有自己的属性或方法。覆盖或实现父类的方法时输入的参数可以放大。覆盖或实现父类的方法时输出结果可以被缩小。这是什么意思呢，父类的方法返回值是一个类型T，子类相同的方法（覆写）的返回值为类型S，那么根据里氏替换原则就要求S必须小于等于T，也就是说要么S和T是同一个类型，要么S是T的子类型。采用里氏替换原则的目的就是增加程序的健壮性，需求变更时也可以保持良好的兼容性和稳定性，即使增加子类，原有的子类可以继续运行。在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同业务逻辑。3依赖倒置原则（DependenceInversionDIP）所谓依

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

7、系列上使用。面向过程的结构图：实现代码如下：publicHondaCarvoidRun（）Console.WriteLine（本田车启动了！）;Turn（）本田车拐弯了！Stop（）本田车停止了！FordCar福特车启动了！福特车拐弯了！福特车停止了！AutoSystemenumCarTypeFord,FondaprivateHondaCarhondcar=newHondaCar（）;fordcar=newFordCar（）;CarTypetype;AutoSystem（CarTypecarType）this.type=carType;RunCar（）if（this.type=CarType.

8、Fonda）hondcar.Run（）;elseCarType.Ford）fordcar.Run（）;StopCar（）hondcar.Stop（）;fordcar.Stop（）;TurnCar（）hondcar.Turn（）;fordcar.Turn（）;显然这个实现代码也可满足现在的需求。但是如何现在公司业务规模扩大了，该自动驾驶系统还要把吉普车也兼容了。这些就需要修改AutoSystem类如下：Ford,Fonda,JeepJeepjeepnewJeep（）;CarType.Jeep）jeep.Run（）;jeep.Stop（）;jeep.Turn（）;通过代码分析得知，上述代码也确实满

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

10、机制。如下类图：interfaceICarRun（）;Stop（）;Turn（）;HondaCar:Jeep:ICarcar;AutoSystem（ICarcar）this.carthis.car.Run（）;this.car.Stop（）;this.car.Turn（）;现在Autosystem系统依赖于ICar这个抽象，而与具体的实现细节HondaCar:和FordCar无关，所以实现细节的变化不会影响AutoSystem.对于实现细节只要实现ICar即可。即实现细节依赖于ICar抽象。综上所述：一个应用中的重要策略决定及业务正是在这些高层的模块中。也正是这些模块包含这应用的特性。但是，当

11、这些模块依赖于低层模块时，低层模块的修改比较将直接影响到他们，迫使它们也改变。这种情况是荒谬的。应该是处于高层的模块去迫使那些低层的模块发生改变。处于高层的模块应优先于低层的模块。无论如何高层模块也不应该依赖于低层模块。而且我们想能够复用的是高层的模块，只有高层模块独立于低层模块时，复用才有可能。总之，高层次的模块不应该依赖于低层次的模块，它们都应该依赖于抽象。抽象不应该依赖于具体，具体应该依赖于抽象。4迪米特法则迪米特法则（LawofDemeter）又叫最少知识原则（LeastKnowledgeLKP），就是说一个对象应当对其他对象有尽可能少的了解，不和陌生人说话。对面向对象来说，一个软件实

12、体应当尽可能的少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而其局限于那些与本单位密切相关的软件单位。迪米特法则的目的在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块相互独立，相互之间不存在依赖关系。应用迪米特法则有可能造成的一个后果就是，系统中存在的大量的中介类，这些类只所以存在完全是为了传递类之间的相互调用关系-这在一定程度上增加系统的复杂度。设计模式中的门面模式（Facade）和中介模式（Mediator）都是迪米特法则的应用的例子。狭义的迪米特法则的缺点：在系统里面造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的商

13、业逻辑无关。遵循类之间的迪米特法则会使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有之间的关联。但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。广义的迪米特法则在类的设计上的体现：优先考虑将一个类设置成不变类.尽量降低一个类的访问权限。尽量降低成员的访问权限。下面的代码在方法体内部依赖了其他类，这严重违反迪米特法则12345678910111213Teachercommond（GroupLeadergroupLeader）ListlistGirlsArrayList（）;（inti0;20;i+）listGirls.add（newGirl（）

14、;groupLeader.countGirls（listGirls）;方法是类的一个行为，类竟然不知道自己的行为与其他类产生了依赖关系，这是不允许的。正确的做法是：groupLeader.countGirls（）;GroupLeaderlistGirls;GroupLeader（List_listGirls）this.listGirls_listGirls;countGirls（）System.out.println（女生数量是：+listGirls.size（）;5开放封闭原则（Open-ClosedOCP）entities（classes,modules,functionsetc）open

15、extension,butclosemodification.所谓开放封闭原则就是软件实体应该对扩展开发，而对修改封闭。开放封闭原则是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化，降低耦合，而开放封闭原则正是对这一目标的最直接体现。开放封闭原则主要体现在两个方面：对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。对修改封闭，意味着类一旦设计完成，就可以独立其工作，而不要对类尽任何修改。为什么要用到开放封闭原则呢？软件需求总是变化的，世界上没有一个软件的是不变的，因此对软件设计人员来说，必须在不需要对原有系统进行修改的情况下，实现灵活的系统扩展。如何做到对扩展开放，对修改封闭呢？实现开放封闭的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以对修改就是封闭的；而通过面向对象的继承和多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的。对于违反这一原则的类，必须通过重构来进行改善。常用于实现的设计模式主要有TemplateMethod模式和Strategy模式。而封装变化，是实现这一原则的重要手段，将经常变化的状态封装为一个类。以银行