php网站空间支持,企业在线查询系统平台,Hugo wordpress,外贸建站哪家强外贸网站怎么做1. 开闭原则#xff08;the Open Closed Principle OCP#xff09; 一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法#xff0c;是软件工程 设计… 1. 开闭原则the Open Closed Principle OCP 一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法是软件工程 设计方法的重要原则之一。 我们以收音机的例子为例讲述面向对象的开闭原则。我们收听节目时需要打开收音机电源对准电台频率和进行音量调节。但是对于不同的收音机实现这三个步骤的细节往往有所不同。比如自动收缩电台的收音机和按钮式收缩在操作细节上并不相同。因此我们不太可能针对每种不同类型的收音机通过一个收音机类来实现通过重载这些不同的操作方式。但是我们可以定义一个收音机接口提供开机、关机、增加频率、降低频率、增加音量、降低音量六个抽象方法。不同的收音机继承并实现这六个抽象方法。这样新增收音机类型不会影响其它原有的收音机类型收音机类型扩展极为方便。此外已存在的收音机类型在修改其操作方法时也不会影响到其它类型的收音机。 图1是一个应用OCP生成的收音机类图的例子 2. 替换原则 (the Liskov Substitution Principle LSP) 子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract) 的概念推出。 我们以学生为例夜校生为学生的子类因此在任何学生可以出现的地方夜校生均可出现。这个例子有些牵强一个能够反映这个原则的例子时圆和椭圆圆是椭圆的一个特殊子类。因此任何出现椭圆的地方圆均可以出现。但反过来就可能行不通。 Liskov的相关图示见下图 运用替换原则时我们尽量把类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组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类为每一个客户创建特定业务接口然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。 下图展示了一个拥有多个客户的类。它通过一个巨大的接口来服务所有的客户。只要针对客户A的方法发生改变客户B和客户C就会受到影响。因此可能需要进行重新编译和发布。这是一种不幸的做法。 以上四个原则是面向对象中常常用到的原则。此外除上述四原则外还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化一个类对应一个具体职责等可供我们在进行面向对象设计参考。但就上面的几个原则看来我们看到这些类在几何分布上呈现树型拓扑的关系这是一种良好、开放式的线性关系、具有较低的设计复杂度。一般说来在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系它们反映的是较大的耦合度和设计复杂化。 转载于:https://www.cnblogs.com/wolfrickwang/p/3326068.html
