第三讲 软件架风格和设计原则.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Dependency Inversion Principle (DIP) 要依赖于抽象，不要依赖于具体 抽象层次包含的是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性的决定，是必然性的体现 具体层次则含有一些次要的，与实现相关的算法和逻辑以及战术性的决定，带有相当大的偶然性 表述 ?Abstractions should not depend upon details. Details should depend upon abstractions.（抽象不应当依赖细节，细节应当依赖抽象） ?Program to an interface, not a implementation.（要针对接口编程，而不要针对实现编程） Interface Segregation Principle (ISP) 从一个客户角度来讲，一个类对另一个类的依赖性应当建立在最小的接口上 原则 角色分割 定制服务 聚合(Aggregation)关系 是关联的一种，是强的关联关系，是整体与个体的关系。 依赖(Dependency)关系 是类与类之间的连接，依赖总是单向的。依赖表示一个类依赖于另一个类的定义。 通常被依赖的对象以方法的参数或返回表示。 Law of Demeter (LoD) 又称为最少知识原则 Least Knowledge Principle (LKP) 表述 only talk to your immediate friends“只与你直接的朋友们通信” Don’t talk to strangers “不要与陌生人讲话” 每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位 狭义迪米特法则 如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一方法的话，可以通过第三者转发这个调用 狭义迪米特法则 与依赖倒转原则的互补使用 广义迪米特法则?控制信息过载 在类的划分上，应当创建弱耦合的类。类之间的耦合越弱，就越有利于复用 在类的结构设计上，每一个类都应当尽量降低成员的访问权限(Accessibility) 在类的设计上，只要有可能，一个类应当设计成不变类(Immutable) 在对其它类的引用上，一个对象对其实例的引用应当降到最低 组合/聚集复用原则(CARP ，Composite/Aggregate Reuse Principle)。 组合和聚集都是对象建模中关联（Association）关系的的一种。 聚集表示的是整体和部分的关系，表示“含有”，整体由部分组合而成，部分可以脱离部分作为一个独立的个体而存在。 组合则是一种更强的“拥有”，部分组成整体，而且不可分割，部分不能脱离整体而单独存在。 合成关系中，部分和整体的生命周期一样，组合的新的对象完全支配其组成部分，包括它们的创建和湮灭等。 一个合成关系的成分对象是不能与另一个合成关系共享的。 重用发布等价原则(REP) 重用的粒度就是发布的粒度。 共同封闭原则(CCP) 包中的所有类对于同一类性质的变化应该是共同封闭的。 一个变化若对一个包产生影响，则将对该包中的所有类产生影响， 而对于其他的包不造成任何影响。 共同重用原则(CRP) 一个包中的所有类应该是共同重用的。 如果重用了包中的一个类， 那么就要重用包中的所有类。 (相互之间没有紧密联系的类不应该在同一个包中。) 无环依赖原则(ADP) 在包的依赖关系图中不允许存在环。 稳定依赖原则(SDP) 朝着稳定的方向进行依赖。 应该把封装系统高层设计的软件（比如抽象类）放进稳定的包中， 不稳定的包中应该只包含那些很可能会改变的软件（比如具体类）。 稳定抽象原则(SAP) 包的抽象程度应该和其稳定程度一致。 (一个稳定的包应该也是抽象的，一个不稳定的包应该是抽象的. )  BBP(Black Box Principle)黑盒原则 多用类的聚合，少用类的继承。 DAP(Default Abstraction Principle)缺省抽象原则 在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作. IDP(Interface Design Principle)接口设计原则 规划一个接口而不是实现一个接口。 DCSP(Don‘t Concrete Supperclass Principle)不要构造具体的超类原则，避免维护具体的。  分解 人们面对复杂性有一个常见的做法：