刚刚阅读了 Design Patterns Suck 这篇文章，对设计模式有了些新的思考，且发现在之前代码品味与架构设计中可能给了些错误的引导，出于对本博客为数不多读者的负责，我快马加鞭写了这一个小短篇。

里面让我对设计模式有了重新思考的一个观点是：设计模式并不是在解决你的问题，而是让你解决语言本身的问题。我们这学期学习的 java 之所以这么推崇设计模式，是因为 java 本身的语言特性不足。 java 设计者认为，如果你给开发者太多权力，他们会自毁前程。但现在大部分语言都不是这样，尤其是 python 和 cpp 。因此设计模式就会显得冗余和过度包装，为了使用设计模式而使用设计模式，就像刚拿到什么高级工具的小孩，在解决一个简单问题时也想用所谓的高级工具（说的就是我）。

其实我早应该发现这个问题的，本人一向是质疑复杂度，推崇奥卡姆剃刀原理的。我反思了这次我被设计模式冲昏头脑的原因，有以下两点。一是，对于刚入门的程序员来说，设计模式实在显得太高级了，一度被我认为是我的大学课堂中为数不多以后能用上的内容。二是，之前和佬的交谈中，将设计模式与代码品味关联在一起，更是为其蒙上了神秘的面纱，让我直接默认了奥卡姆剃刀在写代码这件事上不成立，写代码就应该冗余设计。

现在想来，当时的自己居然一度放弃了自己最推崇的思考，因为佬和我的对话中，有能让我清醒过来的内容，但我没把握住（佬终究还是佬）。佬曾说过，应该关注的是设计模式要解决的问题，而不是具体的表现形式，也曾说过并不是所有情况都要使用设计模式，到后面要像庖丁解牛一样，自如地、知道什么时候合适地使用设计模式。只不过，真的必须要使用设计模式的地方，比我想的要少得多。

那代码品味呢？没有了设计模式这一具体的入门砖后，我们又该怎么培养代码品味呢。以我的拙见，这就不得不提到，设计模式落伍的原因：现代语言本身丰富的特性。设计模式是在一个特性有限的语言里，将部分特性以某种逻辑固定的组合在一起，但在现代语言中，特性是丰富的，因此在每个具体的、不同的场景，都可以有不同的特性以不同的方式组合在一起，甚至一个特性就能实现一个设计模式的功能。在能完成需求的情况下，不要放弃对灵活和简单的追求，不要遗漏任何一种语言的特性，这或许是现代唯一正确的“设计模式”。套用设计模式可能是一种无错的选择，但是学会自己组合特性，使用特性，灵活变通，才是在向代码品味迈进。

据我的观察，代码品味可能还和类型有关，但在这方面我还没有太深的见解，先挖个坑。

最重要的是，不能放弃思考。这次某种意义上有点像 ai hype ，我能想明白不要 ai hype ，却被自己一直所渴求的代码品味给 hype 了一回，这下能理解 ai hype 了。但既然有了前车之鉴，后面更应该保持清醒，知道思考的可贵。