一个外部具体对象的引入，必然会给一个模块带来与外部模块之间的依赖。而具体对象的创建始终是我们无法规避的。即使我们可以利用设计模式的工厂方法模式或抽象工厂封装具体对象创建的逻辑，但却又再次引入了具体工厂对象的创建依赖。虽然在设计上有所改进，但没有彻底解除具体依赖，仍让我心有戚戚焉。 以一个电子商务网站的设计为例。在该项目中要求对客户的订单进行管理，例如插入订单。考虑到访问量的关系，系统为订单管理提
- 添加新评论
- 阅读次数：
《编程絮语》之二
没有对象协作的系统是不可想象的，因为此时的系统就是一个庞大的类，一个无所不知的“上帝类”。每个对象都有自己的自治领域，“各人自扫门前雪”，对象定义的法则就是这么自私。单一职责原则（SRP）[1]体现的正是这样的道理。对象的职责越少，则对象之间的依赖就越少。这一前提就是对象具有足够的高内聚与细粒度。这样的对象一方面有利于对象的重用，另一方面也保证了对象的稳定性。
对象的职责可以是自己承担，也可以委派给其他对象。因此，有对象就必然有依赖，正如有人就有江湖。那么，我们该如何降低对象之间的依赖？第一要则是依赖于抽象，如依赖倒置原则（DIP）[2]所云。如果无法依赖于抽象，则至少应该保证你所依赖的对象是足够稳定的。事实上，最稳定的对象就是抽象对象，所以万法归一，稳定才是降低依赖的基础。
依赖之殇的源头是“变化”。变化与稳定显然是矛盾的，软件设计的最大问题就是如何协调这两者之间的矛盾。我们需要像高明的杂技师，要学会掌握平衡，能够在钢丝绳上无碍的行走。那么，如何解决变化带来的影响呢？答案是利用封装来隔离变化。
封装的一种方式是抽象，因为相对于实现而言，接口总能保持一定的稳定性。例如税收策略。对于调用方而言，只是希望能够得到准确的税值，至于如何计算，则不是他关心的内容。抽象出计算税值的接口，就能够隔离调用方与可能变化的税收策略之间的依赖关系，如下图所示：
利用抽象还可以解除对特定实现环境例如外部资源、硬件或数据库的依赖。此时抽象隔离的变化可能是外部环境提供的API。例如，在考勤系统中，利用抽象隔离不同型号考勤机的变化。
利用抽象解除对象之间的依赖，还可以保证系统具有良好的可测试性。因为调用者依赖于抽象接口，就为我们引入Mock对象（当然也可以是Fake对象）执行单元测试提供了方便。尤其是当我们对领域对象进行测试时，如果领域对象需要对数据库操作，可以通过依赖抽象的持久对象（或仓储对象）实现职责的委派。此时，我们可以引入持久对象的Mock对象，模拟领域对象持久化的职责，既分离了领域对象与数据库资源的依赖关系，又能够提高单元测试的效率。
public interface IOrderRepository
{
void Add(OrderInfo order);
void Remove(OrderInfo order);
}
public class Order
{
private IOrderRepository m_repository;
public Order(IOrderRepository repository)
{
m_repository = repository;
}
public void Place(OrderInfo order)
{
if (order.Validate())
{
m_repository.Add(order);
}
}
}
利用封装隔离变化，并非必须依赖于抽象，根据不同的场景，降低要求，依赖于较为稳定的具体类对象也是可行的。这是一种降低复杂度的设计方式。例如，我们可以引入一个Helper类来封装第三方API的调用，从而实现调用方与第三方API的隔离。例如为SQL Server数据库操作定义一个Helper类：
public static class SQLHelper
{
public int ExecuteNonQuery() {}
public DataSet ExecuteQuery() {}
}
这样的设计类似于Gateway模式[3]，利用一个Gateway对象来封装外部系统或资源访问。具体类对象显然不如抽象接口稳定，因此在设计时，我们需要遵循单一职责原则。这样的设计体现了DRY[4]原则，利用封装避免代码的重复，避免解决方案蔓延的坏味道[5]。合理的封装可以将变化点集中或限制到一处，以应对变化。一个常见的例子是利用简单工厂模式，将所有对象的创建集中在一个类中（当然也可以按模块创建不同的静态工厂）。即使创建的产品对象发生了变化，我们也可以只修改静态工厂类一处的实现。简单工厂模式常常可以应用在领域层中，通过工厂对象创建持久层对象（或所谓的数据访问对象）。
依赖源于对象的协作。传递依赖的方式可以通过属性，构造函数或方法的参数。若要保证对象间的松散耦合，构造函数或方法的参数以及属性的类型就应定义为抽象类型，如前面例子中的Order类。这是依赖解耦的关键方式，完全符合“面向接口设计”的编程思想，同时，它也有利于我们在后期实现“依赖注入”。
然而，产生依赖的方式绝不仅限于上述三种情形。例如，方法的返回值以及方法体中局部对象的创建，同样可能产生依赖。比较而言，这种依赖关系更难解除，因为它与具体的实现紧密相关。换句话说，因为这两种情形的依赖都涉及到具体对象的创建，且由实现者完成，而不能转交给调用方。例如，在如下的设计中，消息头会决定消息编码的方式。
MessageHeader的GetEncoder()方法需要返回一个IEncoder对象，这就要求在方法体中创建一个具体的IEncoder对象。要解除这样的依赖关系非常困难，如需彻底解除，一种可能是利用反射技术，通过具体类的类型来创建。还有一种可能是利用“惯例优于配置”实现解耦[6]。如果不需要彻底解除依赖，也可以利用“表驱动法”，或者直接将条件分支语句封装到方法中。
如果在方法实现中需要创建一个局部对象，我们可以考虑简单工厂模式或Registry模式[3]。例如，在Role对象的IsAuthorized()方法中，需要创建一个PriviledgeFinder对象，通过调用它的FindPriviledges()方法获得角色对应的权限集。此时，我们可以在Registry对象中提供PriviledgeFinder对象：
interface IPriviledgeFinder
{
IList<Priviledge> GetPriviledges(int roleID);
}
public class PriviledgeFinder:IPriviledgeFinder
{}
public class Registry
{
private Registry()
{ }
private static Registry Instance = new Registry();
protected virtual IPriviledgeFinder m_priviledge = new PriviledgeFinder();
public static IPriviledgeFinder PriviledgeFinder()
{
return Instance.m_priviledge;
}
}
public class Role
{
public bool IsAuthorized()
{
IList<Priviledge> priviledges =
Registry.PriviledgeFinder().GetPriviledges(this.ID);
}
}
上述实现实际上仍然利用了“将变化集中在一处”的设计原则。注意Registry类中的m_priviledge属性是virtual的受保护属性，它提供了一种变化的可能，可以交由子类去实现。
如何知道一个类是否过多的依赖其他类？一个办法就是创建这个类，并保证创建的对象能够正常使用。如果创建的过程非常复杂，就说明该类的依赖过多。此时，可以考虑分解该类的职责。如果这些依赖是必须的，则可以考虑利用封装，例如将对外部对象的调用修改为在内部创建（应用builder模式）；也可以考虑使用Factory Method模式或者利用简单工厂。
依赖关系不仅仅只限于类与类之间，包（组件、模块、层）与包（组件、模块、层）之间同样存在依赖关系。良好的设计需要包之间保持松散耦合。大体上讲，包之间的依赖解除与类之间的依赖解除方式是一致的。即：要求一个包尽量依赖于一个稳定的包。注意，一个包依赖于另一个包，就代表着它依赖于这个包的每一个类。Robert C. Martin说：“我放入一个包中的所有类是不可分开的，仅仅依赖于其中一部分的情况是不可能的。”[7]因此，我们可以将一个包看做是一个类，它仍然要求职责的高内聚。在包中对类的分配，就相当于是对类进行一次分类。共同封闭原则[7]要求：“包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。”简言之，我们在对包进行设计时，需要避免将不同的职责耦合在一个包中，它会造成变化点的扩散。
解除包之间依赖关系的一个重要方法仍然是抽象。使用Seperated Interface模式[3]，在一个包中定义接口，而在另一个与这个包分离的包中实现这个接口。例如在分层架构模式中，我们常常对数据访问层进行抽象，使得业务逻辑层依赖于该抽象层，而不是它的低层模块。
上图的设计实际上是依赖倒置原则的体现。在项目开发中，这种将抽象与实现分别放在不同的包中，是系统设计中常见的方式。这样的设计也能够更好地应用在分布式开发场景中。
[1]单一职责原则（Single Responsibility Principle）：就一个类而言，应该只专注于做一件事和仅有一个引起变化的原因；
[2]依赖倒置原则（Dependency Inversion Principle）：高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象；
[3]Martin Fowler, Patterns of Enterprise Application Architecture；
[4]DRY原则，即“不要重复你自己（Don't Repeat Yourself）”它要求“系统中的每项知识只应该在一个地方描述。”
[5]Joshua Kerievsky, Refactoring to Patterns；
[6]文章《解除具体依赖的技术》
[7]Robert C. Martin Agile Software Development:Principles,Patterns and Practices
- 添加新评论
- 阅读次数：
《编程絮语》之一
C# 的语法脱胎于C++，因而保留了virtual关键字，可以定义一个虚方法（或虚属性）。一个类的成员被定义为virtual，就意味着它在告诉自己的子 类：我准备了一笔遗产，你可以全盘接受，也可以完全拒绝或者修改我的遗嘱。显然，虚方法授予子类的权利甚至大于抽象方法。子类面对抽象方法只有重写 （override）的权利，而对于虚方法，它还可以选择完全继承。
毫无疑问，虚方法破坏了对象的封装性。如果不加约束的使用，会对调用方 造成破坏，至少它有可能破坏子类与父类之间在外在行为上的一致性。因此，当我们在重写虚方法时，务必要遵循Liskov替换原则。我们要保证对于调用方而 言，子类对于父类是完全可以替换的。这里所谓的“替换”，是指子类不能破坏调用方对父类行为的期待。准确地说，子类在重写父类的虚方法时，必须遵循调用该 方法的前置条件与后置条件。这也是“契约式设计”的思想。最理想的状态是让使用对象甚至无法知道是否存在派生类[1]。即类的继承体系对于调用者而言，必 须体现外部接口的一致性，这样才能做到调用者对派生类无知。
如果确实需要重写父类的方法，最好的方式是扩展而不是修改。这实际上也是开放- 封闭原则的体现。例如在Decorator模式中，我们重写父类方法的目的，是为了实现对该方法的装饰。Proxy模式的实现同样如此。Michael C. Feathers对此给出的忠告是[2]：
1）尽可能避免重写具体方法。
2）倘若真的重写了某个具体方法，那么看看能否在重写方法中调用被重写的那个方法。
Feathers 的忠告是针对Java语言，因为在C#中我们无法重写具体方法，只能利用new关键字在子类中新建一个相同方法签名的具体方法，而这样的方法并不具备多态 性。这里涉及到一个有趣的话题，是关于Java和C#的比较。在Java语言中，如果没有添加任何关键字，则方法默认就是虚方法，任何子类都可以重写它。 C#则相反，它对虚方法给予了显式的定义。Java语言的缔造者显然是“性本善”论者，他认为所有子类的实现者均抱着善意的态度来对待父类的方法，因而他 赋予了子类相当程度的自由，但却可能被别有用心者偷偷打开封装的＊＊。如果确有非常重要的隐私防止被篡改，则可以利用final关键字来强制保护。C#语 言的发明者则持有“性本恶”的论调，他恶意地揣测子类总是会不怀好意，所以提供了一套默认的强权，来保护父类的隐私。如果需要对子类开放，则明确地声明为 virtual，这就牢牢地把控制权攥紧在父类的手中。
C#保守的做法使得语言的特质更加安全(当然，Java会更加自由)，我们可以使用 virtual的自由性，搭配方法的访问限制，搭建一个安全合理的白盒框架。virtual关键字的含意本身就是面向子类的，所以，我们应该尽可能地将其 放在protected方法中使用。如果该方法代表的行为确实需要公开给调用者，我们可以定义一个公开的具体方法，在其中调用一个受保护的虚方法。
在Template Method模式中，体现了C#这种划分具体方法和虚方法的好处。Template Method模式要求子类只能部分地替换父类的实现，整个骨架则必须保持固定不变。在父类中，我们将模板方法定义为具体方法，将基本方法定义为抽象方法。 模板方法规定了基本方法的调用顺序，如果我们可以在子类中重写模板方法，就可能破坏基本方法的调用顺序，从而对整个策略造成影响。Strategy模式就 不存在这个问题，因为它的策略是整体的。Template Method模式在模板方法中规定的骨架，实际上就是为调用者制订的前置条件和后置条件。
有 一种说法是不要在虚方法中访问私有字段[3]。这存在一定的合理性。因为一旦我们在父类的虚方法中访问了私有字段，那么在子类重写该虚方法时，由于无法获 得父类的私有字段值，就可能会导致该字段值的缺失。但这种说法并不完全准确。一方面，我们认为Liskov替换原则主要是为了约束Is-A关系在行为上的 一致性[4]，如果该字段对行为不会造成影响，则无大碍。另一方面，这也说明我们在重写虚方法时，最佳实践还是需要在重写的同时，调用父类的虚方法，如 Decorator模式的实现方式。
[1] Alan Shalloway, James R. Trott Design Patterns Explained
[2] Michael C. Feathers Working Effectively with Legacy Code
[3] Dino Esposito, Andrea Saltarello Microsoft.NET Architecting Applications for the Enterprise
[4] Robert C. Martin Agile Software Development:Principles,Patterns and Practices
- 添加新评论
- 阅读次数：
本讲义主要包括以下三部分：面向对象三要素、面向对象五原则和面向对象六视点。面向对象三要素包括：封装(Encapsulation)、继承 (Inheritance)、多态(Polymorphism)。五原则自然是众所周知的OO五原则：单一职责原则、开放封闭原则、Liskov替换原 则、依赖倒置原则和接口隔离原则。前面两部分内容是大多数OO设计都需要掌握的内容，在讲解中虽然加入了我的一些理解，但讲义中并无太多新鲜的东西。最后 一部分则是我这段时间对面向对象的认识与思考，分别包括：复用、扩展、分离、变化、简约和一致。这些内容是我的第二本著作的雏形，当然讲义中展现的内容仅 仅是冰山一角，不过大体框架已经具备了。
讲义下载：OOD.pdf
- 添加新评论
- 阅读次数：
几年前的文字，曾经在我的博客上提供过下载。这些内容可以算是我的书《软件设计精要与模式》的前身。这些文章大体包含了我在前几年对软件设计的思考与经验总结。现在看来，还有一些稚嫩之处，其中还夹杂了一些错误和失误。但总体来说，还是能给人以思考与帮助。所谓“尽信书则不如无书”，无论看谁的著作，还是要报着怀疑的态度去学习，这样才能真正将别人的知识转变为自己的。
- 添加新评论
- 阅读次数：
Mediator模式有一种本事，就是可以让本身需要互相协作的对方，可以不用知道彼此，而把两者之间的联系，转交给Mediator来处理。换句话说，Mediator模式解除了需要互相协调的对象之间的依赖。这也是Mediator（调停者）模式名字的由来。一个颇为形象的例子是＊＊＊。进入＊＊＊的用户总是要彼此通信的，这些对象如果直接进行交互，就会彼此连接，最后织成一张纷繁复杂的大网。要分清彼此之间的关系，真可以说是“剪不断理还乱”了。所以，引入一个＊＊＊对象来管理用户间的交流，就势成必然。
- 添加新评论
- 阅读次数：
Strategy模式是对算法的封装。即使是一个计算行为，如果其实现有其多样性，为达到易扩展的目的，我们也有必要将其抽象出来，以接口的形式来定义。由于充分利用了面向 对象的多态性，在调用该行为时，其具体的实现是在运行期决定的。以税收计算为例，假定税收策略分为个人所得税，和企业所得税。根据策略模式，将税收策略抽象为接口ITaxStrategy：
public interface ITaxStrategy
{
double Calculate(double income);
}
- 添加新评论
- 阅读次数：
面向对象思想为软件设计与开发赋予了哲学的意义。在哲学的世界里，小至沙粒微尘，大至日月星辰乃至宇宙，均可视为单独的个体对象而存在。如果以哲学的目光 凝视程序的世界，又何尝不是如此？一个用户，一种销售策略，一条消息，或是某种算法，一个Web的网页，面向对象思想均将其看作为一种对象。而每一种对 象，都有其单独的生命周期，谁来创建它，谁来销毁它，它的内在属性，表现行为，以及它与外界之间的关系和集合，无不具有某种哲学的意味。我们在定义对象 时，就好比是在描述一个活生生的事物，需要定义该对象的自然属性和社会属性，限定它的内涵与外延，勾勒出该对象的社会关系。而对于抽象、多态与封装，则是 一种形而上学的概念，它将面向对象技术推向为思想的境界。
...
- 添加新评论
- 阅读次数：
1.引言
隐喻思维具有普遍性，是人类认知得以深化的前提之一，隐喻是丰富人类语言的有效手段。
然而，一直以来，对于隐喻的讨论主要限于语言学和修辞学，从而将隐喻狭隘化，局限化，使得隐喻在其他领域中的作用未能得到彰显。美国语言学家莱考夫认为，隐喻不是语言的表面现象，而是一种深层的认知机制，它组建了我们的思维，形成了我们对世界的判断，使语言结构化、系统化，从而具有巨大的生产力。
...
- 添加新评论
- 阅读次数：
分布式处理在大型企业应用系统中，最大的优势是将负载分布。通过多台服务器处理多个任务，以优化整个系统的处理能力和运行效率。分布式处理的技术核心是完 成服务与服务之间、服务端与客户端之间的通信。在.Net 1.1中，可以利用Web Service或者.Net Remoting来实现服务进程之间的通信。本文将介绍一种基于消息的分布式处理架构，利用了.Net Remoting技术，并参考了CORBA Naming Service的处理方式，且定义了一套消息体制，来实现分布式处理。
- 添加新评论
- 阅读次数：
张逸(Bruce Zhang)
