如何命名纯虚拟受保护属性答案

【问题标题】：How to name pure virtual protected property如何命名纯虚拟受保护属性
【发布时间】：2009-04-23 11:53:05
【问题描述】：

前言：

我有一个组件，我们称之为 IView。该组件由 BaseView 类实现，该类拥有它的大部分功能。我们使用模板模式将逻辑委托给继承类。

问题：

我们有一个名为 IView.Visible 的属性，它指示组件是否应该可见。这个属性不是虚拟的，因为它涉及我们 BaseView 中的一些逻辑。

我们创建了一个虚拟保护方法 IsVisible，从 BaseView.Visible 调用它来决定 IView.Visible 的最终值。

我们觉得这个属性名称 IsVisible 对于派生类的实现者来说描述性和清晰性不够。

有人建议将其重命名为 ShouldBeVisible，但我们仍然填写有更好的名称。

你怎么看？你有更好的名字吗？是否有涵盖模板方法这一主题的良好命名约定？

更新： 澄清一点，Visible 和 IsVisible 属性对组件没有副作用，Visible 属性使用 IsVisible 中的值来决定 Visible 的值是否应该是是的，但它不是唯一的考虑因素，并且还结合了组件的其他内部状态来给出最终判断。

【问题讨论】：

【解决方案1】：

我从来没有特别热衷于这种命名约定，但Framework Design Guidelines 书建议使用“Core”作为这种模式的后缀。此代码取自 Microsoft System.Windows.Forms.Control 类

public bool CanSelect
{
    get
    {
        return this.CanSelectCore();
    }
}

internal virtual bool CanSelectCore()
{
    ...
}

我对这个解决方案的担忧是，您公开了一种未知复杂性的方法，并可能会产生副作用作为属性，但是由于您可以翻阅 .NET 框架代码并发现如果您正在寻找这种约定经常使用对于一个标准，这可能与您得到的一样接近。

【讨论】：

【解决方案2】：

这个问题没有“对”或“错”，只有“更好”或“更差”。

就我个人而言，我会将“涉及某些逻辑”的属性设为 GetVisible() 方法，以明确存在某些逻辑（即使它也可以是属性那么简单）。

持有信息的属性可能只是可见的。

这就像理解不同的成员：属性是数据（或数据的幻觉），方法是逻辑。

【讨论】：

【解决方案3】：

基类是实现属性还是打算由继承类实现，即它是抽象的吗？我的第一个想法是它应该像在继承类中一样命名。如果它控制类输出是否可见，那么 Visible 似乎是正确的名称。至少在我看来，这个名称不应该反映实现，而是反映目的。

【讨论】：

【解决方案4】：

我认为“虚拟保护”确实足以达到目的，它已经指定它可以并且将在某个时候被覆盖并由子类访问。

命名不应该太大，以便一次又一次地编码，并且 IsVisible 是标准的命名方式。它也应该属于正确的英语。 ShouldBeVisible 听起来像是某种条件/验证，而不是属性。

成员的名字应该只描述目的而不是逻辑或过于技术性的细节，这只会让名字越来越大。

【讨论】：

【解决方案5】：

由于所考虑的方法是 Visible 的继承类的实现，如果必须的话，我会使用可怕的丑陋但非常具有描述性的名称 VisibleImplementation 或 VisibleImpl。这让开发人员非常清楚，这是他要实现使组件可见或不可见的逻辑的地方。

 protected bool VisibleImplementation()  { ... }

或者，您可以给它赋予相同的名称 Visible 并要求它采用布尔参数，指示它是否从基本实现中调用。就个人而言，我不喜欢仅仅为了区分方法而引入参数，但有时你必须做出妥协。

 protected bool Visible( boolean fromBase ) { ... }

【讨论】：