对象，你喜欢极品装备吗？[更新]

关于该思想的实现，请参照 实现对象装备模式

本来想说很多客套话的，但拿捏不好语气，该帖子主要讨论一个草根想法。
大家一看就知道我是新鸟一只，只是在这混了好久，第一次发言，想让大牛们给我指导一下，我的收获会很大。
先谢谢了，请尽量看完。(如时间不充足，请看红色部分！)

草根来源：
场景——一个自运营的门户网站
系统——考虑了很久，打算用DWR+MeshCMS+guice+Db4o，轻轻轻量级。。。。
思路——使用基于文件的内容管理，生成静态的内容数据页，动态交互使用ServerPush，完全OO模型，直接对象持久
问题——使用对象数据库，那我的领域模型怎么工作，要DAO合适吗？魔鬼告诉我，db4o的session太好用了，耦合吧-_-
思考——在学习google的guice期间，当时正好看到方法注入，本想跳过，一般我不用，但突然想到了，既然db4o不适合
存储复杂业务的对象，那么我在对象取出时给他注入他将要用到的业务逻辑方法。。。。。Service轻松了好多，好像更
OO了。。。。于是，请看下文(如时间不充足，请看红色部分！)！

关键字：装备模式、套装模式

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
今天偶然之间又看了JavaEye大牛的文章，就是分析DDD模型的3种思想实现。
我联想到，在两年以前未接触Hibernate、iBatis等ORM框架前的一个项目，寿光一散热器公司的
工程车间管理系统，里面从工艺管理、产品周期管理、人员管理到订单管理一气呵成。那时的我
无独立开发经验，自己设计摸索了一个月，也在车间里转悠了一个月，虽然坚定了OO的设计思路
还有Java的设计模式以及数据结构Java版，但最终我仍然使用C#开发的，因为是桌面应用么～～
我把每种管理的原子数据结构分离出来，在不符合Bean规范下做了简单的PO，当时遇到的问题就是
应该用一个上层容器管理这些OOD出来的模型对象，还是直接在这些对象里写入逻辑让控制层方便
运算（其实运算也不方便），最后按这种结构做了几个试验，发现效果可以，效率不错，并且形成
一种规范，之后的每种对象都如此管理，在类中写入自身动作的持久业务。这里呢，持久我都是用
静态方法，其他业务都是跟属性并存，我认为这样，符合老师教我的OO设计，一个对象如果只有数据
那应该叫C中的结构TYPE，对象要能自己描述自己，自己应该有自己独立的原子性动作，这里我也坚决
认为团队动作的化应该由上层对象管理，因为上层对象也是被OOD出来的。最后项目完成了，使用上
问题较少，前面一个月的分析设计没有白做哦！但最大的问题就是，当厂长提到许多小细节的优化或者
流程上的改进时，我发现很难插手修改，难以想像修改后会有多少异常。。。。。
其实，那时候哪懂DDD啊，只是看着.Net的ADO好用，然后经理了过渡设计，在脑子里重构了多少遍
之后才动手，已经发挥我的极限能力了。不过我想说的是第3种贫血模型就是耦合了模型、DAO的方式
仍然使用于某些场景，是可行的而且是高效的，设计1月后，我自己用了10天编码就全部完成了，包括报表
也做好了。

回忆了许多，其实想说，如今了解了DDD、ORM、重构与设计之后，反而被约束了许多，很多想法还没实践
就被已有的知识为“创意”判了死刑。现在又有一创意，在脑中萌发，我想改变他的命运所以我没有继续想，
我要先写下来，人的思维和搜索引擎总是太高级，太快，太厉害了，但总是会忘记和遗漏某些不经意的小
细节，其实这也是电脑目前不可能做到的一件事情。

OO的特性里，继承、封装、多态，我又联想到一个名词，那就是包装。与其说DDD中有贫血模型，不如说
是裸体模型，他没有穿任何衣服、装备、宠物、家族等等（扯到网络游戏里了）。不过事实就是如此，我们
的生活中不可能离开这些，那在编程的原始社会，从低级到高级，好像人会站立行走了，从过程到OO好像
人们有语言和沟通了，越来越接近自然的法则就是，我们的对象要穿衣服了，不光要有衣服，还要有手套、
工具、坐骑、家（持久层?!）。玩过变装类游戏角色的人知道，当他们换衣服时等于换了一种角色
换了一种特有属性，唯一不同的就是基础属性，他的动作和专注点发生了变化，那么，我们的软件中，每个
对象好像不是一种角色，只完成单一的任务，而是在不同的场景，使用不同的服务，发生不同的动作，造成
不同的变化，那么每一套对象之外的动作、属性、状态是不是像装备一样包装着这个对象呢？！是不是可以
给对象准备好一套装备，在他要去工作或者执行任务以前把他武装起来而不是裸体上阵呢？我想问问对象，
你喜欢极品装备吗？ 当然他回答不了我，但我列了几个我自以为的可选答案：
A.无所谓（仍然保持原始的性感美丽）
B.喜欢（向往现代文明）
C.贼喜欢（迫切的愿望说明他厌恶了裸奔的日子）
D.讨厌，就是喜欢暴露 （。。。。。。。你男的女的？不对，公的母的？还不对，雄的雌的？反正变态）

这只是一个雏形，一种想法和冲动，我没有脑力和能力继续实践他，至少目前还没有，要休息下脑子才可以，
而且我的知识结构混乱，也不敢继续想，但是直接告诉我这个道路在黑暗中有一思光明，好像从小到大我的
这种感觉总是很准。还有一点想说的是，程序员的性格和兴趣不同，就好像游戏里的不同职业团队里的不同
角色，总是可以完成任务，不在乎哪中道路达到目标。只是我感觉周围有像我一样，那种路都不想选择而又
想要到达目的地的人，仍然在继续找寻一个新的道路（“世上本没有路，走的人多了便成了路”）。

最近根据这个思路衍生了一个使用DDD的套装模式，现正在写一个简单的实现，等测试完成后尽快跟大家分享。

睡觉了，希望明早上班这帖子还在，保佑，阿门。
（听同事说，好多人第一次法帖都被咔嚓了。。。）

最近就在研究Guice，如果lz的想法能行的通的话……有点意思

是裸体模型？
MS：数据库如果还是三代的关系数据库
裸体模型就是它的逻辑结构吧。
OO是现实的模拟。。。

而不是把衣服从人身上长出来的。。。
先设计时把衣服，都作成接口
把裸体的数据库拿过来

而代码只是把衣服穿上的过程而已


PS：这个还不够良好吧。。。。

有点错误引导，你的意见我理解了，但是希望其他人不要理解错了，我们是两种思路，没有必要争论。
第一，接口不是衣服，更象是对象群居的洞穴，因为衣服是一人一件的；
第二，我们不要围绕数据库设计，数据库＋对象也不是自然对象，对象是有自己的行为动作的;
第三，把数据库里拿来的对象直接到服务接口，不就等于裸体上阵么，我们的思路是两种路线，我只想给对象
加一件合身的衣服，让他工作起来更方便的衣服。

给贫血的领域对象穿衣服？衣服随便换，不同的衣服不同的效果？

感觉有点太理想化了吧

过度设计的味道。。。

我那句话也可以说成是：“我不想看着模型对象裸奔”
这只是自然化，不是理想化，也没有过度设计。因为我到现在还没有
掌握一种模型对象的设计模式，只知道Bean规范而已。
因为他自从DDD以来一直在裸奔。
模型对象只有结构，只能描述他该有什么，而没有描述一些不该有的
举个例子：人的年龄可以是int，因为 int是非负整数，但是自然规则
或者业务规则里，这个值不应该大于100，那好你可以说万一是101岁
的老人呢，那我可以说这个值不能大于200吧，你如果再说万一有长命
的活到300岁了，那我只能回敬你，万一有活过 65536 岁的怎么办？
难道让年龄的属性使用Long？那应该怎么办，应该有自身的限制属
性的方法，我限制他只能200，当他到200给他穿寿衣！当他穿了寿衣
代表他不在世界了，不能进行正常的业务逻辑了，符合自然法则了。
普通衣服可以约束你有两只手，不是至少而是至多（有残疾人）那么
如果是畸形，真有三头六臂，那可以给他穿特质的衣服。

以上只是为了表述我的思路，可能许多朋友没有理解，我的表达可能不够精确。说这些还是希望不要误解，谢谢！

我提到“裸体”不只是衣服，还有“装备”、“工具”、“武器”等等
总之是业务战场里会需要用到的一种“包装”。

一战士上战场。。。。
你要不要给他开一卡车军火？
用到了再加入叫TDD，
先设计好了给他四十子弹一把枪叫瀑布开发。
而你把发霉的代码重构时
向哪方面隐藏？
隐藏在pojo内就叫弃血，
向service中隐藏就是贫血。

OO设计是从前向后从上向下，贫血好设计
TDD就是从下向上，充血好改。。。

衣服是要放在衣橱里的，军火是在军火库里的！
不是每个士兵不带枪就要贫血；
更不是把你说的枪放在战场上；
我们先不要讨论开发方法～～
我在想衣橱要怎么设计，怎么把衣橱里面的衣服给模型。
因为联想到GoogleGuice为什么把绑定关系的类叫做model？！
因为我感觉每种绑定组合就像是一套定制的装备，不同的
组合适用于不同的战场，至于穿的方法用AOP，不用关心装备方面
有了你就用。