其中提到:
...让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。
这时我们就需要Factory工厂模式来生成对象了,不能再用上面简单new Sample(参数)。....
我认为工厂模式与被创建对象的构造函数做多少工作没有多大关系。最简单的例子:
Factory类的片断
|
这时候,我们仍然可以在SampleA的构造函数中做很多事情,情况如下:
|
希望banq能不厌其烦为学生指点一二,谢谢。
其中提到:
...让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。
这时我们就需要Factory工厂模式来生成对象了,不能再用上面简单new Sample(参数)。....
我认为工厂模式与被创建对象的构造函数做多少工作没有多大关系。最简单的例子:
Factory类的片断
|
这时候,我们仍然可以在SampleA的构造函数中做很多事情,情况如下:
|
希望banq能不厌其烦为学生指点一二,谢谢。
这两种定义应该分派,分别封装在不同class中。
实现接口中定义的方法的同时增加一些特殊的方法
继续我们的假设,通常一个人初始化是2条腿,但是不幸的是,我们这里的man由于先天不足,初始化时候只能是1条腿,那么我们就要在构造子中写入:
this.leg = 1;
当然,这个过于绝对的例子并不能很好的表达我的意思,但是,我依然认为,对构造函数的改造不应属于使用factory这个模式所带来的影响。
如果可以(当然这样做并不很好)
那么,工厂模式与简化构造函数所作的事情又有什么关系呢?我认为工厂模式仅仅是以取代通常的new关键字而引发的一种设计模式,它的目的在于尽可能少的修改代码而为系统添加新的功能。SampleA和SampleB是工厂模式的两个具体产品,他们在实现或继承接口类或抽象类的同时理应有属于自己的实现方法,哪怕部分操作是写在构造函数中,工厂并不关心产品的这些方方面面,它唯一关心的是它能产生什么样产品(例如,在静态工厂模式中,我们需要在工厂类的方法中写明return new ...)。你说呢?
如果是一些简单赋值,如this.a = a ,就无需使用Factory. 总之,如果你的构造函数变得复杂了,那么就要重整(refactor)到Factory模式。
放入工厂类或抽象产品类还是具体产品类?疑惑中
也就是说forum是自己从数据库中产生的!?