你不必严格遵守这些原则违背它们也不会被处以宗教刑罚但你应当把这些原则看成警铃若违背了其中的一条那么警铃就会响起 Arthur JRiel
()所有数据都应该隐藏在所在的类的内部
()类的使用者必须依赖类的共有接口但类不能依赖它的使用者
()尽量减少类的协议中的消息
()实现所有类都理解的最基本公有接口[例如拷贝操作(深拷贝和浅拷贝)相等性判断正确输出内容从ASCII描述解析等等
()不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中
如果类的两个方法有一段公共代码那么就可以创建一个防止这些公共代码的私有函数
()不要以用户无法使用或不感兴趣的东西扰乱类的公有接口
()类之间应该零耦合或者只有导出耦合关系也即一个类要么同另一个类毫无关系要么只使用另一个类的公有接口中的操作
()类应该只表示一个关键抽象
包中的所有类对于同一类性质的变化应该是共同封闭的一个变化若对一个包影响则将对包中的所有类产生影响而对其他的包不造成任何影响
()把相关的数据和行为集中放置
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象这种类型的行为暗示着这条经验原则被违反了
()把不相关的信息放在另一个类中(也即互不沟通的行为)
朝着稳定的方向进行依赖
()确保你为之建模的抽象概念是类而不只是对象扮演的角色
()在水平方向上尽可能统一地分布系统功能也即按照设计顶层类应当统一地共享工作
()在你的系统中不要创建全能类/对象对名字包含DriverManagerSystemSusystem的类要特别多加小心
规划一个接口而不是实现一个接口
()对公共接口中定义了大量访问方法的类多加小心大量访问方法意味着相关数据和行为没有集中存放
()对包含太多互不沟通的行为的类多加小心
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数
()在由同用户界面交互的面向对象模型构成的应用程序中模型不应该依赖于界面界面则应当依赖于模型
()尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则)
()从你的设计中去除不需要的类
一般来说我们会把这个类降级成一个属性
()去除系统外的类
系统外的类的特点是抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息
()不要把操作变成类质疑任何名字是动词或者派生自动词的类特别是只有一个有意义行为的类考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中
()我们在创建应用程序的分析模型时常常引入代理类在设计阶段我们常会发现很多代理没有用的应当去除
()尽量减少类的协作者的数量
一个类用到的其他类的数目应当尽量少
()尽量减少类和协作者之间传递的消息的数量
()尽量减少类和协作者之间的协作量也即减少类和协作者之间传递的不同消息的数量
()尽量减少类的扇出也即减少类定义的消息数和发送的消息数的乘积
()如果类包含另一个类的对象那么包含类应当给被包含的对象发送消息也即包含关系总是意味着使用关系
()类中定义的大多数方法都应当在大多数时间里使用大多数数据成员
()类包含的对象数目不应当超过开发者短期记忆的容量这个数目常常是
当类包含多于个数据成员时可以把逻辑相关的数据成员划分为一组然后用一个新的包含类去包含这一组成员
()让系统功能在窄而深的继承体系中垂直分布
()在实现语义约束时最好根据类定义来实现这常常会导致类泛滥成灾在这种情况下约束应当在类的行为中实现通常是在构造函数中实现但不是必须如此
()在类的构造函数中实现语义约束时把约束测试放在构造函数领域所允许的尽量深的包含层次中
()约束所依赖的语义信息如果经常改变那么最好放在一个集中式的第方对象中
()约束所依赖的语义信息如果很少改变那么最好分布在约束所涉及的各个类中
()类必须知道它包含什么但是不能知道谁包含它
()共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系
[] []
![PHP程序61条面向对象分析设计的经验原则[1]](/UploadFiles/4.jpg)