在博客还没搭建之前，我曾经写过一篇东西谈论“Design Pattern”这种东西为什么是合理的，当时，貌似是七八个月之前？我曾经问过一个非常naive的问题:只有java才能完美地实现设计模式，而设计模式又是稳固地构建大型软件工程所必须的，那么……为什么其他的语言比如python这种和java几乎背道而驰的东西也可以写出几十万行代码的项目呢？
后来我终于发现了事实是什么–构建大型工程压根不需要什么设计模式，根据某些博客（包括王垠的‘当然我在扯淡’）的说法，设计模式只是当年GOF尝试用搞出一套语言，类似于另外某个人在建筑学中的尝试，来为描述设计提供一套工具。当然描述什么东西的语言和怎么做一个东西并没太大关联。
java思想的坑
在我还只会一点点C语言，读了两个月C++的时候，刚碰到java时我觉得java是世界上最好的语言，比如传说它易建壮，传说它跨平台，传说它简单，好吧其实以上三点其实都算不上java的优点，最后一点，java很火热，这属于少数几点真的优点。后来我大概花了十多天看了一半《java编程思想》，发现里面充满了充满了’design pattern’。为啥这里非得写个pattern不写‘模式’？也许这个词更能凸显pattern的‘模式化’吧，并且评论某某pattern让代码变得更为漂亮，然而我当时只是觉得这本书里面的代码越来越难懂了，说实在的我几乎看不出为啥同样一件事先用‘工厂模式’搞了一遍然后又用‘抽象工厂’搞一遍。
鉴于我开始读不懂这本书而这本书也没有详细解释‘工厂模式’，‘抽象工厂’这些东西到底是什么，于是我又去搞了一本《设计模式之禅》，这本书的确比较简单，但我发现就算是最古老的设计模式也有二十多种。当时我觉得很费解，我觉得既然设计模式对于构建大型工程这么又用，显然它就会被经常用到，那为啥它没有被直接集成到语言之中呢？显然这样就不需要再编写那些重复的代码了。再者，设计模式的存在使我直接使用别人搞好的设计，那么问题来了，设计早就被以前的人搞完了，那我还有什么可设计的呢？那我作为一个编码者不就是没啥用了吗，虽然者二者中的后者尤其令我感到很不爽，但还是把《设计模式之禅》读了一半，然后烂尾了，具体烂尾原因貌似是借书期限到了？好像是。
然后我发现了python，最初动机是想用python搞数值计算和可视化，那个时候……貌似我对物理还挺有信心的。在那个非常无聊的寒假我花了一个星期看完了oreilly的《python学习手册》。oreilly出版社……对于实用技术oreilly出版的一般是精品，我的意思是对比一些‘入门到精通’或者‘xx天学会xxx’之类的。对于只会和java语法相似的语言的人来说，刚看到python难免会觉得奇怪，比如，python没有访问控制，没有private也没有protect，没有抽象类，也没有接口，虽然python的for in 循环，列表推导，作用域划分这些都非常优雅，但是没有这些搞‘面向对象’的元素真能‘面向对象’吗？毕竟java才是‘纯粹的面向对象语言’。
好吧事实是java压根就不是什么‘纯粹的面向对象语言’，就连python这个并不纯粹的面向对象语言都比java更面向对象。问题的关键在于，对于一直学c/c++/java这几种最火的编程语言的人来说，首先并不知道什么是面向对象，然后听说java是纯粹的面向对象语言，然后就以为java这一套东西就是正统的面向对象。
我觉得对于只会c#/java的人来说，接触设计模式是迟早的。……在大概一年之后，我终于发现一年前我的几个问题的答案。感觉如果一直沉浸在java之中的话，大概很难发现。大概这属于java的思想中的坑。
为什么设计模式没有被集成到编程语言之中？
其实有一个叫kotlin的语言真的这样做了，使用kotlin比起java来，在写设计模式的时候会减少大量的代码，kotlin自称可以减少‘模板代码’，这的确是我原来想要的，虽然并不是我现在想要的。
为什么python没有访问控制？
访问控制显然并不总是是必要的，还有其他很多编程语言也没有。
没有java里面的那些东西意味着python不面向对象吗？
其实这只是python经常不被‘面向对象’所宣传，如果说java面向对象，那为什么基本数据不是对象，函数不是对象，类也不是对象？而python当中这些的确都是对象。java之所以说是面向对象，大概是由于它对函数式编程几乎没有任何支持。
