有什么理由不使用“受保护”？特性？
只是想知道......
有什么理由不使用受保护的属性吗？
我的意思是不要使用这个：
public abstract class Foo
{
protected Bar { get; private set; }
}
使用这个：
public abstract class Foo
{
private Bar _bar;
protected Foo(Bar bar)
{
_bar = bar;
}
protected GetBar()
{
return _bar;
}
}
Just wondering...
Is there any reasons not to use protected properties?
I mean instead of using this:
public abstract class Foo
{
protected Bar { get; private set; }
}
to use this one:
public abstract class Foo
{
private Bar _bar;
protected Foo(Bar bar)
{
_bar = bar;
}
protected GetBar()
{
return _bar;
}
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不认为您有任何理由使用
GetXXX()方法而不是属性，无论它的修饰符如何。由于您使用
C#标签标记了这个问题，因此我强烈建议使用第一种方法。这就是属性的用途。仅当每次调用该方法时返回的值可能不同（无论其状态如何）时，才使用该方法。例如，
DateTime.Now是一个错误，应该是一个方法。有关更多详细信息，请参阅属性
使用指南在 MSDN上。顺便说一句，令人惊讶的是，自Framework 1.1以来他们就不需要更改它了。I don't see any reason why you would use a
GetXXX()method instead of a property regardless of it's modifiers.Since you tagged this question with
C#tag, I strictly recommend using the first approach. That is what properties are for.Use a method only when value returned by it can be different every time you call it regardless of it's state. For example,
DateTime.Nowwas a mistake and should have been a method.For more details refer to Property
Usage Guidelines on MSDN. On a side note, it's surprising how they haven't had a need to change it sinceFramework 1.1.使用属性而不是方法的更多原因：
A few more reasons to use properties instead of methods:
仅当类中有不可写或不可读取的属性时
Only if you have non-writable or non-readable Attributes inside the class
问题实际上并不是关于受保护的，它更多的是：为什么我应该使用属性？
属性在逻辑上与 Getter/Setter 方法对等价，无论您可以使用
Name {get{} \ set{}}做什么，都可以使用GetName() \ SetName( )配对，反之亦然，特别是 C# 有 getter 和 setter 访问器，因此我们也可以使用可访问性。但是，有些人认为公共（或受保护）属性从 OOP 的角度来看有点像作弊，特别是如果该属性所做的只是公开一个支持字段。毕竟
person.Name = "SWeko"看起来像是从外部改变了对象的状态，而person.SetName("SWeko")只是告诉对象它需要改变它的状态。从纯粹的理论角度来看，我认为这些反对意见是有道理的。然而，并不是所有人都能奢侈地生活在象牙塔里，因此属性的概念确实很有用，因为它更具可读性，不易出错，而且恕我直言，更接近现实世界的模型。它还为我们提供了一种二分法，当我写这样的东西时：
我期望第一行将是快速分配，并且不会有副作用，而我期望第二行会做更多的事情，并且可能影响物体的内部状态。当我使用 Getter 和 Setter 方法时，没有立即明显的区别：
The question is not really about
protectedit has more with: why should I use properties?Propeties are logically equivalent with Getter/Setter method pairs, whatever you can do with a with a
Name {get{} \ set{}}you can do with aGetName() \ SetName()pair and vice versa, especially as C# has getter and setter accessors, so we can play with the accessibility too.But, there are some folks that feel that public (or protected) properties are a bit like cheating from an OOP perspective, especially if all that the property does is just expose a backing field. After all
person.Name = "SWeko"seems like it changes the state of the object externally, whileperson.SetName("SWeko")merely tells the object that it needs to change it's state. And from a purely theoretic standpoint I think that those objections have merit.However, not all of us have the luxury of living in ivory towers, so the concept of properties is really usefull, as it's more readable, less error prone, and IMHO, closer to the real world model. It also provides us with a kind of dichotomy, when i write something like this:
I expect that the first line will a fast assignment, and will not have side-effects, while I expect that the second line will do something more, and probably affect the inner state of the object. When I use Getter and Setter method, no such distiction is immediately obvious: