L lncd Unregistered / Unconfirmed GUEST, unregistred user! 2003-10-13 #1 房间类:class room 桌子类:class desk 房间里要放若干张桌子,但桌子数目不定。 房间和桌子都有一些各自的属性和方法。 象这样的问题如何表示?
A aoyou Unregistered / Unconfirmed GUEST, unregistred user! 2003-10-16 #6 这样就可以送分了,太好了![]!是不是零分以下就不可以进入论坛了
O oldsheep35 Unregistered / Unconfirmed GUEST, unregistred user! 2003-10-16 #7 楼主把题目给删了! 节约是种美德,但现在连上海的中小学都不提倡了 楼主就浪费吧!
W weiwei81123 Unregistered / Unconfirmed GUEST, unregistred user! 2004-01-07 #8 加一个类 桌子列表: class desklist 房间类中有一个成员是桌子列表类型 不就是这样?
L lncd Unregistered / Unconfirmed GUEST, unregistred user! 2004-01-07 #9 weiwei81123, 用语言如何表达class desklist?
W weiwei81123 Unregistered / Unconfirmed GUEST, unregistred user! 2004-01-07 #10 参考一下TCollection,或者用TList也行
N nanyehy Unregistered / Unconfirmed GUEST, unregistred user! 2004-01-07 #12 在Class Room里加一个TList类型的字段,用于存储Class Desk,想放多少个Desk都可以!
Z zyyzj Unregistered / Unconfirmed GUEST, unregistred user! 2004-01-07 #13 TRoom = class FDesks: array of TObject/TDesk; end; TDesks = class ... end; 这是很普遍的容器结构。 根据应用的不同有许多种变化,像上面array of TObject和array Of TDesk会导致很微妙的变化。 或直接定义的TDesks的容器类,变成下面这样: TRoom = class FDesk: TDeskCollection; ... end; TDeskCollection = class ... end; TDesk = class ... end; 此类结构,接近于在设计模式中的[复合模式]。 只是接近,不要硬套。像上面的代码,也可以发展为[代理模式]。
TRoom = class FDesks: array of TObject/TDesk; end; TDesks = class ... end; 这是很普遍的容器结构。 根据应用的不同有许多种变化,像上面array of TObject和array Of TDesk会导致很微妙的变化。 或直接定义的TDesks的容器类,变成下面这样: TRoom = class FDesk: TDeskCollection; ... end; TDeskCollection = class ... end; TDesk = class ... end; 此类结构,接近于在设计模式中的[复合模式]。 只是接近,不要硬套。像上面的代码,也可以发展为[代理模式]。
小 小雨哥 Unregistered / Unconfirmed GUEST, unregistred user! 2004-01-07 #14 TO xzh2000: 大富翁里的版主会删这样的帖子吗?不会吧。哈哈,这么一个 OO 贴也删的话,大富翁就没 了啊。 桌子和房间应该出自不同的基类,2 个类间的关系可以很复杂,也可以很简单。但一般不会 出现桌子里有房间的情况。简单地看,在房间类的创建里,摆上几张桌子实例就可以了。
TO xzh2000: 大富翁里的版主会删这样的帖子吗?不会吧。哈哈,这么一个 OO 贴也删的话,大富翁就没 了啊。 桌子和房间应该出自不同的基类,2 个类间的关系可以很复杂,也可以很简单。但一般不会 出现桌子里有房间的情况。简单地看,在房间类的创建里,摆上几张桌子实例就可以了。
L lncd Unregistered / Unconfirmed GUEST, unregistred user! 2004-01-07 #15 房间里的桌子是不定的。所以恐怕还得有个桌子的器类。 看来得用以下3个类描述 TDesk = class //桌子类 ... TDeskList = class(TList) //桌子容器类 ... TRoom = class //房间类 FDeskList:TDeskList; ...
房间里的桌子是不定的。所以恐怕还得有个桌子的器类。 看来得用以下3个类描述 TDesk = class //桌子类 ... TDeskList = class(TList) //桌子容器类 ... TRoom = class //房间类 FDeskList:TDeskList; ...
C creation-zy Unregistered / Unconfirmed GUEST, unregistred user! 2004-01-07 #16 to 楼主: 您的这个问题有很多现成的例子,VCL中的窗体(TForm)以及窗体上的控件(TComponent)的 关系即是如此—— 1..n 关系。好好的学一学 VCL 的源代码吧。
A archonwang Unregistered / Unconfirmed GUEST, unregistred user! 2004-01-07 #17 ? 模式问题? 如果单单考虑只是一间房子可以这么讲的:虽然是同类派生出来的咚咚,不过属性却完全不通的说,关键看楼主你怎么考虑它们的事件和属性。 zyyzj说得挺地道的:容器结构。 大概程序都是比较单纯的,^_^
? 模式问题? 如果单单考虑只是一间房子可以这么讲的:虽然是同类派生出来的咚咚,不过属性却完全不通的说,关键看楼主你怎么考虑它们的事件和属性。 zyyzj说得挺地道的:容器结构。 大概程序都是比较单纯的,^_^
小 小雨哥 Unregistered / Unconfirmed GUEST, unregistred user! 2004-01-07 #18 说是模式问题当然可以,因为总可以用模式来描述。 怎么起类、起几个类,也可以自己看着办。比如你认为需要一个桌子列表类做为容器,而 我觉得可以用容器也可以不用容器。我认为你的房间没有进化到仓库,就不需要遍历,而 完成一个房间,使用桌子列表还不如使用物品清单,更绝对的,我的房间类和我的桌子类 关系很特殊的话,我那个桌子类本身可能就是继承自物品清单类。有什么不可以的?
说是模式问题当然可以,因为总可以用模式来描述。 怎么起类、起几个类,也可以自己看着办。比如你认为需要一个桌子列表类做为容器,而 我觉得可以用容器也可以不用容器。我认为你的房间没有进化到仓库,就不需要遍历,而 完成一个房间,使用桌子列表还不如使用物品清单,更绝对的,我的房间类和我的桌子类 关系很特殊的话,我那个桌子类本身可能就是继承自物品清单类。有什么不可以的?
桦 桦树皮 Unregistered / Unconfirmed GUEST, unregistred user! 2004-01-07 #20 这个结构很适合于酒店的前厅管理模式,呵。 如果把整个这样的系统设计成一个类,可操作性就好多了