可能重复:
Properties vs Methods
在方法中,您也可以输入一些代码和属性。例如,我有一个属性名称。当类名更改时,我想从数据库中获取一些数据并更改对象的状态。我可以添加此代码来设置我的属性的一部分。其他解决方案是将set part更改为private并添加名为SetName的方法,并在此方法中添加我的代码。
那有什么区别?什么时候把一些代码放到getter / setter并且何时创建自己的方法来改变我的属性和我的类的其他部分是不好的?
答案 0 :(得分:52)
以下是一套很好的指南,用于何时使用Bill Wagner中的属性与方法(固定链接)
重复调用setter(具有相同的值)与单个调用没有任何区别。
get不应返回对内部数据结构的引用(参见第23项)。方法可以返回深层副本,并可以避免此问题。
答案 1 :(得分:12)
鉴于此类财产
private string _name;
public string Name { get { return _name; } set { _name = value; } }
可以编写以下两种方法:
public string get_Name() { return _name; }
public void set_Name(string value) { _name = value; }
行为相同。事实上,这正是编译器在创建属性时为您所做的事情。
一般来说,当它们内部的代码开始感觉“昂贵”时,我会远离属性,如果这有意义的话。我希望属性感觉像字段(在特定时间发生受控的副作用),因此它们应该是轻量级的。
答案 2 :(得分:8)
一个属性只不过是一些语法糖。 在某些情况下,最好定义属性而不是方法,因为它更清晰/更易读。
设计指南指出,当您实施的功能很昂贵时,应优先考虑某个属性。
实际上,一个属性是作为一个或两个方法实现的;取决于您的财产是否有安装者。该属性被转换为get_xxx和set_xxx方法。
答案 3 :(得分:3)
每当我遇到将代码放入getter / setter的需要时,我将代码放在私有方法中并从getter / setter中调用该方法。这样,代码在方法调用中可用,如果我在其他地方需要它。不确定这是否是您正在寻找的答案,但这只是我使用的方法。
答案 4 :(得分:3)
想到它,属性不仅仅是语法糖。它们是您的会员代码的会员数据的公开面孔。
因此,为您提供一个干净的图层,用于从您的代码中检索或输入您的成员数据的单个方面。
例如,DTO只不过是一堆写得很好的属性,可以有效地分割数据和行为。 没有DTO,您会想象将DataGrid或Dropdown紧密耦合到复杂的业务逻辑方法吗?
简而言之,方法实际上正在开展工作......属性要么采取行动要么获得状态。
但是,您可以在属性中使用方法代码......这不是它们的意思。即便如此,如果你不得不最好干净地调用属性中的另一个方法,而不是实际编写代码。 HTH!
答案 5 :(得分:2)
基本上没有区别(除了设置器中的保留标识符“value”)。
Getters和setter在内部被翻译成标准方法,因此运行时不知道某个getter或setter是否与某个属性相关联。术语句法糖通常用于这类便利结构。
但是,有一个重要的软件工程优势:如果限制自己使用get和set语义来使用getter和setter,那么代码往往更容易理解。即只做提供相应财产所需的步骤。
执行一些额外工作的常见用例是例如设置或获取不由成员字段直接支持的属性。例如,您有一个包含表示距离的值的类。您的班级可以提供两个属性:公里和英里,各自的安装者和吸气剂。然后,您将在一对中进行简单的转换,并保存自己以将值存储两次。
作为一般经验法则,您不应将任何代码放入具有副作用的吸气剂中。此外,setter中代码应该具有的唯一副作用是setter引用的对象中的状态更改。
答案 6 :(得分:1)
本质上,属性有两种方法 - getProperty和setProperty。这只是事物的惯例/简化。
假设属性getter没有副作用(好吧 - 它们可能有一些副作用,比如延迟加载)。
答案 7 :(得分:1)
这可能不是最重要的区别,但其中一个区别是调试器可以配置为跨越属性(假设它们的代码很简单)。