06模式与框架它们的关系与误区.pdfVIP

2018/8/15 极客时间 | 程序员进阶攻略 无须再重复相同的工作。 而《设计模式》一书借鉴了建筑领域的定义和形式，原书中是这么说的： 本书中涉及的设计模式并不描述新的或未经证实的设计，我们只收录那些在不同系 统中多次使用过的成功设计；尽管这些设计不包括新的思路，但我们用一种新的、 便于理解的方式将其展现给读者。 虽然该书采用了清晰且分门别类的方式讲述各种设计模式，但我相信很多新入门的程序员在看完 该书后还是会 像我当年一样有困扰，无法真正理解也不知道这东西到底有啥用。 早年我刚开始学习 Java 和面向对象编程，并编写 JSP 程序。当我把一个 JSP 文件写到一万行代 码时，自己终于受不了了，然后上网大量搜索到底怎样写 JSP 才是对的。之后，我就碰到了 《设计模式》一书，读完了，感觉若有所悟，但再去写程序时，反而更加困扰了。 因为学 “设计模式” 之前，写程序是无所顾忌，属于拿剑就刺，虽无章法却还算迅捷。但学了 一大堆 “招式” 后反而变得有点瞻前顾后，每次出剑都在考虑招式用对没，挥剑反倒滞涩不 少。有人说：“设计模式，对于初窥门径的程序员，带来的麻烦简直不逊于它所解决的问 题。”回顾往昔，我表示深有同感。 后来回想，那个阶段我把《设计模式》用成了一本 “菜谱” 配方书。现实是，没做过什么菜只 是看菜谱，也只能是照猫画虎，缺少好厨师的那种能力——火候。初窥门径的程序员其实缺乏 的就是这样的“火候”能力，所以在看《设计模式》时必然遭遇困惑。而这种“火候”能力则源 自大量的编程设计实践，在具体的实践中抽象出模式的思维。 “设计模式” 是在描述一些抽象的概念，甚至还给它们起了一些专有名字，这又增加了一道弯 儿、一层抽象。初窥门径的程序员，具体的实践太少，面临抽象的模式描述时难免困惑。但实践 中，经验积累到一定程度的程序员，哪怕之前就没看过《设计模式》，他们却可能已经基于经验 直觉地用起了某种模式。 前面我说过我刚学习编程时看过一遍《设计模式》，看完后反而带来更多的干扰，不过后来倒也 慢慢就忘了。好些年后，我又重读了一遍，竟然豁然开朗起来，因为其中一些模式我已经在过往 的编程中使用过很多次，另一些模式虽未碰到，但理解起来已不见困惑。到了这个阶段，其实我 已经熟练掌握了从具体到抽象之间切换的思维模式，设计模式的 “招数” 看来就亲切了很多。 在我看来，模式是前人解决某类问题方式的总结，是一种解决问题域的优化路径。但引入模式也 是有代价的。设计模式描述了抽象的概念，也就在代码层面引入了抽象，它会导致代码量和复杂 度的增加。而衡量应用设计模式付出的代价和带来的益处是否值得，这也是程序员 “火候” 能 力另一层面的体现。 /column/article/13294 2/5 2018/8/15 极客时间 | 程序员进阶攻略 有人说，设计模式是招数；也有人说，设计模式是内功。我想用一种大家耳熟能详的武功来类 比：降龙十八掌。以其中一掌“飞龙在天”为例，看其描述： 气走督脉，行手阳明大肠经商阳…此式跃起凌空，居高下击，以一飞冲天之式上 跃，双膝微曲，提气丹田，急发掌劲取敌首、肩、胸上三路。 以上，前半句是关于内功的抽象描述，后半部分是具体招数的描述，而设计模式的描述表达就与 此有异曲同工之妙。所以，设计模式是内功和招数并重、相辅相成的 “武功”。 当你解决了一个前人从没有解决的问题，并把解决套路抽象成模式，你就创造了一招新的 “武 功”，后来的追随者也许会给它起个新名字叫：某某模式。 开发框架 不知从何时起，写程序就越来越离不开框架了。 记得我还在学校时，刚学习 Java 不久，那时 Java 的重点是 J2EE（现在叫 Java EE 了），而 J2EE 的核心是 EJB。当我终于用“JSP + EJB + WebLogic（EJB 容器）+ Oracle 数据库”搭 起一个 Web 系统时，感觉终于掌握了 Java 的核心。 后来不久，我去到一家公司实习，去了以后发现那里的前辈们都在谈论什么 DI（依赖注入）和 IoC（控制反转）等新概念。他们正在把