Java基础-面向对象编程的几个原则.docx

Java基础:面向对象编程的几个原则
一个模块在扩展性方面应当是开放的而在更改性方面应当是封闭的。因此在进展面对对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面对对象设计的方法，是软件工程设计方法的重要原则之一。我们以收音机的例子为例，叙述面对对象的开闭原则。我们收听节目时需要翻开收音机电源，对准电台频率和进展音量调整。但是对于不同的收音机，实现这三个步骤的细节往往有所不同。比方自动收缩电台的收音机和按钮式收缩在操作细节上并不一样。因此，我们不太可能针对每种不同类型的收音机通过一个收音机类来实现（通过重载）这些不同的操作方式。但是我们可以定义一个收音机接口，供应开机、关机、增加频率、降低频率、增加音量、降低音量六个抽象方法。不同的收音机继承并实现这六个抽象方法。这样新增收音机类型不会影响其它原有的收音机类型，收音机类型扩展极为便利。此外，已存在的收音机类型在修改其操作方法时也不会影响到其它类型的收音机。
　　2. 替换原则 （the Liskov Substitution Principle LSP）
　　子类应当可以替换父类并消失在父类能够消失的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC （Design by Contract） 的概念推出。
　　我们以学生为例，夜校生为学生的子类，因此在任何学生可以消失的地方，夜校生均可消失。这个例子有些牵强，一个能够反映这个原则的例子时圆和椭圆，圆是椭圆的一个特别子类。因此任何消失椭圆的地方，圆均可以消失。但反过来就可能行不通。
　　运用替换原则时，我们尽量把类B设计为抽象类或者接口，让C类继承类B（接口B）并实现操作A和操作B，运行时，类C实例替换B，这样我们即可进展新类的扩展（继承类B或接口B），同时无须对类A进展修改。
　　3. 依靠原则 （the Dependency Inversion Principle DIP）
　　在进展业务设计时，与特定业务有关的依靠关系应当尽量依靠接口和抽象类，而不是依靠于详细类。详细类只负责相关业务的实现，修改详细类不影响与特定业务有关的依靠关系。
　　在构造化设计中，我们可以看究竟层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依靠详细实现相关的模块，底层模块的详细实现发生变动时将会严峻影响高层抽象的模块，明显这是构造化方法的一个“硬伤“.
　　面对对象方法的依靠关系刚好相反，详细实现类依靠于抽象类和接口。
　　为此，我们在进展业务设计时，应尽量在接口或抽象类中定义业务方法的原型，并通过详细的实现类（子类）来实现该业务方法，业务方法内容的修改将不会影响到运行时业务方法的调用。
　　4. 接口分别原则（the Interface Segregation Principle ISP）
　　采纳多个与特定客户类有关的接口比采纳一个通用的涵盖多个业务方法的接口要好。
　　ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。
　　这个原则的本质相当简洁。假如你拥有一个针对多个客户的类，为每一个客户创立特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需全部方法有效。
　　以上四个原则是面对对象中经常用到的原则。此外，除上述四原则外，还有一些常用的阅历诸如类构造层次以三到四层为宜、类的职责明确化（一个类对应一个详细职责）等可供我们在进展面对对象设计参考。但就上面的几个原则看来，我们看到这些类在几何分布上呈现树型拓扑的关系，这是一种良好、开放式的线性关系、具有较低的设计简单度。一般说来，在软件设计中我们应当尽量避开消失带有闭包、循环的设计关系，它们反映的是较大的耦合度和设计简单化。