PHP面向对象分析设计的61条军规

(1)全部数据都应该隐藏在所在的类的内部。 (2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。 (3)尽可能减小类的协议中的消息。 (4)实现全部类都理解的最基本公有接口[例如，拷贝操做(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。 (5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。若是类的两个方法有一段公共代码，那么就能够建立一个防止这些公共代码的私有函数。 (6)不要以用户没法使用或不感兴趣的东西扰乱类的公有接口。 (7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另外一个类毫无关系，要么只使用另外一个类的公有接口中的操做。 (8)类应该只表示一个关键抽象。 包中的全部类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的全部类产生影响，而对其余的包不形成任何影响 . (9)把相关的数据和行为集中放置。设计者应当留意那些经过get之类操做从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。 (10)把不相关的信息放在另外一个类中(也即：互不沟通的行为)。朝着稳定的方向进行依赖. (11)确保你为之建模的抽象概念是类，而不仅是对象扮演的角色。 (12)在水平方向上尽量统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工做。 (13)在你的系统中不要建立全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加当心。规划一个接口而不是实现一个接口。 (14)对公共接口中定义了大量访问方法的类多加当心。大量访问方法意味着相关数据和行为没有集中存放。 (15)对包含太多互不沟通的行为的类多加当心。这个问题的另外一表现是在你的应用程序中的类的公有接口中建立了不少的get和set函数。 (16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不该该依赖于界面，界面则应当依赖于模型。 (17)尽量地按照现实世界建模(咱们经常为了遵照系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。 (18)从你的设计中去除不须要的类。通常来讲，咱们会把这个类降级成一个属性。 (19)去除系统外的类。系统外的类的特色是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其余类发出的消息。 (20)不要把操做变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者还没有发现的某个类中。 (21)咱们在建立应用程序的分析模型时经常引入代理类。在设计阶段，咱们常会发现不少代理没有用的，应当去除。 (22)尽可能减小类的协做者的数量。一个类用到的其余类的数目应当尽可能少。 (23)尽可能减小类和协做者之间传递的消息的数量。 (24)尽可能减小类和协做者之间的协做量，也即：减小类和协做者之间传递的不一样消息的数量。 (25)尽可能减小类的扇出，也即：减小类定义的消息数和发送的消息数的乘积。 (26)若是类包含另外一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系老是意味着使用关系。 (27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。 (28)类包含的对象数目不该当超过开发者短时间记忆的容量。这个数目经常是6。当类包含多于6个数据成员时，能够把逻辑相关的数据成员划分为一组，而后用一个新的包含类去包含这一组成员。 (29)让系统功能在窄而深的继承体系中垂直分布。 (30)在实现语义约束时，最好根据类定义来实现。这经常会致使类泛滥成灾，在这种状况下，约束应当在类的行为中实现，一般是在构造函数中实现，但不是必须如此。 (31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所容许的尽可能深的包含层次中。 (32)约束所依赖的语义信息若是常常改变，那么最好放在一个集中式的第3方对象中。 (33)约束所依赖的语义信息若是不多改变，那么最好分布在约束所涉及的各个类中。 (34)类必须知道它包含什么，可是不能知道谁包含它。 (35)共享字面范围(也就是被同一个类所包含)的对象相互之间不该当有使用关系。 (36)继承只应被用来为特化层次结构建模。 (37)派生类必须知道基类，基类不该该知道关于它们的派生类的任何信息。 (38)基类中的全部数据都应当是私有的，不要使用保护数据。类的设计者永远都不该该把类的使用者不须要的东西放在公有接口中。 (39)在理论上，继承层次体系应当深一点，越深越好。 (40)在实践中，继承层次体系的深度不该当超出一个普通人的短时间记忆能力。一个广为接受的深度值是6。 (41)全部的抽象类都应当是基类。 (42)全部的基类都应当是抽象类。 (43)把数据、行为和/或接口的共性尽量地放到继承层次体系的高端。 (44)若是两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每一个共享这个数据的类都包含这个类。 (45)若是两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每个都应当从一个表示了这些数据和方法的公共基类继承。 (46)若是两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们须要被多态地使用时，他们才应当从一个公共基类继承。 (47)对对象类型的显示的分状况分析通常是错误的。在大多数这样的状况下，设计者应当使用多态。 (48)对属性值的显示的分状况分析经常是错误的。类应当解耦合成一个继承层次结构，每一个属性值都被变换成一个派生类。 (49)不要经过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会致使在运行时切换类型。 (50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加当心。 (51)若是你以为须要在运行时刻建立新的类，那么退后一步以认清你要建立的是对象。如今，把这些对象归纳成一个类。 (52)在派生类中用空方法(也就是什么也不作的方法)来覆写基类中的方法应当是非法的。 (53)不要把可选包含同对继承的须要相混淆。把可选包含建模成继承会带来泛滥成灾的类。 (54)在建立继承层次时，试着建立可复用的框架，而不是可复用的组件。 (55)若是你在设计中使用了多重继承，先假设你犯了错误。若是没犯错误，你须要设法证实。 (56)只要在面向对象设计中用到了继承，问本身两个问题：(1)派生类是不是它继承的那个东西的一个特殊类型？(2)基类是否是派生类的一部分？ (57)若是你在一个面向对象设计中发现了多重继承关系，确保没有哪一个基类其实是另外一个基类的派生类。 (58)在面向对象设计中若是你须要在包含关系和关联关系间做出选择，请选择包含关系。 (59)不要把全局数据或全局函数用于类的对象的薄记工做。应当使用类变量或类方法。 (60)面向对象设计者不该当让物理设计准则来破坏他们的逻辑设计。可是，在对逻辑设计做出决策的过程当中咱们常常用到物理设计准则。 (61)不要绕开公共接口去修改对象的状态。