关于类设计的问题

问题描述：  
  　　比如一个内部图书管理系统，有用户管理功能，可以增加、修改、删除用户。每个用户可以属于或者不属于一个部门，部门信息也是可以增加、修改、删除的。  
  　　在分析设计类时我有两种想法，请教大侠哪一种好点，或是有更好的办法请赐教。  
  方法一：设计一个用户类，一个部门类，其中增加、修改、删除都作为类的方法。  
  方法二：设计为一个用户信息类，部门信息类，再加上两个管理类分别对用户及部门信息类进行操作，比如有个用户管理类，该类有增加、修改、删除用户信息类的方法。  
   
  请比较两种方法的得失! 问题点数：80、回复次数：9Top

1 楼hurricane（随意春芳歇）回复于 2003-08-04 23:16:19 得分 10

个人认为用第一种就可以了  
  本身你这个系统比较简单  
  在用户类里面封装用户的数据和操作  
  在部门类里面封装部门的数据和操作  
  简洁明了  
  另外设计一个管理类反而使得逻辑变得复杂化Top

2 楼13060939425（显示器）回复于 2003-08-05 11:49:31 得分 10

一种情况,就是部分类的数据成员多得很;但是自己编写的方法反而很少,写在一些阅读不方便  
   
  二种情况,是有很多个不同的部门,描述不同的部门的类,在同小异.   如果用第一种方法,会写出很多个类来,用第二种方法,只要两个类就够了Top

3 楼zhaoxichao（小西）回复于 2003-08-05 12:01:06 得分 10

应该使用方法2：这样的设计肯定更容易扩展，而且更复合面向对象的方法  
  信息类相对于一个实体类，管理类为操作类  
  可以为部门信息类和用户信息类作为一个基础类，可以泛化成普通用户、高级用户，部门也可以有不同的类型  
  而对应不同类型的信息类，相应操作类也可以有不同的操作Top

4 楼einsteincao（至尊宝！pig难过恐龙关）回复于 2003-08-05 12:10:24 得分 10

使用第二种办法：  
    应为如果使用第一种方法，就可能产生类内部的操作（比如用户类中对用户本身信息的增删改），这样导致用户信息仅仅变为了一种属性。    
  当然这样做也可以达到目的，只不过会增加耦合性。      
  如果使用第二中方法，注意信息类中的操作尽量避免河操作类中的重复  
   
  条条大路通罗马...Top

5 楼dujinghong（红风）回复于 2003-08-05 13:04:47 得分 10

应该使用方法2。  
  Top

6 楼spanzhang（红尘斩丝客）回复于 2003-08-05 14:47:21 得分 10

个人意见：  
  将用户类与部门类从同一个超类继承下来，这个超类里面有增加，删除、修改等接口，并且它还有一个Owner属性（recursive）。Top

7 楼13060939425（显示器）回复于 2003-08-14 11:33:46 得分 10

如果信息类和操作类分开,是不是意味着信息类成为一个静态类呢?  
   
  是不是要在操作类里面实例一个信息类的对象,   然后在操作类里面对此信息类进行增删改?  
  这样是不是方便啊?好象不方便呢Top

8 楼jeffyan77（jeffyan77）回复于 2003-08-14 11:40:49 得分 10

一般情况下，数据与行为不能分开，这是OO设计的核心。不然的话，就又回到过程性编程了。  
   
  这叫DIM(Do   It   Myself)对象的行为属于自己。Top

相关问题

• 用户
• 修改
• 信息
• 管理
• 数据
• 类
• 操作
• 部门
• 设计
• 方法

• 帖主：kmhertz
• hurricane
• 13060939425
• zhaoxichao
• einsteincao
• dujinghong
• spanzhang
• 13060939425
• jeffyan77

• CSDN Blog
• 技术文档
• 代码下载
• 第二书店
• 读书频道