先是大概看了下,介绍工厂模式的篇幅有些略长啊,有些不太愿意看了。
在书中先是介绍了“简单工厂”,就是利用一个方法生成实例对象,在别的语言中通常用静态实现,在OC中往往是利用+标识的类方法实现,简单的理解就是避免用new生成实例的方法。直接用类方法进行生成新当前类实例的方法被书中介绍成“简单工厂方法”。
根据书中的定义:
通过让子类决定该创建的对象是什么,来达到将对象创建的过程封装的目的--------工厂方法模式
如果按照该定义作为正确评判工厂方法模式的正确准则的话,我们用+标识的方法,仅仅是类方法,并非是某一种设计模式,并且书中介绍简单工厂模式仅仅是大家约定俗成的一种书写习惯,谈不上是什么模式。
但是核心思想都是我们调用直接调用一个方法去生成实例,相比我们直接使用new 进行实例化有什么好处呢?
好处就是 我们可以更改这个方法的具体实现,并且不会更改原有调用方的代码逻辑,这也体现了封闭的原则,我们可以在该方法中实例化出对应的子类,也就是调用方从来不关心具体是哪个实例,只要我能调用出对应的方法就好。利用多态,做到更改函数的具体实现,而这样做的一切,都不会影响调用方--------即调用方可以不更改任何代码,仅仅更改工厂函数(瞎起的名,懂这个意思就好)具体生成子类的策略,就能实现处理不同场景的功能,这样的一切更改对于调用方 都是无感知的。
OO的封装、继承、多态思想还需要加强,多态的影子中在设计模式中太常见了。
值得注意的是,在我当初学这个模式的时候有些想不通的是,直接在我们直接在调用类的等号左边直接用父类,等号右边直接实例化子类不也是达到了同样的效果么?调用方的代码就也就改了一处,后来发现这种想法是略傻逼的。在代码实现上判断耦合程度最简单的方式就是看#import引入的类是否多,如果引入过多的类则证明改类会和很多类都有联系,即和很多类存在耦合,如果按照刚才方式,做了一件事不仅引入了父类也引入了子类,相比别人做一件事只引入一个类是不是办的优点傻逼呢?
所以具体的实例化过程还是都放在工厂方法中实现比较稳妥,这样调用方仅仅引入父类即可,而且一行代码都不用更改!
尽量以后设计的时候,尽量多考虑依赖接口,而不是依赖实现编程,这是为了以后即使需要变动,尽量保证变动较少的原则。这些目前看都是简单工厂所做的,工厂模式 目前还没真理解,只是有点模糊的理解,属于半吊子阶段中。
一个正式的工厂方法模式的介绍:
定义一个创建对象的接口,但由子类决定要实例化的类是哪一个,工厂方法让类吧实例化推迟到子类。
就是用方法封装了实例化的过程,调用方都会当作父类去使用,而实际实例了哪个类都是由工厂函数决定了。