宅男程序员给老婆的计算机课程之5:设计模式

原创
开发
这个系列来自一位宅男程序员,这个系列是他写给老婆的电脑课程。以下,开始本系列的第6篇——设计模式。而实际开发中常用的设计模式更是屈指可数,Singleton,Factory,Facade,Active Record、Provider等等。

设计模式,应该是很多ED心目中牛B的编程方式。

上回说到ED的好书POEE,实际上便是一本专门讲企业开发中使用的设计模式中的书。

设计模式,并不多,基本上看完GoF的这边《Design Pattern》便可以有足够了解了。

而实际开发中常用的设计模式更是屈指可数,Singleton,Factory,Facade,Active Record、Provider等等。

就那么几个,花花功夫,仔细了解一下这几个,然后在实际编码中应用一下,便可以算是掌握了。

设计模式,并不难。

它是开发中非常必要的知识,实际上,是非常基础的知识,并不牛B。

开发的时候,需要时刻明确自己的目标:解决问题。

解决问题才是最重要的。

设计模式的存在,是为了更好的维护、管理代码,或者是为了扩展性;绝对不可以为了设计模式而模式。

在Java程序中,为了模式而模式的现象蛮普遍的。

我猜想这是因为Java是一门工业语言,有大量的ED使用的缘故。

ED把设计模式的使用,当成是一种可以炫耀的编程技巧,或者说,他们遵从的编码规范中,要求他们去使用某某设计模式。

至于为什么要使用设计模式,最常见的理由便是:为了将来可以XX,或者YY。

程序开发中,有一句名言:“Pre-mature optimization is the root of all evil”。

过早优化,是万恶之源。

非常多的情况下,将来预想中的XX或者YY;并不会发生。大部分代码,写了之后就会被丢弃掉,再也不会有人去维护。

当XX或者YY发生的时候,往往,都是会推倒重来。

除非你很牛B,只有牛到一定程度,才有可能对将来可能发生的情况做好合理的预测,并预留出改善、调整的空间。

但非常讽刺的是,为将来做设计的最好方法就是:什么都不做。

只有空白,才能够留下最大的发挥空间。

现在为将来可能发生的情况,做了编码,任何一行编码,都是很可能是在为将来添加限制、制造麻烦。

现在写下去的代码,将来,都是要被删掉的;能够不写,就不写。

在任何时候,都应该保持代码简洁。

函数,尽可能的短;当一个函数的长度,超过一个屏幕的时候,便应该考虑重构、拆分。

牛B的程序,都应该是简单、易懂的;采用大量的设计模式,复杂得让人无法直接看懂,或许有它的意义以及应用场景,但这绝对不是编程功力牛B的表现。

打个比方,设计模式就是武术招式。

学徒,必然需要熟悉什么“有风来仪”或者“屁股朝后平沙落雁式”。

但更高的境界是:无招胜有招。

简单、直接的把代码搞定。

Python大牛沈崴有云:“得道的程序员,既不封装,也没有重复代码。”
http://eishn.blog.163.com/blog/static/6523182010102342531684/

作业

1. 使用一种编译语言实现 Singleton 模式

2. 使用一种动态语言实现 Singleton 模式

3. 说说对 Provider 模式的理解。

男主角:Wuvist(新浪微博),真名翁伟,自称胖程序员一个,幸好已婚。学习.NET出身,现常用Python做服务器端开发,曾任新加坡某创业公司主程。公司被Techcrunch blog过后,觉得新加坡生活太过安逸,终于在去年辞职只身回家乡汕头创业,活跃于珠三角技术沙龙,热衷于与其他技术宅分享。

[[58036]]

本文作者:Wuvist

女主角:Katze,Wuvist的老婆,女程序员,在某跨国投行任Unix系统管理员,常被Wuvist嘲笑技术太差。

[[58037]]

51CTO系列:

  1. 宅男程序员给老婆的计算机课程之0:认清本质
  2. 宅男程序员给老婆的计算机课程之1:认清实际
  3. 宅男程序员给老婆的计算机课程之2:怎么看待牛人
  4. 宅男程序员给老婆的计算机课程之3:架构比较
  5. 宅男程序员给老婆的计算机课程之4:SQL vs NoSQL
责任编辑:彭凡 来源: 51CTO
点赞
收藏

51CTO技术栈公众号