抽象工厂的缺点和解决方法

先上干货，后面才是代码例子：
参考《设计模式之禅》的话“抽象工厂模式是工厂方法模式的升级版本”。其实就是用工厂方法生产具有多维度变化的产品类。什么是多维度的类？即一个类会有多个维度会影响其发生变化。比如下面例子的汽车类，一个维度是牌子，一个维度是型号。（23种设计模式里面还有结构型的桥接模式和行为型的访问者模式，也可以用来处理多维度类的问题）
我们知道，抽象工厂最大的缺点是产品族难以扩展。那么应该怎么解决这个问题呢？为什么下面例子中我要用型号这个维度作为抽象工厂的接口呢？
GoF里面提供了一种解决方法：一个更灵活但不太安全的设计是给创建对象的操作增加一个参数。该参数指定了将被创建的对象的种类。它可以是一个类标识符、一个整数、一个字符串，或其他任何可以标识这种产品的东西。
其实就是把判断逻辑集中到了工厂类，它自己也说了，这样做其实抽象工厂里面只需要一个方法make(typy)即可，make的实现根据传进来的type判断生产哪个产品。我认为这不是一个好的解决方法，它会使工厂类的判断逻辑越来越庞大，违反了单一性原则，再说这已经不是抽象工厂模式了。
让我来回答这个问题，要考虑两个点。第一是产品的扩展性，第二是需求的变更性。
前者指的是这个多维度的产品类一般会向哪个维度扩展，即哪个维度是相对稳定的，哪个维度是相对异变的。一般情况下选择稳定的维度作为抽象工厂的接口。举《设计模式之禅》里面的例子：女娲造人。这里的人有两个维度——性别和肤色。我们知道，性别这个维度是稳定的：男、女或不详（就算有第三种性别）。所以应该把性别这个维度作为抽象工厂的接口，这样就可以从容应对肤色的变更。（《设计模式之禅》里面把肤色作为抽象工厂的接口了，我认为是不妥的）。
后者考虑的是客户端的需求变更问题，就像代码里的例子。假设现在公司跟宝马公司决裂了，董事会决定全公司不用宝马车，跟奔驰公司签了新约换奔驰。好，这时只要在客户端代码的1处更换具体工厂即可：CarFactory factory = new BenzFactory()，后面的业务逻辑代码无需变动（这点与策略模式的功能有点像）。方便！
那么怎么衡量这两点呢？
我觉得应该优先考虑第二点，因为客户的需求才是最重要的。但如果在需求不明确，只是设计一般的API的情况下，就要考虑第一点了，如果是这样，例子中就要以牌子作为抽象工厂的接口了。因为一般情况下汽车牌子是稳定的，型号是不断更新的。举个生产手机的例子，假设富士康签了长期合同为两家公司࿰