我见过一些人通过创建一个类和一个对象来调用所有方法来编写 Python 代码。如果我们不使用继承、封装等，使用类有什么好处吗？在我看来，这些代码似乎不太干净，因为我们可以避免所有这些“自我”论点。这种做法是否受到其他编程语言（如 Java）的影响，或者 Python 程序应该采用这种结构有什么好的理由？
示例代码：
class App:
# all the methods go here
a = App()
【问题讨论】：
虽然并不总是适用，但它的一个优点是它可以通过子类化一个类来轻松扩展程序。例如，我可以对其进行子类化并覆盖从 csv 文件读取的方法以读取 xml 文件，然后根据运行时信息实例化子类或原始类。从那里，程序的逻辑就可以正常进行了。
这当然提出了一个问题，即读取文件是否真的是类的责任，或者更恰当地属于一个类，该类具有用于读取不同类型数据的子类并为该数据提供统一的接口，但也就是说，当然，另一个问题。
就个人而言，我发现最干净的方法是将对其参数做出强烈假设的函数作为方法放在适当的类中，并将对其参数做出非常弱假设的函数作为函数放在模块中。
【讨论】：
我自己也经常为应用程序的管理器部分做同样的事情，理论上可以简化为简单、非常顺序的函数式编程。
它的主要优点（对我来说）是它很好地封装了你的主循环或你的一次性执行，它允许跨块高效、干净地配置运行和持久化数据，从根本上根据需要重新配置它无需更改代码本身。更不用说将执行子类化为不同的扩展执行的能力了。
以这种方式扩展主要内容也往往容易得多，然后就是当你有一个由 200 行组成的实心块来扔掉相当隐蔽的范围内的东西时。
自我，在你写了足够多的 Python 之后，有点像障碍物消失了，我个人喜欢它如何立即提供视觉上的区别，我显然希望跨范围坚持什么，什么是我做的一次性元素想要超出范围并在完成特定步骤后立即被收集。
最后但并非最不重要的一点是，有些人会对他们拿到的任何东西进行对象定向，或者无法阅读它。我就是其中之一:)
【讨论】：
1.我知道这样做的一种用途。
虽然这可以通过其他方式实现。它确保两个模块 - module_B 和 module_C 使用相同的 App 实例，并且不会实例化单独的对象。
在module_A.py中
class App:
....
a = App()
在module_B.py中
from module_A import a
在module_C.py中
from module_A import a
当然，您可以创建单独的对象，但这不是上述模块的意图。
如果您在 module_D.py 中执行以下操作会怎样
from module_A import App
a = App()
2。 [迂腐]
您可以避免使用类并仅使用模块和函数来分解您的解决方案。但是在大型程序中这看起来不会很丑。你不想在你的程序中使用面向对象的范例吗？所有语言都提供了利用 OO 的特定方式。我们都喜欢某件事或其他事情，有些确实让我们失望。显式优于隐式通常是 Python 方式。虽然这还不足以成为包含它的理由。
【讨论】：
当我认为我可能需要某个东西的多个实例时，或者如果我认为从它继承会有用时，我倾向于使用类。如果我只是在寻找一种方法来对影响其行为的相关功能和设置进行分组，那么，一个模块也可以用更少的语法来工作。有时我会在同一个模块中使用这两种方法。
此外，尽管您可以将装饰器和上下文管理器编写为类，但我个人倾向于将它们编写为函数时更清晰，因此我通常是这样编写它们的。
Python 是一种多范式编程语言。使用您认为最清楚地表达您的意图的任何方法。您永远需要使用 OO。
我喜欢使用的一种方法是考虑如果其他人要编写一个模块以通用方式解决像我这样的问题，我希望如何向我提供各种功能。基本上，我首先尝试设计模块之间的接口，并使每个模块尽可能简单易用。在这一点上，我开始清楚我应该为每个功能使用什么方法。
但我只是一个人，编程不是我的主要工作。
【讨论】：
__enter__() 和__exit()__ 之间共享状态，就不必使用实例变量。只是普通的老当地人工作得很好。
如果我们不使用继承、封装等，使用类有什么好处吗？
是的。
这种做法受到其他编程语言（如 Java）的影响
没有。
有什么好的理由说明 Python 程序应该采用这样的结构？
是的。
但是。根据您的问题，您已经清楚地确定“在我看来，这些代码在所有这些‘自我’论点中都不那么干净”。
如果您已经确定它“不太干净”，那么解释类声明的优点就没有什么意义了。
考虑一下。
底线。
你可以在短时间内不上课。直到你做出改变。那你会后悔没有class这个词和所有那些“不干净”的自我论点。
你最终会添加它们。
为什么要等？
【讨论】：