设计模式什么的哪有那么神秘 ----第三集 建立延后

上一集咱们聊了设计模式中对于函数参数传值使用的一些有意思的地方.那么今天,咱们来聊一聊设计模式中对于函数返回值有哪些有意思的运用.

设计模式中,有一个很常见的思想,就是"让建立操做延后".

表明模式首先就是工厂系列三大模式.这里只讨论简单工厂模式.

为何要让建立操做延后?

设计模式对于编程最大的贡献,或者说它宣扬的是让程序架构灵活,拥抱变化.

假设我如今须要操做A对象

通常状况下

A a = new A(); 或  Ia a = new A();//Ia表明A类的接口或抽象,推荐用接口的方式声明.

当咱们写完功能之后,发现功能并非很好.咱们从新写一个A2的类,处理方式比A类要好用.

而后咱们须要把程序代码中全部对A的操做改为A2.这是多么大的工做量啊.若是没有IDE帮助,根本不可能完成.

要知道,加班都是自找的.

咱们能够这样处理

Ia a = createA();//经过调用一个函数实现得到a的实例.

当咱们需求再发生更改的时候,只须要改一下函数内的具体实例化就能够了.

并且,creatA函数内部也可使用反射来实现动态返回想要的类.

这其实就是工厂系列模式中最核心的韵味.虽然工厂方法和抽象工厂在此基础上进行了抽象和封装的扩充.

写到这里我想起了一篇小文章.

当我在大学的时候，我选了一门“高级”面向对象编程课程。之前历来没有接触过这种知识，这个课程使用SmallTalk这种语言教学，并且教学方式很是特别；第一天，教授给咱们布置了一个将会贯穿整个4周课程的做业。

咱们很是兴奋，由于这是要编写一个游戏。一个老式的文字输入式的冒险游戏，相似于Zork风格。咱们分红3人一组，来到教授拥挤的小屋里。在那里，教授给了咱们一页纸，上面写着一些说明。从那里返回时咱们几乎是一路小跑。

而就在咱们刚要出门时，教授把咱们叫了回去(我相信他是特地选了这个最佳时机)：

“哦，我差点忘了。两个星期后，我会对这个游戏内容作一些大的修改。大家要继续按修改后说明开发。”

我跟不少的软件开发团队(包括一些软件产品创始人)说过这个故事，他们的反应几乎都同样：

你能在屋里听到笑声。至少是咯咯的笑。常常你还能一些“不会吧”等话
“哦，老兄，这也太没谱了吧！”
“这教授这么难为人吗——怎么可能有这样的任务”
问题就在于，教授并无告诉他将会作什么样的修改。只是说会修改一些东西——两周后。

你认为咱们该如何去完成这个任务？

咱们开发时到处设防。

“哦，不行——若是教授打算改动这个怎么办？”
“也许应该把这里作成接口——万一教授要求用不一样的方式实现它呢？”
“不行——咱们应该把这部分提取出来，这样，当咱们修改这部分时就不须要改动模块X了”
这就是咱们的作法。我最想说的是，这是一个很是好的做业任务，它让我在面向对象编程和Smalltalk方面学到了不少。感谢你，咱们的Davidson教授！

最终，咱们作成了一个很是模块化的系统，这使对它们的修改变得很容易。当那一天终于到来，当游戏设计被修改后，咱们经过努力在一天内就按照要求修改了程序，使咱们能顺利的接着开发界面和怪兽等很酷的部分。

咱们为之后的改变而优化系统。由于Davidson教授告诉咱们变化很快就会来到。

不少程序员抱怨客户需求不断变化,老板今天让改这个明天让改那个.其实在你踏入行业第一天,你就应该意识到也许需求下一秒就会变化.所以在设计的时候,为变化留下后路.甚至说赶在客户/老板以前意识到变化,并做出调整.没有人怀疑程序员是一批聪明的人.那么你只要用心,必定能发现变化.运用设计模式拥抱它.