简书 賈小強
转载请注明原创出处，谢谢！
在静态语言比如Java中被人熟知的21种设计模式可以谓大名鼎鼎，而为什么到了动态语言比如Python中设计模式不再突出，这篇文章讲进行分析
在静态语言中为了不让代码写死，为可能的变化预留灵活性，从而很多模式都利用接口，高层代码面向抽象编程，只有当实际运行的时候代码高层代码才执行实例化的具体对象的方法，而在动态语言中语言本身就具有动态性，于是不再需要显式的接口
| 静态语言（Java） | 动态语言（Python） |
|---|---|
| 优点：由于显式面向接口，于是在IDE中可以跳转到特定的接口，然后通过接口又可以找到实现这个接口的某些类，建立代码的联系更方便直观 | 优点：省事，不需要显式专门写个接口。方便的高级数据结构list，dict，set，方便构造json |
| 缺点：费事，需要更多的代码，类型声明，显示接口定义。没有方便的list，dict，set，构造json显得臃肿，不自然 | 缺点：只有当代码实际运行的时候在知道某个变量到底是什么，于是对某个方法，或者某个类在没运行的情况下不容易理解 |
也许有人觉得面对复杂的代码我们情愿多写一点东西，让代码更加方便理解，这确实不错，那么动态语言是否真的写不出强壮并且方便理解的代码呢？
实际情况并不是这样，通过足够的单元测试和模拟测试，针对每个类或者方法有对应的单元测试，需要理解代码，只需要跑一下对应的测试加上断点也可以方便的理解某些变量实际上到底是个啥我们都知道单元测试如此重要，在静态语言中一样，那么既然静态语言也需要写单元测试，那么静态语言的显示的接口是否多余呢？
从代码理解的角度确实是这样，但是显式接口有些是静态语言所不具有的优势，比如上面提到的IDE支持可以通过接口知道实现这个接口的有哪些类，在没单元测试支撑的情况下，静态语言更加容易理解学习扩展，比如知道某个类依赖某个类型的接口就可以学习相关的各种不同变体了，而动态语言中单元测试了解的只是局部，然后通过局部的类，再去找到可能存在的继承体系，动态语言知识相对没有显式的联系，为此假设拿到一个类，再没跑起来的情况下，可能无法继续学习，当然不能跑起来的代码本身就没有价值，代码终是都能跑起来的静态语言更方便够构建抽象层次更高的系统吗？
在动态语言中，假设我们在一个高层考虑问题，编写高层代码的时候没有IDE的自动提示，只能依靠自己理解来建立联系，需要人记住的更多和靠人主观建立联系，至少某个方法传入的是个x，实际我在给一个Frame类型对象编程，那么没代码提示，真心不方便。以此推论，静态语言可以方便的在高层编码，甚至层次不断提升，而动态语言到了高层只有靠人，而且有的代码重构根本无法实现，比如我想讲x重命名，也只能重命名方法作用域的局部变量，并不能将整个项目中同种类型的对象重命名，可能在一个大型的项目中这将产生严重的悲剧，不同的team在用不同的名字表达同一个东西动态语言是不是不存在，或者不需要设计模式？
答案是否定的，首先对于有些设计模式，在动态语言中确实根本不需要，但是对于一个设计良好的面向对象系统而言，并不分动态还是静态语言，至少如果某些数据和数据相关的操作没在一起，分离两地，各种传来传去，很快动态语言将为方便付出代价，科学有效的面向对象分析设计终是能够带来好处，而从本质的角度理解，如果需要高层代码和底层代码分离，那么还是需要高层代码面向隐式的接口编程。当然这一些都是在逐渐复杂不可控的情况下，如果你的系统只是个HelloWorld，别提什么设计模式，设计模式是根据需要而生的实际的一般系统并没有那多变化，实际上面向抽象并没有那么必须？
答案是肯定的，面向过程的C语言写出了操作系统，数据库，各种厉害的软件，设计模式甚至面向对象都并不是必须的，各种设计模式中奇奇怪怪的抽象分割在没必要的情况下只会给系统增加不必需要的复杂性，只有都衡量利弊根据需要后才有一个答案，但是如果不知道，那恐怕只有一个解，优秀的程序员是一种宁愿思考1小时然后编码的生物，而不是不加思考权衡封山开山封水开水，后终将陷入自己设计的泥潭，同时不从多种方案中选择权衡的程序员也无法达到更高的高度
Happy learning !!
