在面向对象的编程语言中，抽象类和接口是并存的两个概念，它们之间有很大的相似性，然而也存在一些区别。简单的概括，从语法上来讲，抽象类是可以实例化的，但是接口不存在实例化的问题。从设计的角度来讲，体现出设计者对于相关问题域的诠释。有的面向对象的编程语言，只支持单继承，但是支持多接口。通过接口的方式可以达到或者实现类似于C++中多继承的机制。

    对于只支持单继承的编程语言，通过抽象类和接口的使用，更能够体现设计者对问题域的诠释。用AlarmDoor（报警门）这一类作例子，将问题域解释为“门，带有报警功能”和“报警器，是个门”在设计的过程中是会有差别的，这种差别可以通过抽象类和接口的应用体现出来。
作为“门，带有报警功能”，一般的做法是将门设计为抽象类，而将报警器设计为接口。门的抽象类中提供开和关两个抽象方法，报警器接口提供报警方法。有人也许会问，为什么不在门这个类中直接声明报警方法，而要费尽周折用到接口。

    现在我们来明确一下这个问题。如果我的门，只有开关两个方法，那么我既可以声明为抽象类，也可以声明为接口，我们知道这两者是有很大的相似性的，问题在于，如果现在我有一个门，它除了具有开关的功能之外，还具有报警的功能。这时，我是要修改门这个类（或者接口），显然这是不符合面向对象的一个核心原则ISP（Interface Segregation Priciple，接口分离原则），把门固有的行为方法和另外一个概念“报警器”的行为混在一起了。这样我们才用到了接口分离，或者通过一个抽象类，或者通过一个接口，我们现在的问题在于是选择抽象类还是接口。

    那么，为什么要将门设计为抽象类，而将报警器设计为接口呢？
    再来看一下我们的问题域，也就是我们是怎么理解这个问题的。这里我们将其解释为“门，带有报警功能”。门具有其固有的方法，比如开、关，我们的“报警门”完全可以继承自这样的“门”类，因为我们至少可以继承自某一个类，很自然地，对于单继承，“报警器”类就只能作为接口出现了。当然，我们也完全可以将“门”设计为接口，“报警门”既实现“门”的接口，也实现“报警器”的接口。然而再一想，我们通常是将“狗”类继承自“动物”还是使用接口呢？

再来看我们对这个问题域的另外一种诠释：报警器，是个门。根据前面的介绍，我们会很自然地想到，我们可以采用继承自“报警器”同时实现“门”接口这样的设计方式。

    至于最终我们采用抽象类还是接口，取决于我们对问题域的认识，也就是具体问题具体对待。很多人都习惯性地认为二者没有多大的区别，哪个好用就用哪个自然也无可厚非。就像有人习惯用结构体，有人习惯用类，我们可能会考虑到结构体作为值类型效率会高一些，类则可以增强扩展性，各有利弊，各有千秋。关键在于我们认识到它们到底是什么，就像英文单词“how”，一见就知道是“怎么”的意思，我们也就没有必要深究为什么三个字母拼起来会表示这样的意思了。。。

在程序世界中，我们经常会用到两个词条来标识变量，即Parameter和Argument。那么，现在的问题是，这两者有什么区别呢？

当我们定义一个方法的时候，括号中期望变量的列表就是Parameter。
我们来看一个例子：
function GetSquareArea(sideLength)
{
return sideLength*sideLength;
}
在上面的例子中，sideLength就是Parameter。

当我们在调用这个方法的时候，会有一个变量传进来，它的值即传入的值，这个变量就是Argument。
例如：
var intSideLength = 4;
var intSquareArea = GetSquareArea(intSideLength);
程序运行的时候，intSideLength会被赋值为4，那么对于方法GetSquareArea的调用，intSideLength就是Argument。

最近在做一个小项目的设计，要求用UML设计类图，不可避免地要应用到设计模式。在没有理论指导的前提下进行设计工作纯粹就是瞎掰，就像做完了数据库的设计甚至用了很长一段时间，然后有人问你说设计的数据库满足第几范式，竟支吾不知所以。良好的设计，无论是从风格的角度，还是从可用性的角度来讲，既需要有理论的指导，也许要有相应的理论来评估。也许有人会提出质疑，做出来能用不就完了，搞那些没用的做什么，试问如果没有理论指导实践，火箭上天的时候你就不怕半道儿掉下来落你头顶上？用词有点儿不恰当，还望海涵！呵呵！

Code in C++ with Factory and Template as follows:(build pass using Microsoft VC++ 6.0)

#include <stdio.h>

class Animal
{
public:
 virtual void SayHello() = 0;
};

class Dog : public Animal
{
public:
 void SayHello();
};

class Pig : public Animal
{
public:
 void SayHello();
};

void Dog::SayHello()
{
 printf("Dog say hello!\n");
}

void Pig::SayHello()
{
 printf("Pig say hello!\n");
}

template <typename T>
class AnimalFactory
{
public:
 static Animal* produce()
 {
  return new T;
 }
};

int main()
{//drive testing
 (new Dog())->SayHello();
 Dog* dog = new Dog();
 dog->SayHello();
 Pig* pig = new Pig();
 pig->SayHello();
 //following objects are generated from template of factory
 Animal* pDog = AnimalFactory<Dog>::produce();
 Animal* pPig = AnimalFactory<Pig>::produce();
 pDog->SayHello();
 pPig->SayHello();
 return 0;
}

通过这样的一段代码，起码我们应当知道，工厂是作为一个基类来产生其下继承它的子类的，也就是说，当我们应用到工厂模式的时候，通常不会直接实例化一个具体的类，而是借助于工厂类来产生需要的对象。

如果接触过Enterprise Library的话，应该知道最常用的一句代码：
Database db = DatabaseFactory.CreateDatabase();//code in C#
这就是一种典型的利用工厂来产生对象的方式。毫无疑问的是，工厂中的方法一般都是static类型的，采用"工厂名.方法名"的形式进行调用。