设计往往会偏向复杂

关联内容： 面向对象思想的头脑风暴（一）

关联的文章讨论了一个开放封闭原则的具体案例，其中前两个是超级复杂化的设计，而且还完全不符合开放封闭原则。但是，我想如果没有学习过所谓的设计模式的人，绝对不会犯前两个这种“模式过度”的错误的。因此，设计模式的爱好者们，要小心了，让你代码变得恶心的，往往就是你所热衷的东西。

然后第三个用委托。

第四个用组合接口的方式。

也许是例子不够好，我觉得第三第四也是不完美。

我们回顾一下设计要求：“

需要处理三种产品图书，数码，消费，需要计算产品的税率，图书的税率为价格的0.1，数码和消费类产品为价格的0.11，需要获得三种产品的信息，图书和消费类产品的信息为："名字：" + Name;，数码产品的信息为："数码类名字:" + Name;

”

有个产品类，然后让你加入税率率和打印的问题，你会怎么处理？

你可以让每个产品具体选择应该有的策略，就如关联文章所采取的设计。

产品 a.税率 = 策略1。

产品 b.税率 = 策略2。

但是：

产品 c.税率 = 策略1。

产品 d.税率 = 策略2。

……

你可能需要生产一千个不同产品，却发现来来去去都是这两个策略。

我的分析是这样，首先有个产品类，现在要加入和打印，根据要求，策略依赖的不是具体的产品，而是产品的类型。因此我觉得首先就应该把抽象上升到上一个层次，针对不同产品的类型来编程。

数码类 {税率}

产品类 {类型 a;价格 b;名字 c;

总价：a.税率 * b;

打印：a.打印(c)

}

产品类 computer.a = 数码类。