批判工厂方法模式

之所以取这个标题，纯粹是为了吸引眼球,:)

本人没用过patterns，没有实践经验，所以特来问一个问题。
工厂方法模式中，有两个类体系，一个是产品类体系，如IProduct、ConcreteProductA、ConcreteProductB、ConcreteProductC，具体产品类全部实现IProduct接口。另一个是工厂类体系，如IFactory、ConcreteFactoryA、ConcreteFactoryB、ConcreteFactoryC，对应的具体工厂类用于“生产”对应的具体产品类。

在使用时我们一般这样写：
IFactory f = new ConcreteFactoryA();
IProduct p = f.CreateProduct();
p.ExecuteFunction();// 客户代码中使用IProduct所提供的功能。

如果出现了新品种的产品，我们就先建立新产品及其对应的工厂类，然后这样修改使用代码：
IFactory f = new ConcreteFactoryD();// 仅改这一个地方
IProduct p = f.CreateProduct();
p.ExecuteFunction();

客户端代码虽然不再对具体产品类产生依赖了，但却对具体工厂类产生依赖了。

假设我们不用工厂方法模式，则这样写代码：
IProduct p = ConcreteProductA();
p.ExecuteFunction();
显然，不用工厂方法模式的代码少了一行。请教各位，工厂方法模式给我带来的好处什么？难道是多写了一行代码？

如果让 客户端代码 对 具体产品类和具体工厂类 均不产生依赖，而是依赖于抽象产品类和抽象工厂类，这样在更换具体产品类时客户代码就不用修改。如果语言平台提供了反射功能，可以将客户代码的修改转换为配置文件的修改：
IFactory f = (IFactory)Assembly.Load(“AssemblyNameFromConfig”).CreateInstance(“ConcreteFactoryA”);
IProduct p = f.CreateProduct();
p.ExecuteFunction();// 客户代码中使用IProduct所提供的功能。

假设我们不用工厂方法模式，则这样写代码：
IProduct p = (IProduct)Assembly.Load(“AssemblyNameFromConfig”).CreateInstance(“ConcreteFactoryA”);
p.ExecuteFunction(); // 这种用法是不是就是provider model？
显然，用工厂方法模式的代码还是多写了一行，请教各位，难道这是工厂方法模式给我带来的好处？这里是不是基于抽象编程即可？我感觉自己没有找到真正使用工厂方法模式的场景，请大家帮我找一找。