日期:2014-05-16  浏览次数:20858 次

软件架构设计模式的建议~
     现在有这样一个档案管理的需求,主要涉及四个对象分别为 用户、项目、评论、附件,其中项目、评论、附件都是通过用户对象来创建删除修改的,(项目、评论、附件这三个对象的后台数据库里都有相关的用户ID)。评论和附件都是与项目相关(即针对某个项目的评论、与某个项目相关的附件),项目分为不同专业(建筑、施工、设计等)。那么在设计类或接口的时候,应该怎么设计比较好?
    我的思路是设计用户类、项目基类(各个专业再继承项目基类)、评论类与附件类,但是之间的操作还有交叉,比如有时要判断一个用户是否是某个项目的上传人、删除某个评论里必须是该评论对应项目的创建用户等,挺烦琐的。怎么样设计程序能简洁一些呢?
------解决方案--------------------
没把握本质,被博客园给忽悠了

我的思路是设计用户类、项目基类(各个专业再继承项目基类)、评论类与附件类
评:整体没有问题,不过“各个专业再继承项目基类”完全没必要,不是说你建筑、施工、设计滴档案就应该有不同滴属性,逻辑上不管是什么专业他都是档案。另外档案本身就应该包括附件

---------------------------------------------------------------------------
--------------------------------------------------------------------------

但是之间的操作还有交叉,比如有时要判断一个用户是否是某个项目的上传人、删除某个评论里必须是该评论对应项目的创建用户等,挺烦琐的

这个考虑就比较无厘头了,方法判定是实现细节,这个和设计没啥关系。删除是抽象逻辑,怎么删除是实现细节。


总结:别把你自己当程序员,你应该把自己当档案馆和档案管理员。对于你来说就只有“档案本身”“档案归档索引类别”“档案入库及借阅规定”这几个基本要素
------解决方案--------------------
引用:
     现在有这样一个档案管理的需求,主要涉及四个对象分别为 用户、项目、评论、附件,其中项目、评论、附件都是通过用户对象来创建删除修改的,(项目、评论、附件这三个对象的后台数据库里都有相关的用户ID)。评论和附件都是与项目相关(即针对某个项目的评论、与某个项目相关的附件),项目分为不同专业(建筑、施工、设计等)。那么在设计类或接口的时候,应该怎么设计比较好?
    我的思路是设计用户类、项目基类(各个专业再继承项目基类)、评论类与附件类,但是之间的操作还有交叉,比如有时要判断一个用户是否是某个项目的上传人、删除某个评论里必须是该评论对应项目的创建用户等,挺烦琐的。怎么样设计程序能简洁一些呢?


你可以买一本 UML 的比较权威的书籍,或者20年前OMT技术的书籍,这些书对于OOA建模(而不是OOD)的过程比较细致和实用。