ydf0509/python36patterns

编程时候，设计新的模块或者项目，下不了笔，要思考三天三夜怎么设计，主要是没学设计模式。

编程时候，有时候脑子一瞬间感觉 灵光出现，觉得这么写台好了太合适了，这样写节约代码 扩展高，瞬间感到这是个天才想法，
主要是由于没有专门学习设计模式，只能偶尔灵机一动，形成不了一套稳定的输出，所以才会有这种突然感觉某个代码设计是天才设计这种感受。

不要纠结是23种还是36种了，有细分的，举个例子 观察者模式和发布订阅模式，是有了少许变化，多了解一种总没啥坏处。
为什么是36种，因为是摘自菜鸟教程或者w3cschool网站，这两个网站都是36种，包含了j2ee模式，多了解没坏处。
不愿意学oop和设计模式，天天加班写bug解bug无限复制粘贴扣字老代码写新代码，这种写法瞎忙也没用。
比如韩信3万军队歼灭70万大军，靠的不是大无畏的胡乱冲刺，而是因为韩信看了孙子兵法36计兵书，靠的是策略，所以我要称之为36种设计模式。

设计模式十分有用，是通过大量实践对比得出来的，比如和自己国王写代码的纵向对比总结，和公司n多个现有代码项目的横向对比总结得出来的结论。

使用设计模式或oop转化公式，能使几乎任意项目代码减少50%至90%行，编码速度快一倍。
扩展性和维护性提高数十倍，bug减少5倍。
如果是使用极端纯面向过程（或者加入了少量无效废物类）的方式来写python代码，
我不用看，就知道一定很low。

问函数和类的区别，这简直是牛头不对马嘴的伪问题。
函数和方法可以比区别。函数和类比区别就是问 人和上班 、猪和吃东西 有什么区别一样，简直是没搞清楚比较维度。

类和模块可以比，类主要优势是多实例，多个实例的属性是互不干扰的，每个实例的多个方法都可以直接访问实例属性(成员变量)。
面向过程是一直很low的在函数间把本应该在oop中声明为成员变量的东西弄成在函数间反复传参和return。

类 + 方法 + 实例属性(成员变量)  约等于    模块 + 函数 + 全局变量
1）对于类，类的无数个实例化对象的实例属性(成员变量)是互不干扰的，天然的多实例。
2）对于模块 python的模块在当前解释器中是唯一的，import 一万次 xx.py，xx模块都是唯一的指向同一个地方，
所以使用全局变量 加 函数逇设计方式是行不通的，xx模块是唯一的，xx模块的a 变量 b变量也是惟一的，
所以老是需要设计成吧a和b弄成传参和return而不是全局变量来解决全局变量只有一份的问题。

所以如果需要多实例，类 + 方法 + 实例属性(成员变量) 远好于 模块 + 函数 + 全局变量。
模块 + 函数 + 全局变量 由于要模拟多实例，使全局变量（状态） 不唯一，大部分情况下需要写成 函数反复传参和反复return。
这种面向过程的封装的写法曲折程度毫无疑问被oop暴击了，面向过程导致写代码慢想破头皮搞一堆传参和return。何况oop不只有封装还有继承和多态。

能写类的人100%就能写函数，能写函数的人不一定能写类（说的是真oop的类，排除无效废物面向过程滑稽类），这是不可逆的。

只爱学python语法，只学怎么使用if else break， 学字典 列表怎么用，代码就很low
写代码很慢，设计慢，想的慢，打字慢
代码不可维护，没有高扩展性
写新文件要想破头皮三天三夜才能开始下笔。