• "Design patterns" are not pattern
• "Design patterns" are not about "design"
• What "design patterns" really are

There has been many criticisms on design patterns over the years. Generally speaking, people think those patterns are not that useful(or even, harmful), and can be simplified or eliminated if some features are directly supported by the programming language itself. However, I have yet to see any criticism on "design patterns", I mean, the name. So here's what I think:

"Design patterns" is a really bad name.

"Design patterns" are not pattern

This is a pattern —— the leaves on the carved woodwork repeat in a predictable manner. Normally, you would observe things and find a pattern.

"Design patterns" are not. It may originally come from observing the commonalities in existing code, but it has now become (at least that's what believed by most people) the guidelines people should follow when writing new code. See the difference here? A pattern is the outcome of an observation, they are not, and never meant to be the guidelines for creating new things. Why would you write code like others, just because they wrote it in a certain way? Are you solving the same problem? Do you know the requirements of your program? Do you know the requirements of their programs?

The root cause here, is the word "pattern". We often say "follow a pattern", but that does not mean that "we should follow a pattern when writing new code", in contrast, it is describing a feature of old code, and the program you are about to write is NOT part of it. The word and the phrase are so misleading, it has caused so many programmers (especially Java programers) to believe from the start, that these "patterns" are the law of god, and they will be punished if they ever disobey them.

"Design patterns" are not about "design"

In Google, we write design docs for projects & features that we believe will take longer than a few weeks to accomplish. I've written and read many design docs, but I have not seen any design doc saying "we should use Singleton/Adapter/Proxy... in this project", not even once. Why? Because it is not part of the design. You should define how components communicate with each other, that's design, but nobody cares about whether it is using a singleton. I'm not saying singleton is a bad idea, it may or may not be, but that is what code review is there for, not design.

Again, the word "design" misled so many people, just like "pattern". The authors of GoF are truly geniuses, as I write this, I realized that there couldn't be a better name than "design patterns" that would made the concepts more popular and well accepted than it has ever become today. Let's imagine your friends, who knows nothing about programming, looking at this magical word. What would they think? I actually asked two friends, one thought it's the principles to design a product, the other said it's probably a math model, or a mental model to help you think about a problem. This is quite like what I expected. Like everyone, we understand words by examining their literal meaning. No one is a born programmer, therefore when seeing the word for the first time, we got the impression that it's "about design", it's "how we should model a problem". But actually, it's not, it's implementation details.

With that false impression in mind, some programmers (especially Java programers) tend to decide which design patterns to use before writing the first line of code. What's even worse is that, not many people have the habit of writing design docs, but they still believe they are doing the "designing" work, because they try very hard to pick what design patterns to use! Great job, GoF 👏👏

What "design patterns" really are

"Design patterns" are just coding techniques. That's all. They are by no means more "advanced" or "higher-level" than other techniques, like short-circuiting.

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

So, my final conclusion is, "design patterns" could either be a terrible name, or a brilliant name, depending on how you look at it.

刚才一直在看沙村广明的新作《电波啊，听着吧》。这是一部讲述餐馆女招待成长为电台主播的故事（大概？）。了解到这部漫画是因为知乎上有人提到，结果发现我并没有那么喜欢沙村广明的风格，不过这不重要，重要的是它让我突然想写一点关于“内容创作”的东西。

内容创作者，也就是 content creator，包含的范围及其广泛。小说家、作曲家、导演、主持人、演员、电台主播，当然还有像我们这种兴趣使然写博客办播客的。虽然种类繁多，但其本源都是人类想要表达的欲望。为什么人要表达？可能很大程度上是为了确认自身的存在。以前和朋友聊天，他说死亡最可怕的地方不是痛苦，而是在于死了之后什么都没有，甚至连痛苦都感受不到。而活着的人，如果没办法感受到任何事，其实和死了也差不多。我们通过听、看、闻来感受外界，然而，我们又要如何感受进行感受的物质，也就是我们自身呢？笛卡尔说过“我思故我在”，他通过自己正在思考存在这件事确认自己的存在。这种证明对于普通人还是太抽象了，因此我们需要一些更简单，更直接，更有形的东西。我们所创作的内容，正是这样一种东西。当我们完成某件作品，“我”从一个抽象的概念变成了作品的一部分。注视着它，会让我们想起创作过程中我的所思所想。我们因为确认到自身的存在而感到满足。

另一方面，我们也通过他人的反馈来确认自身。你讲了一个笑话，听的人哈哈大笑，于是你为“自己”逗乐了他人而开心。显然，如果没有说笑话的你，也就没有被逗笑的听众，我们的大脑会很快理解这个因果关系。作为内容创作者，我们总是希望自己的作品能被更多人看见，比如你能在各种地方看见大家乐此不疲地贴出博客地址，不管实际有多大作用。你若问他为什么要贴，他大概也说不出个所以然。我认为通过他人确认自身可以算是人的一种本能，而内容创作者的这个需求会比一般人更强烈。

内容创作同时也是对死亡的直接反抗。这个话题我在《People Die, but Long Live GitHub》一文也有提过。即使你的肉体已经死亡，只要作品还在，某种意义上你这个人就还存在。这是一个被人类社会广泛接受的概念，而它也给了我们直面死亡的勇气。如果回到以前和朋友聊天的那时候，我会对他说，只要你的作品还被人记着，那就并不是什么都没有。虽然你不能在死后感受到任何事，你却可以在活着的时候尽可能地作出更好的歌曲，写出更好的小说，让作品的流传变成一件确定无疑的事。那么，既然你可以在活着的时候确认自己在未来的存在，死后能不能感受到这一点，又有什么分别呢？

说起来好像还没发过这个

石头剪刀布游戏，请用浏览器打开

去年换组，想去做 AR/VR。临时抱佛脚看了一点 three.js 和图形学，做了这个小项目。那几周真的是累到吐血。结论是图形学太难了，智商低学不会。最后别人说想找个更有经验的，就算了。