设计模式的学习和应用

围棋定式，是指在特定的情况下，黑白双方的最优解。限于篇幅，介绍定式的书，通常只描述了标准答案，或者最多加上几种变化，但在现实中，可能有几百种变化。我就不喜欢背定式。我喜欢偏偏不按定式走，看看对手会怎么应，接下来局势会如何变化，对我如何不利，然后解决这些问题。当我把这些问题都解决完，我也就逼近了标准的定式，但同时我掌握了几乎所有的变化，这样在实战中，对手不按定式的变化来应招，我也知道怎么下。

在编程领域，也有很多定式，我们称之为模式。同样的，我认为只把书上的设计模式背下来，不能算掌握了这种模式。

我喜欢写朴实无华的代码，不喜欢用“黑科技”式的模式。举个例子，摩托罗拉有一位令我尊敬的高手写了一个工厂类，根据不同的输入参数，创建不同的对象。他使用了c#的反射标签，声明类时在上面打上标签，构造时根据输入参数循环所有的类，发现标签跟输入参数一致，就构造这个对象。这样代码很简洁，没有冗长的if else或switch case。但对第一次看这个代码的人，会造成阅读困难，我相信即使是对反射技术很熟悉的人，也要花更多的时间才能明白这代码的意图。更别提这种反射用法应该不是很常用（可能是我孤陋寡闻）。更重要的是，实际应用场景里，需求可能只有三四个case（我记得是用于区分产品线类型）。即使写成if else也不会太长。代码换成我来写，我就会先用简单的if else实现这个逻辑，如果随着产品的维护if else变得很长，比如有几十个，再考虑重构，采用技术简化，比如上面的反射。在工作中，我遇到不少照搬定式，过度设计的情况。有的是因为对模式理解不深，有的则是为了炫耀技术。由于可能涉及公司业务就不细说了。《设计的原则，模式与实践》这本书中，作者提出了第一颗子弹原则，一开始不必把系统设计得过于复杂，当你中了一颗子弹，再做相应的修改调整。这是我从小性格养成的习惯。这导致我考试成绩一直不怎么样。每当学到一个公式，我都会想研究它是怎么推导的，它所代表的实际意义是什么。但在实际工作中，我发现我的表现在周围人的排名远远好于学校里的情况。