Microsoft已将其作为框架设计指南,认为properties应该彼此独立并且不依赖于以任何特定顺序进行设置。

假设您有一个需要支持尺寸和面积计算的三角形类。您将如何建模?

当然,这是被认为是gauche的设计,因为Area取决于首先设置的Base和Height:

class Triangle{
    public double Base {get;set;}
    public double Height {get;set;}
    public double Area {
        get{
            return (Base * Height) / 2;
        }
    }
}

假设您使用构造函数,则可以确保这种情况的默认设置,但这是正确的方法吗?
class Triangle{
    public Triangle(double b, double h){
        Base = b;
        Height = h;
    }

    public double Base {get;set;}
    public double Height {get;set;}
    public double Area {
        get{
            return (Base * Height) / 2;
        }
    }
}

您仍然拥有一个依赖于其他属性的属性。为了成为一个纯粹主义者,我只能看到几种方法(我想可以将它们组合在一起):
  • 使基数/高度具有只读成员,这些成员只能在构造函数
  • 中设置
  • 使“面积”计算成为一种方法。
  • 使用某种工厂模式+只读成员可确保尽管可能存在依赖关系,但只能通过实例化Triangle类的方法来设置值。

  • 问题:
  • 该准则是否可行(您是否必须在类中建模很多复杂性以支持该准则)?
    [例如,SqlConnection类允许您初始化连接字符串属性,但可以更改其中的各个部分,例如命令超时]
  • 如何管理属性彼此独立?
  • Extra对于使用Silverlight/MVVM类型体系结构的人来说,由于数据绑定(bind)对对象的工作方式,您是否接受属性的依赖关系?例如,绑定(bind)一个三角形实例,该实例在屏幕上显示高度,底部和面积。
  • 最佳答案

    微软实际上是在试图说“不要以这样的方式设计您的类,即以任意顺序调用属性会导致意外的行为。”此类的用户不会期望请求值(使用属性)会产生尴尬的副作用。

    这属于最不惊奇的原则。

    我认为这是一个完全实用的指南。属性不应有意外的副作用。

    您提出了一个很好的问题:“如何管理属性彼此独立?”。很小心!我尽可能消除状态(并相应减少属性的数量)。另外,通过分解类来划分状态是另一种策略。就这本身而言,这将是一个很好的问题...

    就三角形类而言,我认为您在代码中提出的两种解决方案都是有效的。如果要由我决定,我将设计三角形,使其不可变,并在构造函数中采用宽度和高度。

    关于C#基础知识使属性成为原子,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/1413658/

    10-09 08:18
    查看更多