关联内容： 面向对象思想的头脑风暴（一）
关联的文章讨论了一个开放封闭原则的具体案例，其中前两个是超级复杂化的设计，而且还完全不符合开放封闭原则。但是，我想如果没有学习过所谓的设计模式的人，绝对不会犯前两个这种“模式过度”的错误的。因此，设计模式的爱好者们，要小心了，让你代码变得恶心的，往往就是你所热衷的东西。
然后第三个用委托。
第四个用组合接口的方式。
也许是例子不够好，我觉得第三第四也是不完美。
我们回顾一下设计要求：“
需要处理三种产品图书，数码，消费，需要计算产品的税率，图书的税率为价格的0.1，数码和消费类产品为价格的0.11，需要获得三种产品的信息，图书和消费类产品的信息为："名字：" + Name;，数码产品的信息为："数码类名字:" + Name;
”
有个产品类，然后让你加入税率率和打印的问题，你会怎么处理？
你可以让每个产品具体选择应该有的策略，就如关联文章所采取的设计。
产品 a.税率 = 策略1。
产品 b.税率 = 策略2。
但是：
产品 c.税率 = 策略1。
产品 d.税率 = 策略2。
……
你可能需要生产一千个不同产品，却发现来来去去都是这两个策略。
我的分析是这样，首先有个产品类，现在要加入和打印，根据要求，策略依赖的不是具体的产品，而是产品的类型。因此我觉得首先就应该把抽象上升到上一个层次，针对不同产品的类型来编程。
数码类 {税率}
产品类 {类型 a;价格 b;名字 c;
总价：a.税率 * b;
打印：a.打印(c)
}
产品类 computer.a = 数码类。