如何让代码高效优雅可复用？学习设计模式是最佳捷径

hwyzw

    如何让你的代码高效、优雅、可重用？除了不断迭代之外，学习设计模式是最好的捷径。

    在工作中，你可能经常会发现很多人把大学里学到的Java设计模式、高等数学、编译原理当成脱离实际工作的知识。

    但无论是面试还是实际工作，你是否经常听到资深专家给你“洗脑”，说设计模式很重要？你可能为此购买了书籍或参加过培训，但往往是因为应用效果不佳。从一开始你就非常重视，后来逐渐习惯性的忽视了。最终，它在你心中的重要性可能不如明天那么重要。需要异花受精。

    相信我，你并不孤单。

    过去很长一段时间，我和大家一样，内心反复挣扎，在学与不学的矛盾中徘徊，时不时还存在以下困惑：

    工作多年后回过头来看，发现当时的困惑的关键并不是设计模式太抽象或者难以应用，而是我可能没有从设计模式的范围和背景来理解。开头：设计模式解决了什么问题？为什么要抽象这样的场景呢？如何解决这些问题呢？

    关于设计模式的常见误解

    正是因为我们不了解这些应用的范围和背景，所以很多时候我们总是“抄袭”设计模式，以为自己在应用设计模式，殊不知我们之前一直在误解设计模式我们甚至开始了，而且我们是无法控制的随机性。最终带来了很多不必要的麻烦。

    因此，想要学好设计模式，就必须破除这些误区。

    误区一：经典模式太抽象，难学

    说起设计模式，你的第一反应会不会想到“四人帮”GoF的那本“经典”书籍《设计模式：可复用面向对象软件的基础》？或者想想那 23 种“经典”模式？

    确实，设计模式太经典了，但经典也带来了一个问题：太抽象，难以快速理解。而对于没有太多闲暇时间的你来说，阅读抽象经典更是难上加难。

    例如，下面是《设计模式》一书中对访问者模式的使用场景的描述：

    一个对象结构包含许多具有不同接口的类对象，并且您希望对这些对象执行一些依赖于其特定类的操作。

    需要对对象结构中的对象执行许多不同且不相关的操作，并且您希望避免这些操作“污染”对象的类。这允许您集中相关操作并在类中定义它们。当对象结构被许多应用程序共享时，使用模式允许每个应用程序仅包含它需要的操作。

    定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。更改对象结构类需要为所有访问者重新定义接口，这可能成本高昂。如果您的对象结构类经常更改，那么最好在这些类中定义这些操作。

    你会发现，即使读得很仔细，你还是似懂非懂。看起来好像可以结合实际场景，但是到了实际设计编码的时候，你发现无从下手。为什么？

    最关键的是，当你面对真实的业务需求时，如何快速选择最合适的设计模式？这个问题仍然没有答案。

    其实，经典之所以过于抽象，是因为它所蕴含的知识密度太高，需要时间来破译。比如，在实际业务中，我们其实更关心的是：设计模式如何实现？不同设计模式之间有哪些共性和独特性？有没有真实的代码示例？也就是说，我们首先要弄清楚设计模式能够解决哪些范围的问题，然后才能正确使用设计模式。

    其实设计模式最初提出的时候就说过了，就是《设计模式》这本书的副标题：可重用面向对象软件的基础。设计模式解决的是“可重用”的设计问题，而可靠性设计、性能设计、安全设计、可服务性设计等是设计模式无法解决的。

    简单来说，设计模式是从不同项目中总结出来的通用经验，帮助我们快速理解现有系统并找到共同规则。如果没有足够的经验或思考，很容易引入错误的设计，造成更多的麻烦。

    所以，“经典太抽象”只是一个事实。只要你肯花时间仔细解读，学起来并不难。

    误区二：设计模型过于单一，复杂业务场景难以落地。

    现在，关于设计模式有两个非常有趣的现象。

    其实这个冲突的关键点在于设计模式解决的问题范围不明确。也就是说，设计模式并不是全场景的解决方案，需要考虑其适用范围。

    例如，在面向对象语言Java领域，如何最大限度地发挥面向对象语言的继承与结合的威力？如何解耦程序之间的依赖关系？设计模式将提供一些答案。

    如果您现在接到一个复杂系统的设计任务，比如如何设计闪购系统？你不仅需要关心业务功能的实现，还需要关心不同开发成员之间的相互配置、服务器资源等，这时候你就想到了设计模式中的适配器模式、策略模式、状态模式... 对你来说帮助并不是那么明显，因为你实际上还没有达到需要如此详细实现的阶段。

    事实上，设计模式是为了解决有限领域的有限问题而提出的。比如非业务场景的技术框架如何实现软件的可复用？如何才能提高更多人的编程效率？事实上，在Netty、Java、JDK等广泛认可的工具中，设计模式的应用随处可见，但同时又不仅仅是设计模式本身。

    因此，你不能把设计模式当作一种通用的解决方案，或者认为它应该解决超出其范围的问题。必须考虑它的适用范围，否则问题将无法得到有效解决。

    误区三：既然模式有用，那么一切都是模式

    例如，你可能会说：

    以上其实都是“欲望思维”，逻辑上都是错误的。

    Java设计模式原本是从不同编程项目中总结出来的通用经验。它们是现有的既定事实，可以解决许多工具、组件和框架的重用问题。比如你经常使用的框架中，从工厂模式、原型模式，到代理模式、门面模式、观察者模式等等，在它们的源码中你随处都可以看到它们的身影。

    因此，很多人认为编程时应该处处使用模式，并且使用的模式越多，设计就越好。其实，好的设计从来不在于使用了多少模式，而在于如何合理运用模式的设计思想，如何利用模式来解决实际问题。

    例如，当我负责一个网关系统时，我就陷入了“模式综合症”。当时我就一直在思考各种模式如何使用。即使是一个小的过滤规则模块，我也想知道是否可以使用。责任链模型，但实际上这个需求可以通过简单的白名单来解决。最终的结果当然是代码变得更加复杂和难以维护，导致大量的重构和沟通工作。

    所以，学习设计模式是为了启发我们的思维，而不是“手里拿着锤子，满世界找钉子”。

    如何正确学习设计模式

    设计模式真的不好用吗？或者它已经成为过去式了？其实争论的焦点不应该是设计模式本身是否有用，而是我们是否有正确的学习方法和应用设计模式的思维模式。

    那么如何让经典真正为我所用呢？有四种非常简单的方法。

    首先，我们要端正心态。设计模式不是万能药或灵丹妙药。设计模式能解决的问题其实是有限的。你应该始终保持正常的心态，正确分析设计模式能解决和不能解决的问题。不过，虽然模型解决的问题有限，但它可以激发你的想象力和灵感，获得更多有用的信息来解决更多的问题。总之，放弃争论设计模式的用处，多花点时间去学习和实践，不要总是不加思考就想着使用。

    其次，了解设计模式的背景知识。例如，设计模式是如何定义的？设计模式的历史演变和变化？设计模式适用于哪些领域？哪些领域不适用？如何结合实际分析和使用？在学习一门学科时，如果总是忽略相关的背景知识，久而久之就会养成零碎知识积累的习惯——收集的信息很多，但拆解和吸收的却很少。在学习相关知识的时候，你会发现原来的知识会逐渐串联起来，串联起来。这是一个事半功倍的举动。

    再次，努力拥有作为主人独立思考的习惯。互联网时代，不缺信息和方法，缺的是能解决复杂问题的高手。大师之所以成为大师，是因为大师不拘泥于某一知识的高低，而是保持明智的判断，始终朝着坚定的目标前进。你身边一定有这样的隐藏高手。他们在面对复杂的问题时，始终能够保持清醒的头脑、谦虚的态度以及独立思考的习惯。你应该向他们学习更多。同样，你也需要花时间去刻意练习，通过失败和挫折来探索自己真正的能力，并以此不断增强自己的能力。

    最后，从现在开始，坚持下去。学习技术知识并不比读文学小说好。你需要面对比较枯燥的业务场景，有时还需要做一些你可能不喜欢的重复性工作。但只有坚持，才能成长和发展自己真正的能力。很多时候我们更容易半途而废，但如果你想突破瓶颈、提升能力、升职加薪，如果你不付出努力，你可能无法抓住机会来临时。所以，不要半途而废，要坚持下去。

    总结

    请记住：设计≠编码，愿望≠事实。

    不要看源码很多年，工作做了很多年，还是不能很好地设计和编码。当你知道了很多“如何”时，你还必须更多地思考“为什么”和“什么”。

    学习设计模式的关键不在于你掌握了多少设计模式，而在于你是否能够真正灵活地运用它们来解决更复杂的现实问题。例如，在构建API网关时，是否可以借鉴模式或模式？在设计数据分析应用程序时，您能否避免设计模式并专注于数据分析本身？

    另外，当你学习设计模式时，不要太关注“无用”，而应该发现更多“有用”的地方，并让这些“有用”的地方滋养你的思维，因为你的目的是解决困难解决现实世界中的问题，而不是争论设计模式是否有用。

    就像你无法立即解决生活中的所有问题一样，设计模式也无法解决世界上的所有问题。不过，只要你不断地学习和思考设计模式，设计模式就能给你带来源源不断的新想法。灵感和新的希望。

    课后感想

    在开始学习23种经典Java设计模式之前，你还知道哪些经典设计模式？欢迎您在留言区与我分享，我会尽快回复您。

    下一讲，我将与大家分享Unix哲学给现代编程带来的启发。记得准时来听课哦！