OOP对小脚本有意义吗?

我使用最适合当前问题的范式——无论是程序性的、面向对象的、功能性的。。。程序大小不是一个标准,尽管(有一点差距)一个较大的程序可能更容易利用OOP的优势——一个类的多个实例、子类和重写、特殊方法重载、OOP设计模式等。这些机会中的任何一个都可以很好地发生在一个小脚本中,只是有一个更高的可能性,它会发生在一个更大的。

另外,我讨厌 global 全球的

面向对象编程虽然有助于将系统表示为现实世界的对象(希望能使大型软件系统更易于理解),但并不是所有解决方案的灵丹妙药(尽管有些人教过)。

如果您的系统不能从OOP提供的东西(如数据抽象、封装、模块化、多态性和继承)中获益,那么产生OOP的所有开销是没有意义的。但是,如果您发现随着系统的发展,这些问题会成为您更关心的问题,那么您可能需要考虑采用面向对象的解决方案。

:作为更新,您可能需要前往Wikipedia阅读有关各种网站的文章 criticisms of OOP

用oop开发的一个不幸的习惯是Objectophrenia——在我们编写的每一段代码中看到对象的错觉。

之所以会发生这种情况,是因为我们的错觉相信存在一个统一的物体定理。

这是一个令人讨厌的习惯。通常情况下,最好不要有它。但是当你发现你写的每一段代码都以某种方式落入了模式中,并且你重构/重新调整了这些模式,直到它覆盖了你的大部分需求时,你就会有一种满足感和成就感。

当程序员产生错觉(强迫性面向对象障碍)并且没有意识到模式有例外时,问题就开始出现了,试图过度操纵模式来覆盖更多的案例是错误的。就像我儿时的痴迷,每天早上我吃早餐的时候,都要用黄油或果酱把一片面包完全盖住。有时候,最好还是抛开面向对象的概念,快速而肮脏地完成手头的任务。

公认的工业格言80-20可能是一个很好的衡量标准。用一种不同于通常理解的方式来使用这句格言,我们可以说80%的时间都是面向对象的。20%的时间-快速编码。

沉浸在物体中,但最终你必须抵制它吞噬你。

import 然后再利用一些,是的。在第二种情况下,最好编写一些提供所需功能的类,然后进行条件运行( if __name__=='__main__':

我的经验是,任何超过几十行的纯程序脚本都很难维护。首先,如果我在一个地方设置或修改一个变量,在另一个地方使用它,而这两个地方不能放在一个屏幕上,麻烦就会随之而来。

当然,答案是缩小范围,使应用程序的不同部分更加封装。OOP是实现这一点的一种方法,并且可以成为建模环境的有用方法。我喜欢OOP,因为我发现我可以从思考特定对象的内部如何工作,跳到思考对象如何一起工作,我保持清醒。

OOP是一种管理代码复杂性的工具,50-250行代码很少是复杂的。我写的大多数脚本主要是程序性的。所以是的,对于小脚本,只需使用过程编程。

请注意,对于非常复杂的脚本,OOP可能更为相关,但仍然没有硬性规定要求对它们使用OOP。那是个人喜好的问题。

为正确的工作使用正确的工具。对于不需要复杂数据结构和算法的小脚本,面向对象的概念可能没有用处。

我是不是因为没有更努力地使用对象而漏掉了什么东西,还是OOP对小脚本没有太大意义?

物品买你 封装 和 (通过继承)。在编写小脚本时,这两种方法都不太有用。当您编写了一个类似脚本的集合,或者您发现自己在反复更改脚本时,那么也许您应该考虑对象可能有帮助的地方。

在您的例子中,我认为OOP只有在使脚本更可读和更易理解的情况下才有帮助。如果没有,你可能不需要麻烦。

OOP只是另一个范例。很多问题都可以用过程或面向对象的方法来解决。

OOP的另一个好处是传达意图(无论是对其他开发人员、管理人员,还是将来某个时候对自己)。如果脚本足够小,可以用几句话完全沟通,那么在我看来,OOP可能没有必要。

对几百行代码使用OOP很少有意义。但是如果你的脚本是有用的,它可能会增长得相当快,因为新的功能将被添加。如果是这样的话,最好从长远的角度开始编写OOP。

首先-你说的物体是什么意思?在Python中,函数是对象,您很可能正在使用它们。:)

在小脚本中,不会有任何来自复杂OO设计的杠杆作用。

后者促进了低耦合、封装、责任分离和其他一些概念,这些概念通常产生代码,即简短、表达、可维护、灵活、可扩展、可重用和健壮。

OOP使模块化编程变得更容易,因为它已经为实现模块化编程所提倡的概念建立了解决方案,并且多态性允许通过依赖注入实现真正的低耦合。

就我个人而言,在一个脚本完成了20-30行代码之后,我通常可以找到一种让OOP对我更有意义的方法(尤其是在Python中)。

例如,假设我正在编写一个解析日志文件的脚本。好吧,从概念上我可以想象这个“日志解析器”机器。。。我可以把这些纸都扔进去,它会把它们分类,从一些页面上剪下一部分,然后粘贴到另一页上,最后递给我一份漂亮的报告。

thirdwordremover 和一个 textreversal

class LogParser(Object):
    def __init__(self):
         #do self stuff here
    def pageReader(self):
         #do the reading stuff here, probably call some of the other functions
    def findFrobnitz(self):
         pass
    def findEasterBunny(self):
         pass
    def thirdWordRemover(self):
         pass
    def textReversal(self):
         pass

这是一个非常做作的例子,老实说,可能不是一个情况下,我会使用面向对象。。。但这真的取决于我在那个特定时刻最容易理解的东西。

“脚本”是指“顺序的”和“程序的”。这是一个定义。

有些语言允许您清楚地识别对象。有些语言不能清楚地识别物体。对象是 在那里。这是一个语言表达清楚还是晦涩难懂的问题。

因为物体是 总是 在那里,我发现使用一种能够清晰识别对象、对象的属性、方法和关系的语言是有帮助的。即使是简短的“脚本”,我发现显式对象和OO语言也有帮助。

“过程”、“脚本”和“OO”之间没有有用的区别。

这只是重点的转移。对象是 总是 在那里。世界本来就是面向对象的。真正的问题是“你是否使用了一种使对象显式的语言?”

作为一个编写大量脚本的人,如果你认为你的代码在某个时候可能会超过250行,那么就开始面向对象编程。我使用了大量的vba和vbscript,我同意任何低于100行的代码通常都是非常简单的,花时间来规划一个好的oop设计只是一种浪费。