赛跑的专栏

抽象类和接口在语法和设计原则上的区别1.类是对对象的抽象，可以把抽象类理解为把类当作对象，抽象成的类叫做抽象类   接口只是一个行为的规范或规定，微软的自定义接口总是后带able字段，证明其是表述一类类“我能做。。。”抽象类更多的是定义在一系列紧密相关的类间，而接口大多数是关系疏松但都实现某一功能的类中2.接口基本上不具备继承的任何具体特点,它仅仅承诺了能够调用的方法; 3.一个类一次可以

从设计原则到设计模式• 针对接口编程，而不是针对实现编程– 客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口。• 优先使用对象组合，而不是类继承– 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。• 封装变化点– 使用封装来创建对象之间的分界层，让设计者可以在分界层

本人认为观察者模式和C#中委托的功能是相似的，但。。。机制很不一样。。。可以参看我写的C# 委托机制一文。观察者模式和委托都是在一对多的情况下，当事件发送者产生事件后，由观察者接收，并产生相应的动作（虽然都是同一接口，但。。。实现却是在内部，所以，我叫你吃饭，你可以去吃麻辣烫）。当然，你还可以绑定多个事件处理方法。在这里，我举个例子，一个出版社和各分销商的例子。各分销商是观察者。作为出版社的分

今天老师讲了单件模式，这个模式比较容易学，就开始讲这个。不过俺至今还没发现它有什么特殊用途，虽然，在网上有搜到一些资料关于它的用处。这个模式充分利用了私有的构造函数来解决其他类不能new它，也就是不能实例化它。造成了只有一个对象的情况，在某些设计下，只允许一个对象存在的情况，就使用该模式是最佳选择（当然最好也是在单线程下）还有就是在singleton模式下，是不能让类序列化它，即不能加

 软件设计最大的敌人，就是应付需求不断的变化。变化有时候是无穷尽的，于是项目开发就在反复的修改、更新中无限期地延迟交付的日期。变化如悬在头顶的达摩克斯之剑，令许多软件工程专家一筹莫展。正如无法找到解决软件开发的“银弹”，要彻底将变化扼杀在摇篮之中，看来也是不可能完成的任务。那么，积极地面对“变化”，方才是可取的态度。于是，极限编程（XP）的倡导者与布道者Kent Beck提出要“拥抱变化”，从

以前在 csdn上看到一篇  “你还在使用if/else吗？”文章，提到如果你还在使用if语句，那么你就需要对你的代码重构。那篇文章许多人的评论上褒贬不一，但我现在想举的一个例子是对if/else的重构。（当然，是从别人那偷学来的，^_^)。enum employeetype{     salers;     engineer;   manager;}if(employ

今天看到吕老师的模版方法模式，他举了重构的原则，学习！ 重构的原则在对一个继承的等级结构做重构时，一个应当遵从的原则便是将行为尽量移动到结构的高端，而将状态尽量移动到结构的低端。1995年，Auer曾在文献【AUER95】中指出： 应当根据行为而不是状态定义一个类。也就是说，一个类的实现首先建立在行为的基础之上，而不是建立在状态的基础之上。 在实现行为时，

简单工厂模式并不属于23种设计模式，它只是一个入门，比较容易理解，那好，我这个菜鸟也从这里开始入门了。简单工厂模式是类的创建模式，又叫做静态工厂方法模式。就是由一个工厂类根据传入的参量决定创建出哪一种产品类的实例。    工厂类：担任这个角色的是工厂方法模式的核心，含有与应用紧密相关的商业逻辑。工厂类在客户端的直接调用下创建产品对象，它往往由一个具体的类实现。    抽象产品角

工厂方法模式是类的创建模式，又叫做虚拟构造子模式或多态性工厂模式。它的用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。简单工厂模式的缺点：由于工厂类集中了所有产品创建逻辑的，如果不能正常工作的话会对系统造成很大的影响。如果增加新产品必须修改工厂角色的源码。工厂方法模式的优点：在工厂方法模式中，核心的工厂类不再负责所有的产品的创建，而是将创建的工作交给子类去做。这个