/*************************************
*面向对象设计续,11-20
*************************************/
(11)确保你为之建模的抽象概念是类,而不只是对象扮演的角色。p23 
  
//
//什么叫"对象扮演的角色"?
//(12)在水平方向上尽可能统一地分布系统功能,也即:按照设计,顶层类应当统一地共享工作。p30 
  
//
//什么叫"统一地共享工作"?
//
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。p30 
规划一个接口而不是实现一个接口。 //
//可以理解
//
  
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。p30 
  
//
//数据和行为怎么样才算集中存放?
//(15)对包含太多互不沟通的行为的类多加小心。p31 
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。 
  
//
//是否可以理解为get 和set 互不沟通?
//(16)在由同用户界面交互的面向对象模型构成的应用程序中,模型不应该依赖于界面,界面则应当依赖于模型。p33 
  
//
//不是很明白,什么样的依赖?
//(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。p36 
  
//
//
//(18)从你的设计中去除不需要的类。p38 
一般来说,我们会把这个类降级成一个属性。 
//
//不需要了,干嘛还要降级为属性?
//
  
(19)去除系统外的类。p39 
系统外的类的特点是,抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。  
//
//什么叫系统外的类?
//可以举例说明?
//
  
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类,特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。p40 //
//是否理解为,这个类不能只是一个具体的操作?
//比如:插入商品,不能把这个操作作为一个类,
//而是把商品作为一个类,插入这个操作,只相当于
//商品类里的一个方法 ?
//

解决方案 »

  1.   

    (11)... ...(12)“统一”的“分布”...
         Control Object???(13)类的职责尽可能的单一(14)...两种情况:
        1. 大量调用其他类型的外部接口(如果很少牵涉到自己的数据那更糟),说明该接口可能不属于这个类型。
        2. 通过重构分解了大型方法(支持)(15)what's meannnnnnnnnnnnn~~(16)依赖倒转原则,实现依赖与抽象,抽象不应该依赖于实现
        模型层负责系统的核心业务逻辑处理,其是整个系统的核心与抽象;
        界面是将模型层加工处理的业务逻辑提供显示的场所,是一种显示实现;
        实现应该依赖于抽象,所以界面层应该依赖于模型层。(17)伟大的话总是自相矛盾的(18)“不需要”意指当一个概念不必通过复杂的对象来表示概念,只需要一个简单数据就可以说明问题。(19)一个AMS系统,对某公司的资产进行管理,其间项目组或部门可能需要向总务部门领用一些资产以投入工作,当进行领用登记时,必须知道该部门或项目的信息。而这些信息不由AMS系统维护,他们被维护在总务部门的一个旧有系统之上,换言之公司部门或项目信息并不属于AMS系统,他们仅仅是因为某些应用而保存的记录而已,本身除了一些自描述的数据也无其他交互。(20)异议!!!@.@||~