Mad*_*ist 27 python oop scripting
我主要在python中编写小脚本,大约50到250行代码.我通常不使用任何对象,只是简单的程序编程.
我知道OOP的基础知识,之前我曾在其他编程语言中使用过对象,但是对于小脚本,我看不到对象如何改进它们.但也许这只是我对OOP的有限经验.
我是否因为没有更努力地使用对象而遗漏了某些东西,或者OOP对小脚本没有多大意义？
Ale*_*lli 32
我使用最适合手头问题的范例 - 无论是程序性的,OOP,功能性的......程序大小不是一个标准,但是(稍微有点边缘)更大的程序可能更有可能利用OOP的优势 - 类的多个实例,子类化和重写,特殊方法重载,OOP设计模式等.这些机会中的任何一个都可以很好地发生在一个小脚本中,它在更大的脚本中发生的可能性稍高.
另外,我讨厌global声明,所以如果自然程序方法需要它,我几乎总会转而使用OOP - 即使唯一的优点是能够使用限定名称而不是需要的名字global.
一般来说,没有必要"更加努力" - 只要问自己"这里有机会使用(a)多个实例(等等)"并且很快就会成为第二天性,即你会发现机会无需每次都有意识地提醒自己寻找它们,因此您的编程将得到改善.
使用oop开发的一个不幸的习惯是Objectophrenia--在我们编写的每一段代码中看到对象的错觉.
之所以发生这种情况,是因为我们错误地认为存在统一的对象定理.
您编写的每一段代码,您都开始将其视为对象的模板以及它们如何适合我们的个人计划.即使这可能是一项小任务,我们也会受到这个问题的诱惑 - 这是我可以放入我的类库中的,我也可以将其用于未来吗？我是否在这里看到了一个模式,其中包含我之前编写过的代码以及我的对象千里眼告诉我的代码,我有一天会写这个代码？我可以将当前任务构建为其中一种模式.
这是一个讨厌的习惯.通常情况下,最好不要拥有它.但是当你发现你编写的每一段代码都以某种方式落入模式中并且你重构/重新调整这些模式直到它满足你的大部分需求时,你往往会感到满足和成就.
当程序员出现妄想(强迫性的强迫性面向对象障碍)并且没有意识到模式存在例外并试图过度操纵模式来覆盖更多案例时,问题就开始出现了.这就像我童年的痴迷一样,每天早上我都吃早餐,试图用黄油或果酱完全覆盖一块面包.有时候,将面向对象的感知留在后面并且只是快速而肮脏地执行手头的任务会更好.
公认的80-20的工业格言可能是一个很好的衡量标准.以不同于通常感知的方式使用这种格言,我们可以说80%的时间具有面向对象的感知.20%的时间 - 编码快速而肮脏.
沉浸在物体中,但最终你必须抵制它消耗你.
你可能还没有做足够的编程,因为如果你有,你会看到你所做的所有模式,你也会开始相信你尚未应用的模式.当你开始看到这样的物体视觉异象时,是时候注意不要被它们消耗掉.
如果您打算独立使用脚本,那么不.但是,如果您计划import并重复使用其中的一部分,那么是的.在第二种情况下,最好编写一些提供所需功能的类,然后使用if __name__=='__main__':带有代码的条件运行()来执行脚本的"脚本"版本.
我的经验是,任何超过几十行的纯粹程序脚本都难以维护.首先,如果我在一个地方设置或修改变量并在另一个地方使用它,而这两个地方不能放在一个屏幕上,那么麻烦就随之而来.
答案当然是收紧范围并使应用程序的不同部分更加封装.OOP是实现这一目标的一种方式,可以是一种模拟环境的有用方法.我喜欢OOP,因为我发现我可以在思考特定对象的内部如何工作时思考,思考对象如何协同工作,并保持理智.
但是,OOP肯定不是使代码更好地封装的唯一方法; 另一种方法是一组带有精心定义的输入和输出的小型,命名良好的函数,以及一个适当调用这些函数的主脚本.
OOP 是一种管理代码复杂性的工具，50-250 行代码很少是复杂的。我写的大多数脚本主要都是程序性的。所以，是的，对于小脚本，只需使用过程编程即可。
请注意，对于非常复杂的脚本，OOP 可能更相关，但仍然没有硬性规则要求对它们使用 OOP。这是个人喜好的问题。