google的结果:
策略模式:定义算法族,分别封装起来,让他们之间可以相互替换,此模式让算法的变化独立于使用算法的客户。
简单工厂:将对象的创建完全独立出来,让对象的创建和具体的使用客户无关。
简单工厂严格意义上不是一种设计模式,只能是一种良好的编程习惯。
里面还特意说了,(Strategy 适合下列场合: 1.以不同的格式保存文件;)
我现在就要做文件的下载,csv xml pdf xls 四种格式。
使用工厂模式:
客户端类+工厂类+接口类+4个具体实现类 总共7个类
使用策略模式:
客户端类+调用那个接口的类+工厂类+接口类+4个具体实现类 总共8个类
而且也没发现策略比工厂哪里更好一些。。。谁来帮忙解读一下啊?谢谢啦~~
你这两个方法有什么区别呢?
差的就是那个“调用那个接口的类”。
方法一与方法二都是用工厂生产策略,有什么实质的区别吗?
方法二只是客户端把调用委托给了另一个类,有时候这是个好的设计,但你真的需要如此吗?
策略模式能和工厂模式区别开来吗?一个注重对象的行为,一个注重对象的创建,有区别的必要吗?
都一样 封装变化:)
代码层次上似乎没啥区别,区别在语义和使用场景上。
这个,你可以用工厂生产策略,但是两者不是一回事吧?
google的结果:
策略模式:定义算法族,分别封装起来,让他们之间可以相互替换,此模式让算法的变化独立于使用算法的客户。
简单工厂:将对象的创建完全独立出来,让对象的创建和具体的使用客户无关。
简单工厂严格意义上不是一种设计模式,只能是一种良好的编程习惯。
里面还特意说了,(Strategy 适合下列场合: 1.以不同的格式保存文件;)
我现在就要做文件的下载,csv xml pdf xls 四种格式。
使用工厂模式:
客户端类+工厂类+接口类+4个具体实现类 总共7个类
使用策略模式:
客户端类+调用那个接口的类+工厂类+接口类+4个具体实现类 总共8个类
而且也没发现策略比工厂哪里更好一些。。。谁来帮忙解读一下啊?谢谢啦~~
一个可能的实现应该是这样的吧:
class StrageFactory{ public IOutputStrage produce(string _type){ balabala } } interface IOutputStrage { public void output(OutputStream ...); } class CSVOutput impletes IOutputStrage; class XMLOutput impletes IOutputStrage; ...... class Downloader{ public void run(_type){ ...... StrageFactory.produce(_type).output(..); } }
简单工厂严格意义上不是一种设计模式,只能是一种良好的编程习惯。
这句话怎么说?什么叫严格意义上不是设计模式?“严格意义上”的设计模式是什么样的?
不严格的说,所有的模式,斗不过是一种良好的编程习惯。甚至OO本身也不过如此。