炸丸儿

在设计模式的六原则中提到“合成/聚合”原则，其核心思想是尽量使用合成/聚合，尽量不要使用类继承。那么，问题来了，为什么在编程中尽量不要使用类继承呢？举个例子我想大家就能明白了。        现在，手机已经成为我们普遍使用的的通讯工具。手机分为很多很多的品牌，如：“三星、华为、苹果”等。另外，手机除了通讯功能外，还添加了许多的娱乐功能。采用面向对象的思想，将上述内容中用UML类图表示出来，结果如

《大话》中的23种设计模式的代码都是根据UML类图在C#中实现的，可见类图对于面向对象编程的重要性。在UML类图的四种关系这一篇文章详细地介绍过类图之间的关系，关联（聚合、组合），依赖、继承和实现。这篇文章就类图的四种关系在C#的具体实现做一个介绍。       关联       关联是一种“拥有”关系，指一个类需要“知道”另一类的属性或方法。在代码中的表现为在类A的定义中使用类B作为成员变量

单一职责原则：各司其职        定义：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类        解释：如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，        优点：1、可以降低类的复杂性，一个类之复杂一项职责，其逻辑肯定要比负责多项职责简单的多。2、提高类的可读性，提高系

“工厂”一词我想大家都耳熟能详，在现实生活中，工厂是负责生产产品的基地。那么，在设计模式有一种模式叫做“简单工厂模式”，通过对“工厂”一词的理解，这里的简单工厂模式可以理解为负责生产对象的一个类。

在简单工厂模式中提到了其存在的缺陷，简单工厂模式违背了“开放-封闭”原则，一旦添加新的产品就不得不修改工厂类的代码，这样会造成工厂类的实现逻辑过于复杂。工厂方法模式的存在就很好地解决了这一问题。        工厂方法模式，定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。说白了，就是把简单工厂模式中的工厂类抽象成一个接口（依赖倒转原则），这个接口只有一

上篇文章中介绍了简单的三层架构（U层、B层和D层），三层架构能同过业务逻辑层（B层）作为中间层，对表示层（U层）和数据访问层（D层）进行“解耦”。三层之间各司其职，互不影响，从而保证了系统的正常运行。     简单三层架构虽然解除了U层和D层的耦合，可是U层和B层，B层和D层都有很高的耦合。那么，能否对三层进行进一步的解耦呢？答案是肯定的，之间学习过的设计模式就能很好地解决这个问题。先来一张包图