“Getter/Setter 中的值验证”是好的风格吗？

Question

我的 Getter/Setter 方法在设置/返回之前检查值。当值无效时，它们会抛出异常（BadArgumentException 或 IllegalStateException）。这是必需的，因为我们使用无效值初始化所有成员 - 因此我们避免使用这些无效值（== 在其他地方出现错误/段错误/异常）。

好处是：

• 当您从模型收到成员值时，您就知道它们是有效的
• 有效性检查仅在模型对象中执行
• 值范围在模型对象中定义

这似乎很不寻常，因为大多数新团队成员首先抱怨它——即使在我向他们解释后他们同意我的看法。

问题：这是一种好的编程风格吗？ （即使浪费一点性能）

示例代码：

inline bool MyClass::HasGroupID const { return m_iGroupID != 0; }

int MyClass::GetGroupID() const
{
    if( !HasGroupID() )
        throw EPTIllegalStateException( "Cannot access uninitialized group ID!" );

    return m_iGroupID;

}   // END GetGroupID() const

void MyClass::SetGroupID( int iGroupID )
{
    // negative IDs are allowed!
    if( iGroupID != 0 )
        throw EPTBadArgumentException( "GroupID must not be zero!", iGroupID );

    m_iGroupID = iGroupID;

}   // END SetGroupID( int )

用法：

// in serialization
if( myObject.HasGroupID() )
    rStream.writeAttribute( "groupid", GetGroupID() );

// in de-serialization
try {
    // required attribute - throw exception if value is invalid
    myObject.SetGroupID( rStream.GetIntegerAttribute( "groupid" );
} catch( EPTBadArgumentException& rException )
{
    throw EPTBadXmlAttribute( fileName, rException );
}

Answer 1

关于验证：Setter 验证类不变量是否受到尊重是非常常见的（实际上，与公共值相比，这是它们的大部分附加值）。这在 Getters 中是最不寻常的（延迟验证对于调试来说是地狱），但在 Debug 构建中，在那个阶段重新验证可能会很有趣，只是为了捕获更多错误。

但是，这不是您在这里所做的。您的类 Invariant 显然允许一个可选元素（如GroupId），但您禁止用户将此GroupId 设置为无效状态...为什么！？这是不规则的。

关于 Getter，有一个简单的解决方案：可选类型（如 Boost.Optional）。这样一来，您始终可以毫无例外地返回，但您可以提供一个值......或者不提供。

Answer 2

我会同意你的新团队成员。对我来说，这并不常见，但如果你必须这样做并且这是唯一的方法，你应该这样做。
我会尝试制作填充有一致性数据的对象。
您可以通过检查构造函数中的值并且不提供设置器来达到此目的。
首先我为编写 C# 找借口，但我的 C++ 有点生疏:-)

class MyClass{

    private int groupId; 

    public MyClass(int groupId) {
        if(groupId ==0){
            throw new ArgumentOutOfRangeException("groupId",groupId,"Group Id must be >0");
        }
        this.groupId = groupId;
    }

    public int GroupId{ 
        get{ 
             return groupId;
        }
    }
}

现在您可以确定，MyClass 类只有在所有属性都符合它们的要求时才会被初始化。您可以实现一个构造函数，它采用 MyClass 实例并克隆所有值以创建克隆对象。
如果您需要更改属性，请创建一个接口并定义一个MyClassChangeable

public class Programm {
    static void main(string[] args) {
        IMyClass myClassChangable = new MyClassChangable(-123);
        try {
            MyClass correctMyClass = new MyClass(myClassChangable);
            useThisClass(correctMyClass);

        } catch (Exception ex) {
            //Display to user or something
            Debug.WriteLine(ex);
        }
    }

    static void useThisClass(MyClass myClass) {
        //this is alway correct!
        int groupId = myClass.GroupId;

    }
}

interface IMyClass {
    int GroupId { get; }
}

class MyClass : IMyClass {
    private int groupId;

    public MyClass(int groupId) {
        if (groupId == 0) {
            throw new ArgumentOutOfRangeException("groupId", groupId, "Group Id must be >0");
        }
        this.groupId = groupId;
    }

    public MyClass(IMyClass instance)
        : this(instance.GroupId) {
    }

    #region Implementation of IMyClass

    public int GroupId {
        get { return groupId; }
    }

    #endregion
}


public class MyClassChangable : IMyClass {
    private int groupId = 0;

    public MyClassChangable() {

    }

    public MyClassChangable(int groupId) {
        this.groupId = groupId;
    }

    #region Implementation of IMyClass

    public int GroupId {
        get { return groupId; }
        set { groupId = value; }
    }

    #endregion
}

你现在可以使用你想使用的类，而不是只在一个点“检查”它（所以一个异常点）。在“BusinessCore”中，您使用的是始终具有正确值的 MyClass。所以没有例外，也没有OutOfBounds！
希望我能提供帮助，如果您有其他问题或有什么问题，请与我联系，很高兴学习！
我很乐意收到对我的想法的反馈！

Answer 3

我认为这是一种常见的风格，它肯定是第一个想法中 getter/setter 的核心动机之一。但是，在您的特定示例中，我认为它们没有意义，而且我认为通常有更好的选择：

如果调用GetGroupID 引发异常，如果HasGroupID 产生错误，那么这是一个程序员错误 - 所以你应该使用assert。事实上，为什么一开始就可能有一个没有组 ID 的对象呢？这听起来有点不雅。

此外，如果只有非零 ID 是有效的，那么您应该尝试使用专用类型更早地强制执行此限制。这样，所有处理组 ID 的代码都可以确保 ID 是有效的（事实上，编译器强制执行此操作！）并且您不可能忘记在某个地方进行检查。考虑：

class GroupID {
public:
    explicit GroupID( int id ) : m_id( id ) {
        if ( m_id == 0 ) {
            throw EPTBadArgumentException( "GroupID must not be zero!", m_id );
        }
    }

    // You may want to allow implicit conversion or rather use an explicit getter
    operator int() const { return m_id; }
};

使用这个，你可以写

void MyClass::SetGroupID( GroupID id )
{
    // No error checking needed; we *know* it's valid, because it's a GroupID!
    // We can also use a less verbose variable name without losing readability
    // because the type name reveals the semantics.
    m_iGroupID = id;

} // END SetGroupID( int )

事实上，由于组 ID 现在是专用类型，您可以将函数重命名为 Set 并使用重载。所以你有MyClass::Set(UserID)和MyClass::Set(GroupID)等等。

Answer 4

本质上，这是 getter/setter 理念最重要的目的之一。封装本身是不舒服的——编写只访问成员变量的简单代码更容易。但是通过封装，您可以限制对变量的访问：完整性检查值、通过互斥锁同步访问、将更改绑定到触发器、记录它们等等。

通常，在最基本的情况下，这些都不是必需的，但后来会出现数量惊人的这些新芽，如果您一直在摆弄班级成员，那么有很多代码需要修复。如果您从一开始就到处使用简单的 getter/setter，那么现在您可以向它们添加任何您需要的东西。