类的属性和方法要分成两个类还是用一类来存放？

[mobbs]

如Person类。
有属性psnID,psnName,psnSex。
有方法addNew();getOnePerson()
两种方案：
1.放在一起。
Person类。
属性:psnID,psnName,psnSex。
方法:addNew(thePsn:Person):void;getOnePerson(psnID:int):Person
2.存成两个类
Person类
属性:psnID,psnName,psnSex。
没有方法（构建器除外）
PersonManager类
属性：psnID
方法:addNew(thePsn:Person):void;getOnePerson(psnID:int):Person

[mobbs]

同样的事
方案一：
Person aPsn = new Person();
aPsn.PsnName = "abc";
Person.AddNew(aPsn);
方案二：
Person aPsn = new Person();
aPsn.PsnName = "abc";
PersonManager aPsnManager = new PersonManager();
aPsnManager.AddNew(aPsn);
===============
有人喜欢1，有人喜欢2。大家说呢。

[freezingfire]

应当分开。对单个对象本身的操作与对对象集合的操作，应当分开。

[mobbs]

写错，是

同样的事
方案一：
Person aPsn = new Person();
aPsn.PsnName = "abc";
aPsn.AddNew(aPsn);//自己加自己，看起来怪怪的。
方案二：
Person aPsn = new Person();
aPsn.PsnName = "abc";
PersonManager aPsnManager = new PersonManager();
aPsnManager.AddNew(aPsn);//看起来更合理些。
===============
有人喜欢1，有人喜欢2。大家说呢。

[AiWangji]

无论是属性还是方法，都是类的特性，而所谓类的特性就是它
与生俱来的本质的性质或行为。一个类同时具有属性和方法并
不是问题，问题是这些属性和方法是不是它应该有的特性。

象例子中的addNew，getOnePerson显然是对Person的操作（管理），
并不是Person本身的特性，而是管理Person的类的特性。
因此当然把这些方法放到管理Person的类中描述比较合适。
（mobbs(陆家之马)在方案2中用将这些方法放在PersonManager类
中，这当然不错。但是我认为更好的方法是，我们首先要观察（分析）
问题域中对Person的管理是怎么一种模型，如果正好和某种容器模型
象吻合的话，在PersonManager中直接放一个相应的容器不就行了嘛，
这样既省力又便于维护。）

[mobbs]

AiWangji(爱忘记) :
"在PersonManager中直接放一个相应的容器",你的意思是说，在PersonManager中加一个属性thePerson:Person。类似这样的？好像不是这意思吧。
赐教，赐教。

[AiWangji]

我讲的不是指单个的Person，而是指装Person的容器。
比如Dictionary，Vector，Set，Array等容器。即在
PersonManager中加一个容器属性,如
personList: Set or Dictionary or Vector of Person
到底取哪一个容器用，要根据问题域来定。比如可重名的话，我们用
Set；不可重名的话，我们用Dictionary；可排序的话，可以考虑用
Vector。

然后我们就可以用 thePerson.GetPersonList().AddElement(aPsn);
thePerson.GetPersonList().GetElement();等等来管理Person了。
如果是一个纯面向对象的系统，所有的容器都是从一个元容器类继承
过来的话，那就更好了，因为这样当问题域发生变化时，我们只要换个
容器类型就可以了，而不需要再改其他地方的设计了。

当然如果这些管理要开放给其他类的话，我们还应该考虑是否要包装。
但是，现在有一种理论当我们的设计的耦合度很低时，包装变得不
重要了。这是因为类之间的相互作用在设计时已经被控制得很好了，
不需要过分依赖包装这一实现手段来控制类之间的相互作用。

[mobbs]

哦，用容器，感觉还不如用类来的直观些：）
就说thePerson.GetPersonList().AddElement(aPsn);
跟在PersonManager类中new 一个Person类，没有什么大的区别呀。
用容器,还是要用两个类（Person和PersonManager）的。

[drama]

一些看法：
现在的person中，可以完成update（），包括了add,和update两个功能，具体区别由isNew来区别，自动完成。而你说的GetOnePerson,我觉得还是应该属于person的。通过某些条件填充自己的属性。这些都是person自身的属性和方法了。
当然对于有类似collection的，就是属于1对多的问题了。需要容器来管理了

[AiWangji]

问题不在于用了几个类，而在于设计的可再用性，可扩充性
以及耦合度等问题。用容器的考虑是：第一是再用性，是现成的
不需要自己再做，第二是扩充性，万一问题域发生了变化，只
要换一个容器类型就可以了。从耦合度来讲，将管理和管理的具体
方法分开考虑这会大大降低类之间的耦合度，即对Person的管理方法
发生了变化，比如从可重名到不可重名等等时，只要改变管理方法
（重选容器）就可以了，而管理本身不需要做任何改变。

[AiWangji]

问题不在于用了几个类，而在于设计的可再用性，可扩充性
以及耦合度等问题。用容器的考虑是：第一是再用性，是现成的
不需要自己再做，第二是扩充性，万一问题域发生了变化，只
要换一个容器类型就可以了。从耦合度来讲，将管理和管理的具体
方法分开考虑这会大大降低类之间的耦合度，即对Person的管理方法
发生了变化，比如从可重名到不可重名等等时，只要改变管理方法
（重选容器）就可以了，而管理本身不需要做任何改变。

[mobbs]

drama() :
我写的addNew()只是随手写的，表示一个特定的方法而已，没有特指什么意思。

好象讨论有点离题了，其实我想问的是，举个例子吧。
好像，最简单的朋友录系统。这个系统只要做一件：增加新的朋友（甚至不用提供列表显示，修改，删除等功能）。而朋友只用记录他的姓名，性别就可以了。
所以，我们应该设计几个类呢？
一个Person类，还是一个Person类和一个PersonManager类？

[mach]

从你的例子看应该有如下类
朋友录：FriendList，有如下方法addFriend,find，removeFriend...
朋友：Friend,有如下属性name,gender...可能有别的什么方法比如eat,sleep...:)
上述两个类是1对多的关系，一个朋友录可以容纳多个朋友的信息

Person类和一个PersonManager类听起来不如Friend和FriendList
不过怎么也不应该是一个类，那样也太不oo了。。。

[mobbs]

mach(照虎画猫) ：
我明白你的意思了。
你的意思是说：类似于eat,sleep这种由person驱动的方法就放在person类中。而对person操作的方法，如addPerson()，就放到PersonList类中。

[mach]

是的，其实oo很简单，很自然，比如你有一帮朋友，和一个通讯录，在现实中，你肯定不会在认识一个新朋友的时候就在他的脸上或者衣服上记录他的名字、性别电话等的吧，肯定是把这些记录到通讯录里，同样的这样的道理可以直接影射到oo模型里。