SpeedVan
2013-05-07 18:46
2013-05-07 07:56 "@banq

"的内容

逻辑一致性判断被放在了客户端或service中,而不是在模型A内部,在多线程环境下会造成A的状态结果混乱,会出现A.upper<A.lower情况。

假设A的lower和upper的初始值是(0, 5);

同时下面两个请求事件发生:

一个 ...

很明显,这是状态引发的问题。在一个完整的逻辑中,所有定义都不能改变,引入改变实际上是无视掉语言上的时间问题。(0,5)变(4,3)就是例子,在客户端A,B中的逻辑依据是(0,5),也就是说结果应该分别是(4,5)和(0,3),到底取哪个取决于决策,而并非混合。若果是先A后B,则B失败,先B后A,则A失败,若果同时,则取决于策略选择进行排斥选择。

flyzb
2013-05-10 00:04
2013-05-05 13:28 "@banq

"的内容

public class Customer {

private String firstName;

private String lastName;

private Wallet myWallet;

public float getPayment(float bill) {

if (myWallet != null) {

if (myWallet.getTotalMoney() > bill) {

theWallet.subtractMoney(payment);

return payment;

}

}

}

对于以上代码,看似把逻辑都放进了模型内,但却让customer与myWallet的行为耦合了起来。如果customer除了支付外,还有看书、看电影、购物、聊天、交友等很多业务,那么customer会臃肿成什么样呢?

我在设计时坚持2条原则:

1、单对象方法中不涉及其他对象;

2、只有场景方法才能组合不同对象的方法。

[该贴被flyzb于2013-05-10 00:05修改过]

gsft
2013-05-10 10:15
2013-05-10 00:04 "@flyzb

"的内容

对于以上代码,看似把逻辑都放进了模型内,但却让customer与myWallet的行为耦合了起来。如果customer除了支付外,还有看书、看电影、购物、聊天、交友等很多业务,那么customer会臃肿成什么样呢? ...

这样的话“边界”在哪里?

flyzb
2013-05-10 21:00
2013-05-10 10:15 "@gsft

"的内容

这样的话“边界”在哪里? ...

从customer本身来说可能会参与到多种业务场景,“至于划分边界”当然是按“核心业务场景”来划分的,比如“支付”就可能是一个“核心业务场景”,它是由许多小的活动场景组成的。

aixs
2013-05-10 23:06
检查钱包里的金额是否足够支付是customer的一部分

至于说刷卡支付,这只是customer的一种委托支付的形式

猜你喜欢