【是不是可以用属性代替方法，有何利弊】

【是否可以用属性代替方法，有何利弊】
下面是一个只读属性：

[解决办法]
从#2楼起都是对的，属性本来就是方法。使用set、get两个方法来屏蔽了对private了的字段的访问。只不过c#（以及vb.net）把这两个方法封装的跟字段似地。这样你先实现为字段然后以后需要时直截了当地重构为属性，而访问它的代码却不需要修改（只需要重新编译）。

比如说Timers.Timer就有一个Enable属性，当设置它的时候就调用了Start或者Stop方法。可见为属性设置值可以一定程度上替代方法。

不过不要把任何事情绝对化。自然才是最好的。比如说Timer并没有因此就删除了Start和Stop方法，因为那两个已经是公开的方法、有人访问了，设计者就不应该轻易地因为有了属性而删除了方法。
------解决方案-------------------- 
 
如果说到属性中过于“充血”的弊端，其实也很多例子。究其原因就是“功能抖动”的问题。

这往往跟不同框架也有关系。例如asp.net的机制是“一次次下载html”的机制，假设一个对象有10个属性，你是否会在任意一个属性被修改时立刻去重新DataBind整个页面呢？还是修改了所有属性之后仅仅在下载html之前的某个事件中才去执行一次页面DataBind呢？前者就可以在属性中调用DataBind，而后者就要把DataBind移出来，另外循着页面生命期的其它机关去部署这个DataBind语句。

显然，假设框架比较死（不能灵活地在客户端所见即所得），或者问了其它设计原因，你需要避免在属性中调用方法，而是在它应该被执行的时候才被执行。
[解决办法]
再举一个非常“喜欢”在属性中被调用的例子（实际上是触发事件，当然调用委托跟调用其它方法也差不多），就不多写了，看msdn：http://msdn.microsoft.com/zh-cn/library/system.componentmodel.inotifypropertychanged.aspx
[解决办法]
引用:
没什么区别

http://www.cnblogs.com/flashicp/archive/2007/03/20/681287.html

但 属性充分体现了对象的封装性：不直接操作类的数据内容，而是通过访问器进行访问，即借助于get和set对属性的值进行读写；另一方面还可以对数据的访问属性进行控制

属性vs.函数

l       相似点

? ……


+1