怪怪 | Nothing, Everything

#1楼    回复  引用  查看    

我觉得这个本质上还是如何处理null引用的问题.
NullObject模式在有些时候有用,但是不太容易理解,尤其是对不同类型采取不同的null策略时,而有时候有些类型是不太方便使用NullObject模式的.所以我觉得还是得根据各种条件具体分析,整个完整的世界是没法规范化的.

不谈虚的,如果相册系统提供了分类重命名功能的话,就有点麻烦了(如果提供删除分类功能的话...);而如果提供了高级查询界面的话,"属于分类'没有分类'","不属于分类'没有分类'"估计会让用户比较郁闷.

#2楼 [楼主]   回复  引用  查看    

相对于这个问题的根本认识， 隐藏“没有分类”这一特殊分类， 让它看起来就像真的没有分类， 其实是容易的...， 关键是例子， 只要有一个不好解决的例子， 就能一下子清楚很多。

NullObject的关键在于行为， 所以比这个问题牵连多广...

#3楼    回复  引用  查看    

我一般列出所有use case，再决定怎样设计
文章列举的情况比较简单，获得的好处只是在查询时，查找没有Category的Picture变得方便了，但是基于Category或Picture的修改，涉及到关联关系的所有use case都变得复杂了，例如deerchao讲到的情况，删除一个Cagegory时，除了删除Category、Category与Picture的关系之外，还得判断那些Picture是否有属于其它分类，没有的话得添加一个与默认分类的关联关系
在这种情形下我是不会这样来设计的，因为追求统一带来的使用效果 < 维护统一付出的代价

结合业务设计来考虑：
其实类似的问题关键是"如何设计Category"，而与其他方面无关，从这个点出发，最终那些"默认分类"都是最终用户可见、可理解，并且能给他们带来方便的概念，而不仅仅是隐藏在系统内部，需要特殊处理而最终用户并不知道的东西
例如cnblogs的上传图片对话框体现出来的，每个用户都有一个自己的图片册根目录，不选择子目录时图片将被上传到这个根目录下，系统不会允许某个图片不属于任何目录的情况出现，用户也知道这个概念
再看其它一些blog，一方面有一个相册可以独立维护，图片可以上传到相册的不同目录中，编辑随笔时可以从相册中选择图片插入到文章中；在编辑blog文章时也可以直接上传插入图片，但与cnblogs的图片管理方式不一样，随笔中上传图片与在相册中上传图片不是整合在一起的(也可以说cnblogs缺少一个可以独立维护的图片册功能)，例如早先的新浪博客。这样看来这些图片就变成游离于相册之外了，我们可以设计一个"随笔中的图片"这样一个系统目录，下面再按照每篇随笔进行分组，这样"随笔中的图片"这个目录也就变成了用户可见的概念而与相册结合起来，而不仅仅是系统内部隐藏的一个设计实现方式
这种思路关键的区别是与业务结合起来，例如前面提到的删除目录之后还得为图片添加默认Category，在这种思路下面就变为：删除目录时相应的图片也被删除，但可以设计辅助功能，例如让用户在目录之间转移图片，甚至删除目录之前让用户决定是否将图片转移到新的目录。这样那个添加"默认目录"的动作也变成了一个用户可见的业务操作步骤了

尽量把这些隐藏概念设计为最终用户可见的概念，在实现时一般都不需要特殊处理了，因为它已经真正的统一起来了，而不是为了统一而做作的。可能伴随着要提供另外一些辅助功能而带来一些工作量，但这已经是以用户为中心的业务设计理念导向，而不是局限在技术上的(这种更像是做绣花枕头华而不实)

#4楼    回复  引用    

我的想法是， 是否可以把设立默认分类当成一个最佳实践，无论建立什么系统时， 只要在实质上是一个分类的问题， 都可以采取这种实现； 因为这个问题普通到不再受其他条件的影响。 问题在于有没有不适合的反例，比如有默认分类在某种情况下更糟糕， 我想问的就是这个。
================
我觉得业务需求的考量很重要。为图片提供一个默认的CategoryID或者“未分类”什么的没问题，因为这个CategoryID本身含的业务含义有限。假设该CategoryID代表的是您订制的某项个人服务，该ID也决定了每月从您的帐户上划走的人民币，这时候对CategoryID采用默认值就需要小心了，如果业务流程上再没有进一步校正控制的话，银子划多了我想您应该不会坐视不理吧？

#5楼 [楼主]   回复  引用  查看    

@ABCD
你说的这个也有道理， 不过按照RicCC说的那种形式， 每个分类也是明码标价的。 有默认分类并进一步校正和没有默认分类时要进行的处理， 在这种情况下会在复杂性上有很大区别吗？

#6楼    回复  引用    

在很多时候采用哪种方式实现，技术上的复杂性并不是取舍的唯一原因。况且设计本身就是可繁可简，定义的边界就在于业务需求。
看得见摸得着的具体功能需求是一个方面，这就是RicCC所讲的。另外一些因素是很隐蔽的，那就是需要去探究和评估数据本身所含的业务意义。有些数据（比如某些主键）对设计很重要，但对客户而言经济意义不大。这样的数据随你采用默认也好、“不分类”也罢都没关系的，即使出错了客户也不会计较的。但有一些数据对设计者而言它不重要性，但它背后却隐藏的客户最关心的经济利益问题，在操作这类数据时对业务的精度要求一般都会非常高，这时候我们就更倾向于较为严格周密的设计，如果因此而带来的维护上的代价也是必须要承受的。

#7楼 [楼主]   回复  引用  查看    

你说的很有道理， 正是抱着这个初衷， 我才希望看看这个问题， 是不是有“反例”。 我上个回复缺了几个字， 就是说即使采用默认分类的形式， “每个分类也是可以有明码标价的”， 更多的， 对于“默认分类”， 其标价可能是0， 也可能是没有分类的情况下那个价格。

那么如你描述的这样一个业务， 是不是一个反例， 或者更具体的说， 采用“默认分类”的话， 从根本上来说不是不能实现这个业务， 那么判断的依据就应该是， 采用“默认分类”的做法， 在这种业务需求下， 是不是造成更大的麻烦， 以至于抵消了它的优势。

实际上我问过4～5个比较有经验的程序员， 有的直接很有信心的反问我， “你说有什么问题？” 有的想过这个问题以后， 倾向于“默认分类”没有问题。 只是我还是不放心， 所以就发出来讨论一下。

我个人也想象不出， 采用“默认分类”的做法， 第一是它在什么情况下会“出错”， 第二，它和精度或者其它可能存在的其它问题有什么关联。 我的疑虑只是不能严格的证明它在所有的情况下都是可疑采取的一个方案， 就像0重新规划为自然数不会造成问题那样。

业务、 需求， 当然在任何时候都是第一位的， 只是这样一个小技巧（而且就是具体到“默认分类”这一个技巧，而不是说倡导或贯彻偷懒的做事方法）， 是不是真的会对它们造成影响呢？ 如果有影响的话， 是什么样的影响？ 我想讨论的其实就是这个~