关于抽象工厂的问题

抽象工厂也就是创建很多产品时候用。
但是在这个抽象工厂类中也就是是定义了每个产品创建的方法返回的接口，比如
FactoryDB{

public A getDB();
public B getDB2();
...
}
我在想，每个具体产品类里继承他，跟不继承他，有什么区别，不继承的时候每个产品的工厂里还是返回A或B这类接口，继承了还是返回这个，我实在想不出抽象工厂好在哪里，请指点。

>不继承的时候每个产品的工厂里还是返回A或B这类接口
不继承A或B如何返回接口A或B?

比如我有个车子的工厂，和一个车的接口,一个bigcar,smallcar类实现了这个接口,
CarFactory{

public ICar getClass(String str)
{
if(str.equals("big"))
return new bigcar();
else if(str.equals("small"))
{
return new smallcar();
}
else ....
}

}

这样没有抽象工厂也一样的啊，如果还有其他产品，如果水果，。。。那么我也像上面一样建立工厂，接口一样能实现，也没有用到抽象工厂啊。那有了抽象工厂的好处又是什么呢。

其实我的意思就是，我在抽象工厂里定义了两个创建方法，一个方法返回类型是ICar,一个是IComputer，如
public Icar createCar();
public IComputer createComputer();

那么我如果还想加入其他产品的话，我不仅要改变这类，还要改变其他继承这类的工厂。等等。。不是很麻烦。。？？

"还想加入其他产品？"
你是想增加新的接口吗？每个模式都有其限制前提，抽象工厂也是。

如果你的接口设计具有一定抽象性，增加其它产品只是增加子类而已。

simple factory 有面象过程编程的味道, 它的确可以完成fatory的功能, 我们以前也是这样做的. It works. 但太多的判断语句,我实在不敢说是一种好的方式. Factory method和abstract factory消除了判断语句, 我们只需要在实例化的时候, 实例化我们想要的工厂子类, 由这个工厂子类中不同的方法得到不同的production. 整个过程是面向接口的, 面向接口的理解在于个人对面向对象编程的理解程度.当你意识到它的好处时, 你的OOP就上了一个层次.

另外, 在设计模式中消除判断语句的模式有: State, Visitor. 当然严格来说, 我觉得很多模式都可以做到这一点.