思考一个有关问题：某个布尔值在系统中应该显式定义还是应该隐式推导
思考一个问题：某个布尔值在系统中应该显式定义还是应该隐式推导？
比如说，人和兽都是动物，业务规则是：直立者即人，爬行者为兽。
那么 在“动物”表中， 除了要有 “行走方式” 这个字段，要不要再搞一个 “是人是兽” 字段？
隐方：不必了。通过站立方式已经可以推导出是人是兽了，再搞一个字段就是冗余了，众所周知，冗余有很多坏处。
显方：我觉得应该搞一个“是人是兽”的字段。先不说冗余的问题，先说搞一个这样的字段有哪些好处。
1. 最重要的一点，是可以帮助业务逻辑之间解耦，降低系统复杂度。 比如说，系统里判断一个动物能否说话时，先要判断这个动物是人还是兽，而要判断动物是人还是兽，要先判断它的行走方式是否为直立。 这样的话，“能否说话” 就依赖了 “是否直立行走”，如果这种依赖关系多了，这些关系就会在系统中形成一个网状结构，很复杂。而如果我们显式地搞一个 “是人是兽” 的 Mediator，网状结构就可以退化成星形结构，这样可以增强系统的可维护性。
2. 业务逻辑之间解耦后，还可以减少公司里业务专家的压力。很多程序员，尤其是新来的五谷不分的程序员，并不知道直立的就是人，趴着的就是兽。要了解这一点，他们就得去问业务专家，即老工程师或者产品经理，这个代价可大可小。他也可以去查文档，但按我们的现状，文档未必完整，而且篇幅巨大，查起来也非常费劲。
隐方：对你的第二点我很赞同，但关于第一点，我觉得还是设计技巧的问题。你在业务层写一个接口用于判断“是人是兽”，不就可以了吗？而且这样还可以封装判断的细节，当判断规则改变时，接口的调用者可以不必改写代码。
显方：这么看来至少你赞成搞一个“显式”的接口了，只不过是放在业务层；这样既可以实现业务逻辑的解耦，又可以避免数据库中的冗余。
隐方：是啊，很完美吧？
显方：但你的想法需要一个大家定一个规矩：即所有人都必须通过个接口来进行人兽判断。这在代码不多、并且软件复用思想深入人心的小型团队里倒是很适用，因为这个规矩很容易执行；但在大型团队里，这个规矩很难执行；因为很多人对业务层的重用并没有什么概念，他们会直接绕道去找数据库；而且即使他们愿意重用业务接口，在项目紧张时也懒得去找相应的接口规格，因为他们根本不知道这个接口是否存在，也不知道应该去找谁问这个问题。
隐方：这是另外一个问题了，主要跟软件过程有关系，或者可以借鉴SOA实践中的一些思想，我们另开一个话题再聊吧。
把所的有程序员都开除
让teamleader + 项目经理组成一个team
同样的时间可以干同样多的活.
顺手还能提高一下项目经理的工资.
跟打仗一个道理。战术思想都不统一，不过是一群乌合之众。
一个好的将领，统兵上万必也是进退有序，若放任你手下的士兵按自己意志行动，其必败。
你要是把人动物都放在一个表中那才叫雷人
同意，感觉更应该用字段表示人兽，用方法表示业务规则。应该用符合思维习惯的方式构建系统。
我想你和很多人一样被楼主带沟里了。OO的角度看问题，用标志位干啥。
按照这个话题，比较适当的方法是人、兽作为抽象类动物的两个实现类，而不是一个标志位。两个类分别实现自己的.运动()方法。实例创建采用工厂接受一个表示类型的参数。
多究一点，运动方法可以用策略模式，动物类的对应属性应该是个集合，表现可以有多个运动方式。
比如说，人和兽都是动物，业务规则是：直立者即人，爬行者为兽。
那么 在“动物”表中， 除了要有 “行走方式” 这个字段，要不要再搞一个 “是人是兽” 字段？
隐方：不必了。通过站立方式已经可以推导出是人是兽了，再搞一个字段就是冗余了，众所周知，冗余有很多坏处。
显方：我觉得应该搞一个“是人是兽”的字段。先不说冗余的问题，先说搞一个这样的字段有哪些好处。
1. 最重要的一点，是可以帮助业务逻辑之间解耦，降低系统复杂度。 比如说，系统里判断一个动物能否说话时，先要判断这个动物是人还是兽，而要判断动物是人还是兽，要先判断它的行走方式是否为直立。 这样的话，“能否说话” 就依赖了 “是否直立行走”，如果这种依赖关系多了，这些关系就会在系统中形成一个网状结构，很复杂。而如果我们显式地搞一个 “是人是兽” 的 Mediator，网状结构就可以退化成星形结构，这样可以增强系统的可维护性。
2. 业务逻辑之间解耦后，还可以减少公司里业务专家的压力。很多程序员，尤其是新来的五谷不分的程序员，并不知道直立的就是人，趴着的就是兽。要了解这一点，他们就得去问业务专家，即老工程师或者产品经理，这个代价可大可小。他也可以去查文档，但按我们的现状，文档未必完整，而且篇幅巨大，查起来也非常费劲。
隐方：对你的第二点我很赞同，但关于第一点，我觉得还是设计技巧的问题。你在业务层写一个接口用于判断“是人是兽”，不就可以了吗？而且这样还可以封装判断的细节，当判断规则改变时，接口的调用者可以不必改写代码。
显方：这么看来至少你赞成搞一个“显式”的接口了，只不过是放在业务层；这样既可以实现业务逻辑的解耦，又可以避免数据库中的冗余。
隐方：是啊，很完美吧？
显方：但你的想法需要一个大家定一个规矩：即所有人都必须通过个接口来进行人兽判断。这在代码不多、并且软件复用思想深入人心的小型团队里倒是很适用，因为这个规矩很容易执行；但在大型团队里，这个规矩很难执行；因为很多人对业务层的重用并没有什么概念，他们会直接绕道去找数据库；而且即使他们愿意重用业务接口，在项目紧张时也懒得去找相应的接口规格，因为他们根本不知道这个接口是否存在，也不知道应该去找谁问这个问题。
隐方：这是另外一个问题了，主要跟软件过程有关系，或者可以借鉴SOA实践中的一些思想，我们另开一个话题再聊吧。
11 楼
抛出异常的爱
2010-06-23
chenjianjx 写道
这里要区分理想情况和现实情况。 一个上百人的大型团队，里面再分几个小型团队，大家的开发风格迥异，对软件复用的理解水平也参差不齐.......
“懒得去找相应的接口规格”某种意义上说就是一种失职吧？
elam 写道
“懒得去找相应的接口规格”某种意义上说就是一种失职吧？
把所的有程序员都开除
让teamleader + 项目经理组成一个team
同样的时间可以干同样多的活.
顺手还能提高一下项目经理的工资.
12 楼
slaser
2010-06-23
chenjianjx 写道
这里要区分理想情况和现实情况。 一个上百人的大型团队，里面再分几个小型团队，大家的开发风格迥异，对软件复用的理解水平也参差不齐.......
“懒得去找相应的接口规格”某种意义上说就是一种失职吧？
elam 写道
“懒得去找相应的接口规格”某种意义上说就是一种失职吧？
跟打仗一个道理。战术思想都不统一，不过是一群乌合之众。
一个好的将领，统兵上万必也是进退有序，若放任你手下的士兵按自己意志行动，其必败。
13 楼
babbyyang
2010-06-24
数据库设计一般要求满足三范式要求，但要根据实际情况从减少业务逻辑和提高程序性能方面来说必要的冗余还是必要的。
14 楼
chenjianjx
2010-06-24
这个贴子能不能关闭啊？ 已经从一种设计理念的高度降到了代码实现的层次，没人真正回答我的问题。
15 楼
beyondmind
2010-06-24
也许实现会驱动我们做数据库的调整，但很少。我接触的更多的因为性能等而做的冗余。
不要说100多号人的团队，成千上万的团队也必然是在一个基本规范基础上做事情的，最基本的分层可以认为对任何人都是适应的，而数据库设计理论上只应该与持久层的实现相关。
1、lz提到的显式和隐式我认为都没问题，我更倾向于隐式。
2、若将来不再按照是否直立行走来区分人和动物了的话，再加字段其实也不迟。
3、冗余在这里需要保证和直立行走的数据一致性，这个是个难点。
另外，业务层不需要接口，在PO/POJO上补充相应方法即可的。
不要说100多号人的团队，成千上万的团队也必然是在一个基本规范基础上做事情的，最基本的分层可以认为对任何人都是适应的，而数据库设计理论上只应该与持久层的实现相关。
1、lz提到的显式和隐式我认为都没问题，我更倾向于隐式。
2、若将来不再按照是否直立行走来区分人和动物了的话，再加字段其实也不迟。
3、冗余在这里需要保证和直立行走的数据一致性，这个是个难点。
另外，业务层不需要接口，在PO/POJO上补充相应方法即可的。
16 楼
魔力猫咪
2010-06-24
我个人赞成隐式推导，一般不建议定义布尔字段。
因为绝大多数的这种判断，都是需要进行一些比较计算的。如果设定一个字段来存这个值，那么在参与判断计算的其他字段发生变化或者计算公式变化的时候，就必须更新这个布尔值。如果考虑不到位，没有更新，那么就会造成错误。为了及时更新，编码里面判断计算的调用到处都是。只要相关字段有了变化，就得重新计算。至于什么时候读取这个字段就不知道了。也许永远不会被读取。所以从这点上说，定义一个布尔值字段是得不偿失的。既增加了大量的无用计算，又引入了忘记计算造成BUG的风险。触发器倒是可以保证不会忘记计算，但是性能损失很大。如果是频繁更新的表，触发器一多，那么插入修改的效率就非常低了。
我认为如果要定义布尔值字段，那么就要求这个字段不用任何判断计算。
我认为LZ提问的动物表问题，不应该设定是否“人”这种字段判断。而是应该使用继承关系进行处理。至于提出的程序员问题，这个不是设计问题而是管理问题。管理混乱，那么插再多的这种字段也没用。除了搞乱数据库结构，没任何好处。建议对新人采用老带新的办法。编码前一定要进行设计，搞清楚了要建哪些类、有哪些接口哪些调用再编码。最好编码前就把测试写出来。新人写完设计（当然不是那种骗客户的设计说明书）后老人一定要进行审核。确认没有重复编码和层次混乱。
最后还要说一下。LZ提出这个问题考虑的层次有点低，什么都放在了数据库层次考虑。这样会把太多的业务逻辑引入到数据库里面。建议尽可能把业务放到应用层而不是持久层。
因为绝大多数的这种判断，都是需要进行一些比较计算的。如果设定一个字段来存这个值，那么在参与判断计算的其他字段发生变化或者计算公式变化的时候，就必须更新这个布尔值。如果考虑不到位，没有更新，那么就会造成错误。为了及时更新，编码里面判断计算的调用到处都是。只要相关字段有了变化，就得重新计算。至于什么时候读取这个字段就不知道了。也许永远不会被读取。所以从这点上说，定义一个布尔值字段是得不偿失的。既增加了大量的无用计算，又引入了忘记计算造成BUG的风险。触发器倒是可以保证不会忘记计算，但是性能损失很大。如果是频繁更新的表，触发器一多，那么插入修改的效率就非常低了。
我认为如果要定义布尔值字段，那么就要求这个字段不用任何判断计算。
我认为LZ提问的动物表问题，不应该设定是否“人”这种字段判断。而是应该使用继承关系进行处理。至于提出的程序员问题，这个不是设计问题而是管理问题。管理混乱，那么插再多的这种字段也没用。除了搞乱数据库结构，没任何好处。建议对新人采用老带新的办法。编码前一定要进行设计，搞清楚了要建哪些类、有哪些接口哪些调用再编码。最好编码前就把测试写出来。新人写完设计（当然不是那种骗客户的设计说明书）后老人一定要进行审核。确认没有重复编码和层次混乱。
最后还要说一下。LZ提出这个问题考虑的层次有点低，什么都放在了数据库层次考虑。这样会把太多的业务逻辑引入到数据库里面。建议尽可能把业务放到应用层而不是持久层。
17 楼
抛出异常的爱
2010-06-24
飘在天上写架构作设计
的那些人是不会明白
写代码这群人的想法的.
一般他们从教科书上了解他手下人的想法.
的那些人是不会明白
写代码这群人的想法的.
一般他们从教科书上了解他手下人的想法.
18 楼
Inside
2010-06-24
我建议显示定义。
理由如下：
1、那个行走方式字段只应该让人判断行走方式，不应该做其它事情，过多的判断依赖这个字段或许是bad smell。
2、从规范上来说，加一个“是人是兽”的字段本身就是一种规范，而且是不会有歧义，学习成本查找成本很低的规范，比隐式推导所依赖的规范廉价得多。
3、开发方便许多，如果系统逻辑很复杂的话，大量隐式推导是会要人命的，出错的概率大大增加。
理由如下：
1、那个行走方式字段只应该让人判断行走方式，不应该做其它事情，过多的判断依赖这个字段或许是bad smell。
2、从规范上来说，加一个“是人是兽”的字段本身就是一种规范，而且是不会有歧义，学习成本查找成本很低的规范，比隐式推导所依赖的规范廉价得多。
3、开发方便许多，如果系统逻辑很复杂的话，大量隐式推导是会要人命的，出错的概率大大增加。
19 楼
chenjianjx
2010-06-25
深表同意。
有个应用场景就是：批量查找。在批量查找时如果没有这个字段是会死人的。
有个应用场景就是：批量查找。在批量查找时如果没有这个字段是会死人的。
Inside 写道
我建议显示定义。
理由如下：
1、那个行走方式字段只应该让人判断行走方式，不应该做其它事情，过多的判断依赖这个字段或许是bad smell。
2、从规范上来说，加一个“是人是兽”的字段本身就是一种规范，而且是不会有歧义，学习成本查找成本很低的规范，比隐式推导所依赖的规范廉价得多。
3、开发方便许多，如果系统逻辑很复杂的话，大量隐式推导是会要人命的，出错的概率大大增加。
理由如下：
1、那个行走方式字段只应该让人判断行走方式，不应该做其它事情，过多的判断依赖这个字段或许是bad smell。
2、从规范上来说，加一个“是人是兽”的字段本身就是一种规范，而且是不会有歧义，学习成本查找成本很低的规范，比隐式推导所依赖的规范廉价得多。
3、开发方便许多，如果系统逻辑很复杂的话，大量隐式推导是会要人命的，出错的概率大大增加。
20 楼
抛出异常的爱
2010-06-25
chenjianjx 写道
深表同意。
有个应用场景就是：批量查找。在批量查找时如果没有这个字段是会死人的。
有个应用场景就是：批量查找。在批量查找时如果没有这个字段是会死人的。
Inside 写道
我建议显示定义。
理由如下：
1、那个行走方式字段只应该让人判断行走方式，不应该做其它事情，过多的判断依赖这个字段或许是bad smell。
2、从规范上来说，加一个“是人是兽”的字段本身就是一种规范，而且是不会有歧义，学习成本查找成本很低的规范，比隐式推导所依赖的规范廉价得多。
3、开发方便许多，如果系统逻辑很复杂的话，大量隐式推导是会要人命的，出错的概率大大增加。
理由如下：
1、那个行走方式字段只应该让人判断行走方式，不应该做其它事情，过多的判断依赖这个字段或许是bad smell。
2、从规范上来说，加一个“是人是兽”的字段本身就是一种规范，而且是不会有歧义，学习成本查找成本很低的规范，比隐式推导所依赖的规范廉价得多。
3、开发方便许多，如果系统逻辑很复杂的话，大量隐式推导是会要人命的，出错的概率大大增加。
你要是把人动物都放在一个表中那才叫雷人
21 楼
chenjianjx
2010-06-25
说话要过脑哦。不要想都不想就说出来。
你要是把人动物都放在一个表中那才叫雷人
抛出异常的爱 写道
chenjianjx 写道
深表同意。
有个应用场景就是：批量查找。在批量查找时如果没有这个字段是会死人的。
有个应用场景就是：批量查找。在批量查找时如果没有这个字段是会死人的。
Inside 写道
我建议显示定义。
理由如下：
1、那个行走方式字段只应该让人判断行走方式，不应该做其它事情，过多的判断依赖这个字段或许是bad smell。
2、从规范上来说，加一个“是人是兽”的字段本身就是一种规范，而且是不会有歧义，学习成本查找成本很低的规范，比隐式推导所依赖的规范廉价得多。
3、开发方便许多，如果系统逻辑很复杂的话，大量隐式推导是会要人命的，出错的概率大大增加。
理由如下：
1、那个行走方式字段只应该让人判断行走方式，不应该做其它事情，过多的判断依赖这个字段或许是bad smell。
2、从规范上来说，加一个“是人是兽”的字段本身就是一种规范，而且是不会有歧义，学习成本查找成本很低的规范，比隐式推导所依赖的规范廉价得多。
3、开发方便许多，如果系统逻辑很复杂的话，大量隐式推导是会要人命的，出错的概率大大增加。
你要是把人动物都放在一个表中那才叫雷人
22 楼
lobbychmd
2010-06-25
如果是一体化的设计自然是表里面不需要这个字段。
考虑到开发以及实施、测试的具体工作则经常需要冗余的信息。
比如说我后台批量改一下数据没必要调用业务类吧。
或者可以看做是一个校验码之类的东东。
考虑到开发以及实施、测试的具体工作则经常需要冗余的信息。
比如说我后台批量改一下数据没必要调用业务类吧。
或者可以看做是一个校验码之类的东东。
23 楼
piao_bo_yi
2010-08-30
enfield 写道
天啊，居然有这样的业务规则，记得一个故事，大概就是，某哲学老师说，人类就是直立行走，身上没有毛的啥啥，然后学生抓来一只鸡，把毛拔光，说，这就是人？
建议把业务规则改了先，不然还是再搞一个冗余字段比较好。
建议把业务规则改了先，不然还是再搞一个冗余字段比较好。
同意，感觉更应该用字段表示人兽，用方法表示业务规则。应该用符合思维习惯的方式构建系统。
24 楼
xihuyu2000
2010-09-12
同意。
我觉得楼主犹豫的地方在于添加字段有些靠近数据库，没有体现oo思想，但是开发和维护方便；而推导方式就比较oo，但是开发和维护成本提高了。
我的想法是数据表加字段描述，在应用中使用接口来体现业务逻辑。这样会好一些
我觉得楼主犹豫的地方在于添加字段有些靠近数据库，没有体现oo思想，但是开发和维护方便；而推导方式就比较oo，但是开发和维护成本提高了。
我的想法是数据表加字段描述，在应用中使用接口来体现业务逻辑。这样会好一些
chenjianjx 写道
深表同意。
有个应用场景就是：批量查找。在批量查找时如果没有这个字段是会死人的。
有个应用场景就是：批量查找。在批量查找时如果没有这个字段是会死人的。
Inside 写道
我建议显示定义。
理由如下：
1、那个行走方式字段只应该让人判断行走方式，不应该做其它事情，过多的判断依赖这个字段或许是bad smell。
2、从规范上来说，加一个“是人是兽”的字段本身就是一种规范，而且是不会有歧义，学习成本查找成本很低的规范，比隐式推导所依赖的规范廉价得多。
3、开发方便许多，如果系统逻辑很复杂的话，大量隐式推导是会要人命的，出错的概率大大增加。
理由如下：
1、那个行走方式字段只应该让人判断行走方式，不应该做其它事情，过多的判断依赖这个字段或许是bad smell。
2、从规范上来说，加一个“是人是兽”的字段本身就是一种规范，而且是不会有歧义，学习成本查找成本很低的规范，比隐式推导所依赖的规范廉价得多。
3、开发方便许多，如果系统逻辑很复杂的话，大量隐式推导是会要人命的，出错的概率大大增加。
25 楼
mccxj
2010-09-12
这个例子太脑残了，没什么感觉，楼主应该务实点。其实用的时候做成方法即可，下面怎么做的随时可以调整。
26 楼
feizhouyu
2010-09-17
我同意这种说法。
显式设计，有些时候是节省了不少的时间。但更加要看到，冗余字段的维护的成本。
如果维护的成本很低，那么添加一个显式字段是正面的；但一旦维护这个冗余字段的成本非常大，比如业务中需要维护这个字段的地方非常多，那么再添加这个字段就得不偿失了。
所以我认为还是实际情况实际考虑吧，一味的抵制或者支持冗余字段都不是很好的想法。
显式设计，有些时候是节省了不少的时间。但更加要看到，冗余字段的维护的成本。
如果维护的成本很低，那么添加一个显式字段是正面的；但一旦维护这个冗余字段的成本非常大，比如业务中需要维护这个字段的地方非常多，那么再添加这个字段就得不偿失了。
所以我认为还是实际情况实际考虑吧，一味的抵制或者支持冗余字段都不是很好的想法。
魔力猫咪 写道
我个人赞成隐式推导，一般不建议定义布尔字段。
因为绝大多数的这种判断，都是需要进行一些比较计算的。如果设定一个字段来存这个值，那么在参与判断计算的其他字段发生变化或者计算公式变化的时候，就必须更新这个布尔值。如果考虑不到位，没有更新，那么就会造成错误。为了及时更新，编码里面判断计算的调用到处都是。只要相关字段有了变化，就得重新计算。至于什么时候读取这个字段就不知道了。也许永远不会被读取。所以从这点上说，定义一个布尔值字段是得不偿失的。既增加了大量的无用计算，又引入了忘记计算造成BUG的风险。触发器倒是可以保证不会忘记计算，但是性能损失很大。如果是频繁更新的表，触发器一多，那么插入修改的效率就非常低了。
我认为如果要定义布尔值字段，那么就要求这个字段不用任何判断计算。
我认为LZ提问的动物表问题，不应该设定是否“人”这种字段判断。而是应该使用继承关系进行处理。至于提出的程序员问题，这个不是设计问题而是管理问题。管理混乱，那么插再多的这种字段也没用。除了搞乱数据库结构，没任何好处。建议对新人采用老带新的办法。编码前一定要进行设计，搞清楚了要建哪些类、有哪些接口哪些调用再编码。最好编码前就把测试写出来。新人写完设计（当然不是那种骗客户的设计说明书）后老人一定要进行审核。确认没有重复编码和层次混乱。
最后还要说一下。LZ提出这个问题考虑的层次有点低，什么都放在了数据库层次考虑。这样会把太多的业务逻辑引入到数据库里面。建议尽可能把业务放到应用层而不是持久层。
因为绝大多数的这种判断，都是需要进行一些比较计算的。如果设定一个字段来存这个值，那么在参与判断计算的其他字段发生变化或者计算公式变化的时候，就必须更新这个布尔值。如果考虑不到位，没有更新，那么就会造成错误。为了及时更新，编码里面判断计算的调用到处都是。只要相关字段有了变化，就得重新计算。至于什么时候读取这个字段就不知道了。也许永远不会被读取。所以从这点上说，定义一个布尔值字段是得不偿失的。既增加了大量的无用计算，又引入了忘记计算造成BUG的风险。触发器倒是可以保证不会忘记计算，但是性能损失很大。如果是频繁更新的表，触发器一多，那么插入修改的效率就非常低了。
我认为如果要定义布尔值字段，那么就要求这个字段不用任何判断计算。
我认为LZ提问的动物表问题，不应该设定是否“人”这种字段判断。而是应该使用继承关系进行处理。至于提出的程序员问题，这个不是设计问题而是管理问题。管理混乱，那么插再多的这种字段也没用。除了搞乱数据库结构，没任何好处。建议对新人采用老带新的办法。编码前一定要进行设计，搞清楚了要建哪些类、有哪些接口哪些调用再编码。最好编码前就把测试写出来。新人写完设计（当然不是那种骗客户的设计说明书）后老人一定要进行审核。确认没有重复编码和层次混乱。
最后还要说一下。LZ提出这个问题考虑的层次有点低，什么都放在了数据库层次考虑。这样会把太多的业务逻辑引入到数据库里面。建议尽可能把业务放到应用层而不是持久层。
27 楼
miaow
2010-09-17
hibernate在同表保存继承的实现已经如此被鄙视了么？
如果能肯定永远不会有人和动物之外的实现类，肯定永远有相应属性、方法或者接口，那么怎么实现都行。
借数据库的一个实现方式说，那个标志属性本身和是否为空的函数索引没啥区别。
不肯定的话，hibernate在数据库层面用标志位、对象层面用多实现类的方式，个人认为是个概念清晰的好方式。不用hibernate也可以参考这个思路。
如果能肯定永远不会有人和动物之外的实现类，肯定永远有相应属性、方法或者接口，那么怎么实现都行。
借数据库的一个实现方式说，那个标志属性本身和是否为空的函数索引没啥区别。
不肯定的话，hibernate在数据库层面用标志位、对象层面用多实现类的方式，个人认为是个概念清晰的好方式。不用hibernate也可以参考这个思路。
28 楼
miaow
2010-09-17
隐式的说法很值得怀疑，是人是动物可以在运行时转换的设计？GSM。
29 楼
gaoc121
2010-09-19
为什么不再setter中书写逻辑呢？
当传入是人是兽时，就可以在其setter中确定了，再为行走方式赋值
这既可以减少冗余，又可以统一实现了吧，再新的新手，不会连实体有哪些属性都不清楚把
当传入是人是兽时，就可以在其setter中确定了，再为行走方式赋值
这既可以减少冗余，又可以统一实现了吧，再新的新手，不会连实体有哪些属性都不清楚把
30 楼
miaow
2010-09-19
gaoc121 写道
为什么不再setter中书写逻辑呢？
当传入是人是兽时，就可以在其setter中确定了，再为行走方式赋值
这既可以减少冗余，又可以统一实现了吧，再新的新手，不会连实体有哪些属性都不清楚把
当传入是人是兽时，就可以在其setter中确定了，再为行走方式赋值
这既可以减少冗余，又可以统一实现了吧，再新的新手，不会连实体有哪些属性都不清楚把
我想你和很多人一样被楼主带沟里了。OO的角度看问题，用标志位干啥。
按照这个话题，比较适当的方法是人、兽作为抽象类动物的两个实现类，而不是一个标志位。两个类分别实现自己的.运动()方法。实例创建采用工厂接受一个表示类型的参数。
多究一点，运动方法可以用策略模式，动物类的对应属性应该是个集合，表现可以有多个运动方式。