@property和传统的getter和setter都有各自的优点。这取决于您的用例。

@property的优点

You don't have to change the interface while changing the implementation of data access. When your project is small, you probably want to use direct attribute access to access a class member. For example, let's say you have an object foo of type Foo, which has a member num. Then you can simply get this member with num = foo.num. As your project grows, you may feel like there needs to be some checks or debugs on the simple attribute access. Then you can do that with a @property within the class. The data access interface remains the same so that there is no need to modify client code. Cited from PEP-8: For simple public data attributes, it is best to expose just the attribute name, without complicated accessor/mutator methods. Keep in mind that Python provides an easy path to future enhancement, should you find that a simple data attribute needs to grow functional behavior. In that case, use properties to hide functional implementation behind simple data attribute access syntax. Using @property for data access in Python is regarded as Pythonic: It can strengthen your self-identification as a Python (not Java) programmer. It can help your job interview if your interviewer thinks Java-style getters and setters are anti-patterns.

传统getter和setter的优点

Traditional getters and setters allow for more complicated data access than simple attribute access. For example, when you are setting a class member, sometimes you need a flag indicating where you would like to force this operation even if something doesn't look perfect. While it is not obvious how to augment a direct member access like foo.num = num, You can easily augment your traditional setter with an additional force parameter: def Foo: def set_num(self, num, force=False): ... Traditional getters and setters make it explicit that a class member access is through a method. This means: What you get as the result may not be the same as what is exactly stored within that class. Even if the access looks like a simple attribute access, the performance can vary greatly from that. Unless your class users expect a @property hiding behind every attribute access statement, making such things explicit can help minimize your class users surprises. As mentioned by @NeilenMarais and in this post, extending traditional getters and setters in subclasses is easier than extending properties. Traditional getters and setters have been widely used for a long time in different languages. If you have people from different backgrounds in your team, they look more familiar than @property. Also, as your project grows, if you may need to migrate from Python to another language that doesn't have @property, using traditional getters and setters would make the migration smoother.

警告

Neither @property nor traditional getters and setters makes the class member private, even if you use double underscore before its name: class Foo: def __init__(self): self.__num = 0 @property def num(self): return self.__num @num.setter def num(self, num): self.__num = num def get_num(self): return self.__num def set_num(self, num): self.__num = num foo = Foo() print(foo.num) # output: 0 print(foo.get_num()) # output: 0 print(foo._Foo__num) # output: 0

以下是摘自《有效的Python: 90种具体方法来编写更好的Python》(一本令人惊叹的书)的节选。我强烈推荐)。

Things to Remember ✦ Define new class interfaces using simple public attributes and avoid defining setter and getter methods. ✦ Use @property to define special behavior when attributes are accessed on your objects, if necessary. ✦ Follow the rule of least surprise and avoid odd side effects in your @property methods. ✦ Ensure that @property methods are fast; for slow or complex work—especially involving I/O or causing side effects—use normal methods instead. One advanced but common use of @property is transitioning what was once a simple numerical attribute into an on-the-fly calculation. This is extremely helpful because it lets you migrate all existing usage of a class to have new behaviors without requiring any of the call sites to be rewritten (which is especially important if there’s calling code that you don’t control). @property also provides an important stopgap for improving interfaces over time. I especially like @property because it lets you make incremental progress toward a better data model over time. @property is a tool to help you address problems you’ll come across in real-world code. Don’t overuse it. When you find yourself repeatedly extending @property methods, it’s probably time to refactor your class instead of further paving over your code’s poor design. ✦ Use @property to give existing instance attributes new functionality. ✦ Make incremental progress toward better data models by using @property. ✦ Consider refactoring a class and all call sites when you find yourself using @property too heavily.

喜欢的属性。这就是他们存在的意义。

原因是Python中的所有属性都是公共的。以下划线或两个下划线开头的名称只是一个警告，说明给定的属性是一个实现细节，在将来的代码版本中可能不会保持相同。它不会阻止您实际获取或设置该属性。因此，标准属性访问是访问属性的正常的python方式。

属性的优点是它们在语法上与属性访问相同，因此您可以在不更改客户机代码的情况下从一个属性更改到另一个属性。您甚至可以有一个版本的类使用属性(例如，用于契约代码或调试)，而另一个版本的类不用于生产，而不需要更改使用它的代码。与此同时，您不必为所有内容编写getter和setter，以防以后可能需要更好地控制访问。

在大多数情况下，我宁愿两者都不使用。属性的问题是它们使类不那么透明。特别是，如果要从setter引发异常，这是一个问题。例如，如果您有一个帐户。电子邮件属性:

class Account(object):
    @property
    def email(self):
        return self._email

    @email.setter
    def email(self, value):
        if '@' not in value:
            raise ValueError('Invalid email address.')
        self._email = value

这样，类的用户就不会期望给属性赋值会导致异常:

a = Account()
a.email = 'badaddress'
--> ValueError: Invalid email address.

结果，异常可能得不到处理，或者在调用链中传播得太高而无法正确处理，或者导致向程序用户提供非常无用的回溯(遗憾的是，这在python和java世界中太常见了)。

我也会避免使用getter和setter:

因为提前为所有属性定义它们非常耗时， 使代码的数量不必要地变长，这使得理解和维护代码更加困难， 如果只在需要时为属性定义它们，类的接口将会改变，损害类的所有用户

而不是属性和getter /setter，我更喜欢在定义良好的地方执行复杂的逻辑，例如在验证方法中:

class Account(object):
    ...
    def validate(self):
        if '@' not in self.email:
            raise ValueError('Invalid email address.')

或类似帐户。保存方法。

请注意，我并不是想说在任何情况下属性都是有用的，只是说如果您可以使您的类足够简单和透明，以至于您不需要它们，那么您可能会更好。

我认为两者都有各自的地位。使用@property的一个问题是，很难在子类中使用标准的类机制扩展getter或setter的行为。问题是实际的getter/setter函数隐藏在属性中。

你可以掌握这些函数，比如

class C(object):
    _p = 1
    @property
    def p(self):
        return self._p
    @p.setter
    def p(self, val):
        self._p = val

你可以像C.p.fset和C.p.fset一样访问getter和setter函数，但是你不能很容易地使用普通的方法继承(例如super)工具来扩展它们。在深入研究了super的复杂性之后，你确实可以这样使用super:

# Using super():
class D(C):
    # Cannot use super(D,D) here to define the property
    # since D is not yet defined in this scope.
    @property
    def p(self):
        return super(D,D).p.fget(self)

    @p.setter
    def p(self, val):
        print 'Implement extra functionality here for D'
        super(D,D).p.fset(self, val)

# Using a direct reference to C
class E(C):
    p = C.p

    @p.setter
    def p(self, val):
        print 'Implement extra functionality here for E'
        C.p.fset(self, val)

然而，使用super()是相当笨拙的，因为必须重新定义属性，并且必须使用稍微违反直觉的super(cls,cls)机制来获得p的未绑定副本。

我很惊讶没有人提到属性是描述符类的绑定方法，Adam Donohue和NeilenMarais在他们的帖子中得到了这个想法——getter和setter是函数，可以用于:

验证 改变数据 鸭子类型(强迫类型到另一种类型)

这提供了一种聪明的方法来隐藏实现细节和代码cruft，如正则表达式，类型转换，尝试..块、断言或计算值除外。

一般来说，在对象上执行CRUD可能相当简单，但请考虑将持久化到关系数据库的数据示例。ORM可以在属性类中定义的绑定到fget, fset, fdel的方法中隐藏特定SQL白话的实现细节，该属性类将管理可怕的if ..elif . .在OO代码中是如此丑陋的梯子——暴露了简单而优雅的自我。variable = something，为使用ORM的开发人员消除细节。

如果有人认为属性只是束缚和纪律语言(即Java)的一些沉闷的残余，那么他们就没有理解描述符的意义。