系统的类该怎么设计

cyuemei 2010-09-04 07:32:55

用asp.net做一个稿件管理系统，由于设计多个角色，包括作者、编辑、副编、主编、专家、管理员等，但各个角色又有不同的属性。
比如作者的角色属性比较多；
编辑部（编辑、副编、主编）属性为姓名、账号、密码、电话、邮箱、地址、栏目分类等；
专家属性为姓名、账号、密码、电话、邮箱、地址、领域分类等；
管理员为姓名、账号、密码；
类该怎么设计？一个角色一个类吗？登录、注册的方法应放在哪个类当中？
对系统类的理解有些模糊？请高手指教。

...全文

96 7 打赏收藏转发到动态举报

写回复

用AI写文章

7 条回复

切换为时间正序

请发表友善的回复…

发表回复

yuxh81 2010-09-05

打赏
举报

这个还真没遇到过

关注

自然框架 2010-09-05

打赏
举报

看你的思路，你是已经乱成一锅粥了。

要明确的区分开来。

作者、编辑、副编、主编、专家 —— 这些是职位或者是职称，总之这个和角色基本没什么关系。

姓名、 —— 这个是每个人都有的信息，是“人”这个基类拥有的属性

账号、密码、 —— 这个是有了软件之后才有的属性，项目相关或者是系统相关。

电话、邮箱、地址、 —— 这个个人的联系方式。

栏目分类 —— 这个又是什么？

你把这些关系不大的信息，都当成了角色的属性，其实你写的这些没有一个是角色的属性。

专家属性为姓名、账号、密码、电话、邮箱、地址、领域分类等；
管理员为姓名、账号、密码；

你的思维混乱了吧。

其实很简单，先设计一个“人”的基类，然后设置“登录账号”的类。

然后是几个分支，“专家”是一个类，放专家自己的信息，比如你说的领域。

还有一个“联系方式”的类。

说了半天，也没说到角色，其实角色自己是很简单的，就是一个角色名称和角色说明两个属性。

然后就要看自己的想法了，每个人的想法不一样，所以角色的其他属性，或者是关联，那就都不一样了。

基本上来说，是要记录角色可以做什么，只是每个人的实现方式都不大一样。

以专业开发人员为伍 2010-09-05

打赏
举报

基本上，所有初学者只能说清楚软件的静态模型，似乎只要有静态模型、弄了数据库表生成工具，就能写好程序了。于是你就会看到一大堆千篇一律、互相抄袭的OA式的“软件”。反倒是一些业余开发者，更加注重软件的动态模型设计，可以将动态模型装载心中，所以可以开发出真正的软件。可惜，如果这些人被初即程序员“熏陶”一段时间之后，也慢慢就变成没有创意的了。

所以一个好的设计师，应该多多注重那些有意义的动态、千变万化的东西，少纠结于数据库表的所谓“设计”方面。

以专业开发人员为伍 2010-09-05

打赏
举报

关键是不要只盯着固定的静态概念，而应该看“关系”。而最基本的关系只需要有两种：关联、继承。

比如按照你的描述，每一个作者都有一个或者多个身份，于是作者和各种角色个体之间是继承关系。比如作者有“姓名、帐号、密码”的属性（实际上，通常要设置一个ID属性来在整个数据库中唯一区分一个对象），那么管理员从作者继承，但是什么新的扩展属性也没有；编辑部人员则扩展了5个新的属性，其中第一个属性是“编辑、副编、主编”的区分标志；专家则扩展了另外4个属性。

顺便说一下，对应在关系数据库设计中，可以将父类作为一个表，然后子类的扩展属性作为另一个表，并且使用外键保持与主类中对应记录的级联（级联删除和级联更新）关系。

登录、注册是什么意思呢？这要看你写什么软件。如果是做界面，那么通常将登录、注册作为一个独立组件（控件），例如winform中的form或者usercontrol，都是可能的，这些独立的组件当然要比数据模型更有用，因为它们就是软件的目的所在。

而如果是做后台数据服务中的登录、注册功能，也是作为独立的服务功能而单独设计，例如你可以此时专心地以一个单独的类来实现一个服务功能，或者是一个独立的static方法（也就是说如果你觉得放在多个模型类中似乎都靠谱，那么不如全都不放，而是放在单独的BusinessLayout类中，这个类是声明为static的类）。

当考虑分层操作时，并不是做一个层内部处理的小程序，所以并不是纯粹的面向对象，而是要更多地以面向功能方法去调用其它层的接口功能。