一个对象一定会有如下4个属性: 1,它的身份标示,可能只是它在内存中的地址; 2,它的类的属性(通常是静态属性)和这些属性的值(通常是动态的); 3,它的类的行为(从实现者的角度看); 3,它的公开接口(从用户的角度看). 2.1 所有数据都应该隐藏在它所在的类内部. 考虑最简单的点Point类(X,Y),再考虑可能点的实现是用的极坐标,那么是否该领悟到这一点了?   2.2,类的使用者必须依赖类的公共接口,但类不能依赖它的使用者.     房子可以依赖闹钟,但是闹钟不能依赖房子,否则这个闹钟就…

4.9 在实现语义约束时,最好根据类定义来实现.但是这经常会导致泛滥成灾的类,在这种情况下约束应当在类的行为中实现,通常在类的构造函数中实现,但不是必须如此. 还是以汽车为例,我们看汽车的定义,为了集中注意力,先只关心汽车的发动机 class 汽车 { 汽车(发动机 para) { m_发动机=para; } 发动机 m_发动机; } class 发动机{...} 我们可以定义奥迪A6,凯梅瑞等等汽车 class 奥迪A6:汽车{......} class 凯梅瑞:汽车{......} 同样我们…

4.7 类包含的对象数目不应当超过开发者短期记忆数量,这个数目通常应该是6左右 4.8 让系统在窄而深的包含体系中垂直分布 假设有如下两份菜单: 正餐 --->甜瓜 --->牛排 --->土豆 --->豌豆 --->玉米 --->馅饼 或者 正餐 --->甜瓜 --->牛排套餐 --->牛排 --->配菜--->豌豆 --->土豆 --->玉米 --->馅饼 对使用者来说,哪种更科学呢? 回答1或者回答2都是错的,面向对象…

4.6 尽量让类中定义的每个方法尽可能多地使用包含的对象(即数据成员) 这其实就是高内聚的翻版强调.如果每个类的情况并非如此,那很可能是这一个类表示了两个或更多的概念,记住一个类只应该表示一个概念. 最明显的情况就是类的一半方法使用了一半的数据成员,而另一半方法使用了另一半的数据成员,那么这个类就应该一分为二. 我们假设一个澡堂,有VIP客户和普通客户,各自有不同的服务(普通客户享受中专生服务,VIP客户享受大学生服务),则定义如下: class 澡堂 { stack<中专生> 普通服务员;…

4.5 如果类包含另一个类的对象,那么包含类应当向被包含的对象发送消息(调用方法).  也就是说,所有的包含关系都应当是使用关系. 如果不是这样,那么包含的类有什么用处呢?当然,面向过程的开发人员会想到可能有一个Get方法供其它类使用这个包含的对象,那么按照“数据隐藏原则”,为什么 不让使用包含类的类直接包含被包含的这个对象呢? 包含一个对象一定是需要使用它才包含. 比如说汽车包含了发动机,如果违背这条原则的话则定义如下: class 汽车 { 发动机 m_发动机; 发动机 Get发动机(){r…

4.1 尽量减少类的协作的数量,即减少使用者和被使用者的数量. 协作意味着一定程度的耦合,但是完全没有协作的类也是没有意义的,最多只能作为一个库使用. 通过抽象,依赖接口,可以最大程度减少依赖的实现类,对使用者来说,只看到接口的依赖,而具体的实现的依赖可以通后后期绑定来配置依赖关系. 如 菜单 ----〉牛肉 ----〉羊肉 ----〉鸡肉       可以抽象为 菜单---->肉类 <===牛肉                       <===羊肉                 …

使用关系 对象A的方法MethodA使用了B的方法MethodB,则表示A对B存在使用关系 使用关系的最关键问题在于,A如何找到B,存在6种方案 方案一: A包含了B,B作为一个成员定义在A的类中,那么在MethodA中可以直接调用B.MethodB() 如汽车可以包含车轮. 如果汽车需要加油,那么就需要调用"加油站B.加油()" class 汽车 { 加油站 m_加油站; 加油(...) { //调用某加油站的加油方法 m_加油站.加油(); } } 那么关键问题在于,汽车如何知道加…

3.7 从设计中取出不需要的类 只有Get/Set方法的类不算是一个必要的类,Get/Set方法也不算是有意义的行为.这种类降级为属性更加合适. 3.8 去除系统外部的类 如果一个类只调用系统领域的方法,而系统没有向该类调用,则可以认为这个类并不属于系统.可能只是系统的使用者,我们没必要去为此建模.     创建此类时应该问一问“这个类在系统内做什么事情?” 3.9 不要把操作变成类. “我需要一个做...事情的类”,如果有这种想法,请先认真斟酌.这个类真的代表了某个关键抽象概念吗? 名字是动词…

面向过程的软件开发通过非常集中化的控制机制来分解功能,在程序设计中表现就是大量的条件判断,深层次的循环嵌套等. 这种模式下,我们可以通过分析方法的参数,局部变量及其访问的全局变量来得到方法对数据的依赖性,但是我们只有分析整个项目代码才能得到数据对方法的依赖性. 面向对象的软件开发主要关注在非常分布的环境中分解数据以及同数据相关的功能.通过高内聚(数据与其相关行为的高度融合)和低耦合(实体之间的相互隔离)来 实现功能的分布,典型表现就是不需要过多的条件判断以及深层次的循环嵌套等. 这里我们可以通过…

一,继承只应被用来为特化层次结构建模 实际上也就是要满足LSP原则,水果类<-榴莲的继承是特化   二,派生类必须知道他们的基类,基类不应当知道他们的派生类   复用的前提   三,基类中的所有数据都应该是私有的,不要使用保护数据(方法不在此原则约束下)    数据封装,物体的重量看起来可以用一个保护数据来表达,而不是get/set方法,但是考虑其他星球上,那么重量的应该实现为质量*加速度的时候呢?   四,理论上,继承层次越深越好    继承越深,意味着复用的功能越多   五,如果没有合适的可…