一、对设计模式常见的误解
在工作中,你可能常常会发现,很多人将 Java 设计模式、大学里学的高等数学和编译原理等,视为脱离实际工作的知识。
但不管是面试还是实际工作中,你是不是又经常听到大牛前辈们给你“洗脑”,说设计模式很重要?为此你可能还专门买书或参加培训学习过,可往往都因为应用效果不佳,从开始的很重视,到后来慢慢地习惯性忽略,最后在你心中它的重要程度可能还远不如明天要交差的需求。
相信我,你并不孤单。
在过去很长的一段时间里,我也曾和你一样,反复地在内心挣扎,徘徊在学与不学的矛盾里,并且时不时还有这样一些困惑:
在面试中时常被问到设计模式,可实际工作中却很少使用;
每个模式的样例代码都很熟悉,实际编码时却总感觉力不从心,实现困难;
很多系统设计看上去和很多模式都很像,却不知道到底该用一个模式,还是多个模式;
设计模式除了在编码阶段有用外,在设计上似乎用处并不大。
工作多年后,我回过头再来看,其实,当时这些困惑的关键并不在于设计模式过于抽象或应用有难度,而在于我可能从一开始就没有搞清楚设计模式的应用范围和背景:设计模式到底解决什么问题?为什么要抽象这样的场景?又是如何解决这些问题的?
正因为没有搞清楚这些应用范围和背景,才导致大多数时候我们总是在“生搬硬套”设计模式,以为在应用设计模式,却不知道还没入门就一直在误解设计模式,并无法控制地胡乱使用,最后反而引入了很多不必要的麻烦。
因此,要想学好设计模式,就得摘去这些误解。
误解一:经典模式太抽象,很难学下去
说到设计模式,你的第一反应是不是会想起“四人帮”GoF 的那本“经典”著作《设计模式:可复用面向对象软件的基础》?或者想起那 23 个“经典”的模式?
的确,设计模式太过于经典了,但是经典也会带来一个问题:过于抽象,难以快速理解。而对于业余时间本就不多的你来说,读抽象的经典更是一件难上加难的事。
比如说,下面是《设计模式》一书中关于访问者模式使用场景的描述:
一个对象结构包含很多类对象,它们有不同的接口,而你想对这些对象实施一些依赖于其具体类