1、之前写的这个很久了
里面提到的是三步走：
模块和类的转换规则是：
1、模块级降为类
2、全局变量改成实例属性，全局的不会被改变的变量类似于那种const的，可以写成类属性（减少点内存存储可以）。
3、然后把函数改成方法。方法是类里面的，函数是模块里面的。
因为里面举得一个例子是一个人，但人的属性写的是模块级全局变量，如果是这种写法，三步走就可以oo了。
2、但现在的情况是很多人不喜欢写全局变量（不写全局是为了尽可能模拟多实例，不可能用全局变量，因为全局变量只有一份；而且运行结果是从入口函数传参得到结果，不希望修改顶层代码，所以才会出现尽量少写全局变量这种现象了），喜欢一步一步一环套一环的传参和return来处理业务，那么这种写法，如果按照上面的三步走战略，就不行了，因为只执行这三部，这样做是没有个卵用的，只是有了class外壳，但丝毫没有封装的概念。我最近就看过一些这样的类，写的貌合神离，貌像面向对象，但神是面向过程，这种类当然是十分的没必要，因为没有体现出面向对象带来的任何优点，也没任何意义了，执行这三步价格class关键字，只不过是脱了裤子放屁。
如果是这种思维来写的面向过程，那么三步走还不行，需要重新构思整个流程，即在代码里面少return少传参，多用全局变量，按照这个思路在脑袋里面过一遍，这一步是发生在脑袋里面的，不是让你真在代码写全局变量，是为了先构思出来有哪些全局变量，然后再接着上面的三步走战略降级命名空间，就是oo了。
所以这个前置的发生在脑袋里面的过程是不能少的，这一步是整个精神支柱 ，后面三步是修改代码面貌。
那么总结一下就是四步走了：
0、脑瓜里面构思，你的面向过程的return 传参，有哪些尽可能多的是可以弄成全局变量的，这时候不用考虑全局变量是不是需要多份的，因为后面在三步走降级的时候，这个玩意自动变成了实例属性，而每个类的实例的的属性都是互不干扰的，除非了你刻意写了单例模式。
1、模块级降为类
2、全局变量改成实例属性，全局的不会被改变的变量类似于那种const的，可以写成类属性（减少点内存存储可以）。
3、然后把函数改成方法。方法是类里面的，函数是模块里面的。
第0步发生在脑袋里面，后面三步发生在代码编辑器里面。
面向对象本质是方法和属性的封装，如果把属性绑定全部改为外界传参给方法，那写这样的类，基本上是没个鸟用废了类的80%功能，只不过是加个class外壳罢了，。
原文地址：https://www.cnblogs.com/ydf0509/p/9265536.html