Domain Model 探索

呵呵，可能你理解错了。
我并没有说引入取款单这个对象不好，相反它可以从抽象层面上规范接口，这是另外一个话题了。

我的主要意思是说，动作是对象的动作，面向对象的要义是对象决定行为！而不是行为决定对象！

这个用例主要交互对象是 用户和atm机 其中用户是外部对象，不在系统内部，换个视角看问题，优化一下用例：
1、ATM机读卡
2、ATM机读如密码、帐户验证
3、ATM机执行操作
1）查询
2）取款
3）退出
atm机作为对象很自然。以上这一段是去掉外部对象的用例。下面再看取款的这个子用例:

再优化一下用列看看哪些actor做乐那些事情，把句子完整化
（0）ATM拿到了结构化的取款单
（1）ATM取款金额是不是合法
（2）ATM询问账户，帐户中有没有足够的钱
（3）ATM中有没有足够的现金

这里出现了3个对象的合作 ATM 取款单 账户。他们的合作是再ATM机取款这个动作的名义下的。整个操作的主用对象都是ＡＴＭ！

还是那句话面向对象的要义是对象决定行为！而不是行为决定对象！

定义一个动作　打：打人实现打，打钉子实现打，打飞机实现打，好像也是很多态的，是is a 的关系么？　它关注的是过程！　打本身并没有描述出一个问题域！你到底要研究，什么？科学？历史？地理？范围太广了。还是先来到历史这个领域里研究吧。

同意你所说的对象决定行为，但我认为这个对象是广义的，包含隐式的和显式的。而行为是内部行为，也即该对象所固有的。不应该把涉及到该对象的外部行为也作为该对象的一部分。



反对把ATM作为整个操作的主用对象。
主要的问题在第(2)步，ATM询问帐户，这根本不应该作为ATM本身的业务逻辑。
把帐户的逻辑通过ATM这个对象来传递，在分析上是不合理的。

老兄，ATM是具体应用的对象，业务层应当通过接口同它打交道,或者ATM通过
业务层的返回结果作出下一步动作。
按照你的设计如果现在是柜台取款，那不是在柜台里非得放个ATM不可？

ATM是一个对象，不过这个对象远远不是一个狭义上的对象，更确切的来说是一个系统。
用例系统边界划分也是有问题。
ATM与存款帐户不应该划分在一个用例中。
可以将ATM和后台分别作为两个系统来对对待，具体的用例分析分别基于这两个系统作独立的分析。 他们之间的联系是发送的报文。
比如取款,
后台系统是作为一个参与者出现,他应该位于ATM系统的边界外面.
至于ATM这个子系统的用例分析和actor等等的确认,需要具体情况具体分析.如果你拥有了现成的接口可以用 ,那么将这些个接口直接作为一个对象/module来参与具体的用例分析将会大大简化分析过程。
对于后台系统的取款用例，ATM作为一个actor。 这个用例的动点是atm发出的message。

有一点是可以肯定的，和用户交流的是ATM，用户不想知道　atm是如何取到钱的，以怎样的顺序与账户交流的。这个我想大家没有什么意见。

先不看划分子系统问题
依赖关系等技术问题，
就用例说用例：

顾客视角：atm　我给了你足够的信息，你把1000钱给我－－〉atm.取款。
atm视角:等一下，１）我看看取款金额是不是合法 ，可以。我再找找看账户有么有钱，喂账户老弟，看看这个账号001里面有没有1000钱啊？
账户视角：我看一下：这是个财主没问题，要多少有多少。
atm视角：yeah！我要拿1000块．
账户视角：好勒！搞定．
atm视角：yeah！我开始吐出大把的钞票了．
顾客视角：爽，下次再来！（这个傻帽假的信用卡也认不出来！）

是不是很像一个sequence图？各人承担各人的角色；是不是很清楚？各人做各人的事情．按不同的角色，把场景预演一遍，不是业务分析的好方法么？（题外话）



顾客对ATM要求是什么？取款是其中的一项，取款就要访问账户接口，这个时候ａｔｍ就作为顾客到账户的代理．真正的业务逻辑还是在账户这个类上．

面向对象相互合作的几个对象，各人把各人的问题域搞清楚了，然后才需要她们之间相互合作来解决问题，解决问题的过程就是在不同的对象之间导航．一个类的一个方法就能解决问题，反而不正常：

总经理说：小王把小明给我找来！，小王去找小李要小明的电话，再打到前台接通外线（落后一点），找到小明，小明在坐车过来！　

难道这一段写一个找小明ＡＣＴ？
否则不是小王依赖小李，很正常．这才叫协作精神么．

下面从技术角度来看看：
所以从atm导航到账户很正常．atm的类没有把账户作为他的私有属性，只是在一个具体的取款方法中用到．所以atm接口本身对账户不是依赖的．具体的atm对具体的账户有依赖关系很正常．大家协作闹革命么！

当然把atm复杂成一个子系统也是一样的，当然会复杂很多（作为讨论问题还是把例子简单点好，复杂的部分可以单独拿出来讨论）．

有分工有合作，不要太还怕合作了！

我怎么感觉等于没说阿！
这些咚咚是最虚的，OO大家都可以大说特说，说得天花乱坠，可是很多人到真正要干活了，便不知道从何入手拉！ 不是说你啊，切勿对号入座！ 

TO firebody:
不知道你想说的主要意思是什么？你的观点？
支持act方式？


大家讨论问题，上面这些话太过主观，和讨论的问题也没什么关系．反而伤了大家的感情，其实都是探讨有对有错的．

呵呵，送你句话：学习都有一个由厚到薄，由薄到厚的过程．

我的意思是：这个取款方法不是ATM所固有的，不应当放在ATM这个对象的内部。
ATM和帐户互相之间不应该有依赖关系。

设想一个新的用例：柜台取款。
你的取款方法又放在哪个对象里呢？

当然是银行柜台这个对象里面，当然是抽象意义上的柜台，取款，存款．．．．．．．

当然还可以把接口抽象化，把取款机和柜台的共同部分的接口抽象出来，但决不是一个方法的接口如同取款Ｉｎｔｅｒｆａｃｅ这一类的

对于后台的取款用例，不同意将ATM作为actor，在帐户验证取款这个步骤时，ATM仅仅是一个透明传输通道，和ATM本身的业务逻辑毫无关系。

在物理上，信息是经过了ATM，但是ATM没有对这些信息进行业务处理。
这就好象我们的信息都经过了网卡、交换机和路由器。
但是我们不会认为我们是在和网卡进行交互，网卡又和交换机或者路由器进行交互。

再重复一遍：
    在询问帐户和帐户验证这个步骤，主角是实际的用户，而不是ATM机。
    无论是柜台询问、还是ATM划卡、还是电话银行乃至网上查询，本质上都是用户和帐户的交互过程。
    这个步骤不属于ATM的业务逻辑。