这个属性应该是我的对象接口的一部分吗？

Question

我有一个名为“IsSecureConnection”属性是我的对象的接口的一部分。这对于接口的大部分实现来说都是有意义的，但是在一些实现中，我想使属性ReadOnly成为可能。

即使所有实现都需要该属性（尽管有时略有不同），我是否应该从该对象的接口中省略该属性？

谢谢！

Answer 1

这实际上取决于您的客户最具可读性。我可以想到几个选项：

1）继承的接口，虽然我不是一个隐藏的粉丝，我认为它使任何VB.NET或显式客户端实现它有点丑陋：

interface IObject { 
    bool IsSecureConnection { get; } 
    // ... other interface definitions // 
} 

interface ISecurableObject : IObject { 
    new bool IsSecureConnection { get; set; } 
} 

2）从属性拆分组，具有遗传接口：

interface IObject { 
    bool IsSecureConnection { get; } 
    // ... other interface definitions // 
} 

interface ISecurableObject : IObject { 
    void SetConnectionSecurity(bool isSecure); 
} 

3）改变语义尝试并获得可靠的连接，其实施者是免费的，只是回报错误来自：

interface ISecurable { 
    bool IsSecureConnection { get; } 
    bool TrySecureConnection(); 
} 

4）添加额外的检查属性：

interface ISecurable { 
    bool IsSecureConnection { get; set; } 
    bool SupportsSecureConnection { get; } 
} 

所有这些都是，IMO，某些情况下是有效的设计。由于我没有关于用例的任何信息，除了几乎所有的时候都可以建立安全连接 - 我可能会投3票。这很容易实现，客户端只有1个代码路径，并且有没有例外机制（这是另一种形式的耦合）。您确实有客户不检查TrySecureConnection返回的危险，但我认为它的问题比其他选择少。

如果客户喜欢的安全连接，但不要要求一个 - 然后1有任何需要过载或客户端的缺点，以检查是否他们的IObject提取真是ISecurableObject。这两种都很丑陋。 2有同样的问题，但没有麻烦的新/阴影诡计。但是，如果某些客户端需要安全连接，那么这个（或2）可能就是要走的路 - 否则，您无法真正使用类型安全来强制实施安全连接。

4，虽然一个有效的设计IMO（有些人会不同意 - 见IO.Stream的反应）很容易让客户错误。如果90％的实施者是安全的，则不容易检查SupportsSecureConnection。实施者还可以选择抛出异常，或者在不支持IsSecureConnection = true的情况下抛出异常，要求客户端捕获并检查IsSecureConnection的新值。

Answer 2

只需在界面中添加getter即可。

public interface Foo{ 
    bool MyMinimallyReadOnlyPropertyThatCanAlsoBeReadWrite {get;} 
} 

接口指定对象必须实现的最小值;它没有说明一个对象不能做什么。为此，您需要查看创建基类。

Answer 3

接口是像盐：到处撒上：

public interface ICanBeSecure 
{ 
    bool IsSecureConnection { get; } 
} 

public interface IIsSecureable : ICanBeSecure 
{ 
    bool IsSecureConnection { get; set;} 
} 

Answer 4

你需要评估的情况。如果它总是可写的没有意义，请将其分隔为第二个界面。

public interface IFoo { 
    bool SecuredConnection{ get; } 
} 

public interface ISecurableOptionFoo: IFoo { 
    bool SecuredConnection{ get; set; } 
}