问题描述
工厂模式抽象出共同的方法,继承接口,反射出对象,执行方法策略模式,抽象出共同的方法,继承接口,context传递继承的类,调用继承类的方法怎么感觉好像啊?为什么会区分成2种设计模式?应用场景的区别是什么?
解决方案
解决方案二：
楼主在哪里知道的这些名词？这些名词能帮你解决什么问题？
解决方案三：
工厂解决的是创建的过程策略解决的是动作更具体的说，工厂是要解决如何创建某个对象，重点在于对象，而策略不关心你对象是怎么创建的，它只关心你传入的对象，它需要用这个对象来解决问题，重点在于解决所以你完全可以用工厂创建对象，然后这个对象作为策略需要的参数
解决方案四：
如果你用.net中的直截了当的术语，根本不需要太多忽悠了。比如说，对象实例是可以动态创建的，例如其本质原型为Dictionary<string,Type>db;stringname;//....vart=(fromxindbwherex.Key==nameselectx.Value).First();varinstance=Activator.CreateInstance(t);
或者比如说，委托实例是可以动态调用的，例如其原型实例为Dictionary<string,Func<int,string>>db;stringname;//....varf=(fromxindbwherex.Key==nameselectx.Value).First();varresult=f(1234);
你可以把这些知识用到需要动态查表去创建不同类型对象或者调用预先注册的委托函数的地方，例如通过配置文件来决定运行时反射执行一些操作。《设计模式》那本书写的年代比较古老，加之作者最初是针对java的，所以技术术语非常贫乏。他们当时还不太懂什么叫做“事件、委托、反射、依赖倒置”等等术语，也没有比较高级一点的编程“语法糖”来让代码写得精简。例如c#中对于Delegate就是个语法糖，编译器自动产生复杂的类型代码、自动实现Invoke等等接口定义方法，但是编程者只用直截了当地一条代码来书写，理解上也容易。而GOF全都用比较雷人的字眼儿来命名了那些模式，也用比较雷人的代码来写那些接口和类型，所以程序员可以用来消磨时光。实际上23种模式，最多有5种就够了。
解决方案五：
引用3楼sp1234_maJia的回复:
如果你用.net中的直截了当的术语，根本不需要太多忽悠了。比如说，对象实例是可以动态创建的，例如其本质原型为Dictionary<string,Type>db;stringname;//....vart=(fromxindbwherex.Key==nameselectx.Value).First();varinstance=Activator.CreateInstance(t);或者比如说，委托实例是可以动态调用的，例如其原型实例为Dictionary<string,Func<int,string>>db;stringname;//....varf=(fromxindbwherex.Key==nameselectx.Value).First();varresult=f(1234);
你可以把这些知识用到需要动态查表去创建不同类型对象或者调用预先注册的委托函数的地方，例如通过配置文件来决定运行时反射执行一些操作。《设计模式》那本书写的年代比较古老，加之作者最初是针对java的，所以技术术语非常贫乏。他们当时还不太懂什么叫做“事件、委托、反射、依赖倒置”等等术语，也没有比较高级一点的编程“语法糖”来让代码写得精简。例如c#中对于Delegate就是个语法糖，编译器自动产生复杂的类型代码、自动实现Invoke等等接口定义方法，但是编程者只用直截了当地一条代码来书写，理解上也容易。而GOF全都用比较雷人的字眼儿来命名了那些模式，也用比较雷人的代码来写那些接口和类型，所以程序员可以用来消磨时光。实际上23种模式，最多有5种就够了。
想补充一下基础知识,所以在看设计模式,不过不去了解原理,只依靠语法糖好吗?另外请教一下,您认为哪5种就够了?引用1楼jhdxhj的回复:
楼主在哪里知道的这些名词？这些名词能帮你解决什么问题？
我在补充基础知识和整理思路引用2楼starfd的回复:
工厂解决的是创建的过程策略解决的是动作更具体的说，工厂是要解决如何创建某个对象，重点在于对象，而策略不关心你对象是怎么创建的，它只关心你传入的对象，它需要用这个对象来解决问题，重点在于解决所以你完全可以用工厂创建对象，然后这个对象作为策略需要的参数
您的看法,是这些没有区别?
解决方案六：
设计模式只是对人们编写的代码形态上的总结，并不具指导意义看看设计模式也没什么坏处，起码你会知道：哦，原来这个还可以那么写