如何正确创建实用程序类

Wei*_*Nir 37 python class

我有一个文件,意味着一个实用程序文件.该文件应包含许多静态方法.

我应该这样定义类中的方法:

#utility.py
class utility(object):
    @staticmethod
    def method1(a,b,c):
        pass

    @staticmethod
    def method2(a,b,c):
        pass
Run Code Online (Sandbox Code Playgroud)

或者像这样使用它(没有课程):

#utility.py
def method1(a,b,c):
    pass

def method2(a,b,c):
    pass
Run Code Online (Sandbox Code Playgroud)

Gam*_*iac 31

第二个选项是Python中的运作方式.我的意思是,如果您所做的只是导入函数,那么您可以执行以下操作:

from utility import some_func
Run Code Online (Sandbox Code Playgroud)

这将导入您的功能.

最佳实践是,如果您只使用静态函数,那么只需将它们放在单独模块的全局命名空间中,它将使您的生活更轻松.你要做的是制作对象,然后用静态方法填充它们.为什么这样,当你可以在.py文件中定义函数时?

事实上,你正在做什么已经被完成.你试图存储一些好的实用功能.嗯,python-requests是大多数Pythonistas所崇拜的第三方库就是这样做的.它将其良好的实用功能存储在一个单独的模块中.这是一个例子.

  • **永远不要**在生产代码中使用“from foo import *”。它使得无法跟踪导入的来源,并且可能掩盖内置名称。 (2认同)
  • 最佳实践是,如果您只使用静态函数,那么只需将它们放在单独模块的全局命名空间中,它将使您的生活更轻松. (2认同)

Cro*_*man 20

类封装了数据和行为,因此作为一般规则:

  • 如果你只有数据,没有方法,它应该是a namedtuple,而不是a class,除非你需要在创建数据后修改它.
  • 如果函数访问实例数据,它应该是一个方法.
  • 如果函数不访问实例数据,但访问类数据,则它应该是a @classmethod.
  • 如果一个函数既不访问实例数据也不访问类数据,它应该是一个独立的函数,除非有一些非常令人信服的理由使它成为一个@staticmethod.
  • 如果class只有一个方法或一个方法__init__(),那么你几乎可以并且应该将它重写为一个函数.

课程很容易被滥用,但是应该避免将所有东西都推到课堂上的诱惑.你应该在它们有意义时使用它们,并且当它们没有时使用它们.


iCo*_*dez 10

虽然这个问题有点基于意见,但我会说第二个更好.它减少了冗余.使用第一种方法,您将不得不这样做:

import utility
utility.utility.method1(...)
Run Code Online (Sandbox Code Playgroud)

要么:

from utility import utility
utility.method1(...)
Run Code Online (Sandbox Code Playgroud)

然而,使用第二个允许您简单地执行:

import utility
utility.method1(...)
Run Code Online (Sandbox Code Playgroud)

要么:

from utility import method1
method1(...)
Run Code Online (Sandbox Code Playgroud)

如果你正在创建一个只包含静态方法的类,我的问题是"为什么你需要这个类?" 它在这里没有任何积极意义