跨越分析与设计的鸿沟

这些设计类,如果按DDD规则来分层,如何归类呢?

感觉是Visitor模式. 完全不是 原来 的 Bridge 模式.思考中......

而且Visitor模式有一个不好的地方,如果我的产品类别经常变动,Visitor在这里就要改动. [该贴被willem于2008-06-18 18:20修改过]

我想请教freebox ,为什么你想到的是这种设计方案(Visitor模式), 能否把你的思考过程讲一下,谢谢

虽然这些个模式都很熟悉,但老用错,怎么用设计模式总有个章法.比如从哪个方面分析入手等等. 我再比较了一下这两个模式,一个是行为,一个结构. 而上面的逻辑应该是行为. 似乎从设计模式的分类来入手也是一个方面.

也许和您所说的原来的Category意义不同，原来的多个Category可能使用同一种检查方案。我的Category拥有“检查方案类别”的意义，就是“不检查、总检查这些，以及等等”。 我也不确定这个方案就是适用的，并且我不知道这就是Visitor模式（不是说您说这是Visitor模式说错了，是我在概念上不清楚），仅仅是觉得应该这样设计。 理由就是您说的检查方案（该类别的库存处理逻辑）和检查方案类别（产品类别或产品类别的集合所具有的检查类别）都有可能变化。 改个名字：

class Category{
    CheckKind kind;
}
abstract class CheckKind{
    abstract void accept(CheckStock cs);
}
class NeverCheckKind extends CheckKind{
    void accept(CheckStock cs){
        cs.check(this);
    }
}
interface CheckStock{
    void check(NeverCheckKind a);
    void check(AlwaysCheckKind b);
}
class Checker implements CheckStock{...}

abstract class CheckKind
{    
      abstract void accept(CheckStock cs);
}

这个抽出来了,比较好

楼上讨论很不错，Freebox的设计方案看起来还是合适恰当的。

我想补充的是：checkStock绝对不能放入OrderService中，因为checkStock是重要的下单判断标准，属于业务逻辑，根据Evans DDD和充血理论，业务逻辑应该进入领域模型，而不是服务OrderService

Evans DDD中有一个类似案例展示过滤筛选，大概是发票是否过期的判断，根据Domain Model又建立了一个Proxy对象用来封装判断发票是否过期，反正发票是否过期不能进入服务。

checkStock放入OrderService中,还是按常用的分层架构套路, 用Proxy,我倒要试试,最终的service层,我想应该是很薄的一层.

checkStock不能放入OrderService，要坚持静态决定动态的原则。下面贴一下我的设计，不足之处，请大家指正，共同讨论改进。 //订单 public class Order implements Serializable {

private String No; private List items;

//检查库存是否足够 public boolean checkStorage(){ boolean result = false; for (Iterator itr = items.iterator(); itr.hasNext();){ OrderItem item = (OrderItem)itr.next(); result = item.IsStorageEnough(); if (!result){ break; } } return result; } }

//订单项 public class OrderItem implements Serializable {

private String No; //序号 private Product product; //产品 private Double qty; //数量 private long deliveryPeriod; //送货周期

//检查库存是否足够 public boolean IsStorageEnough(){ ICheckStorage checker = null; if (product.getCategory().getCode().equals("A")){ checker = new ACheckStorage(); } else if (product.getCategory().getCode().equals("B")){ checker = new BCheckStorage(); } else if (product.getCategory().getCode().equals("C")){ if (deliveryPeriod > 30){ checker = new ACheckStorage(); }else checker = new CCheckStorage(); } return checker.checkStorage(product, qty); }; }

//订单仓储 public class OrderRepository { public void save(Order order){ } }

//产品 public class Product implements Serializable {

private String ID; private String code; private ProductCategory category; }

//产品类别 public class ProductCategory implements Serializable {

private String ID; private String code; }

//检查库存接口 public interface ICheckStorage { public boolean checkStorage(Product product, Double qty);

}

public class ACheckStorage implements ICheckStorage {} public class BCheckStorage implements ICheckStorage {} public class CCheckStorage implements ICheckStorage {}

//订单服务 public class OrderService {

OrderRepository ordRepstry; //下单 public void dispatchOrder(Order order){ if (order.checkStorage()){ //to do 设置订单状态为“下达”等操作 ordRepstry.save(order); } } public OrderService(OrderRepository ordRepstry) { super(); this.ordRepstry = ordRepstry; }

}

OrderService是repository？只是取了这么个名字吧？

>>>OrderService是repository？只是取了这么个名字吧？ OrderService肯定不是repository啊，两者的角色定位不一样。

我的设计在附件里，望大家批评指正。 我的意思是楼主图中的OrderService，因为我发上帖的时候还没有看到您的帖子，非常抱歉。 model.rar

killer 明确了各个类的责任,赞同,但设计上我还是比较喜欢freebox 的设计, 不喜欢一堆的if-else. 在各个层传递数据时, 喜欢POJO, 所以可以再用一个类和POJO结合而达到一个所谓的充血实体.比如用代理,装饰等可以做到.

[该贴被willem于2008-06-20 15:26修改过]