该属性应该是我对象界面的一部分吗？ [英] Should this property be part of my object's interface?

问题描述

我有一个名为IsSecureConnection的属性，它是我对象界面的一部分。这对于接口的大多数实现都是有意义的，但是，在某些实现中，我想使属性ReadOnly。

I have a property called "IsSecureConnection" that is part of my object's interface. This makes sense for most implementations of the interface, however, in some implementations I would like to make the property ReadOnly.

我是否应该从对象的界面中省略这个属性，即使所有实现都需要它（虽然稍有不同）？

Should I omit this property from the object's interface even though it is required by all of the implementations (though slightly different on occasion)?

谢谢！

推荐答案

这取决于您的客户最可读的内容。我可以想到几个选项：

It really depends on what's most readable for your clients. I can think of a couple of options:

1）继承的界面，虽然我不是隐藏的粉丝，我认为它让它有点难看要实现的任何VB.NET或显式客户端：

1) The inherited interface, though I'm not a fan of hiding, and I think it makes it a bit ugly for any VB.NET or explicit clients to implement:

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

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

2）从属性中拆分集合，并使用继承的接口：

2) Split the set from the property, with an inherited interface:

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

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

3）将语义更改为尝试并获取安全连接，实现者可以自由地返回false：

3) Changing the semantics to try and acquire a secure connection, which an implementer is free to just return false from:

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

4）添加额外的支票属性：

4) Add an additional check property:

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

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

All of these are, IMO, valid designs for certain contexts. Since I don't have any info on the use cases, except that almost all of the time a secure connection can be established - I'd probably vote for 3. It's easy to implement, there's only 1 code path for clients, and there's no exception mechanism (which is another form of coupling). You do have the danger of clients not checking the return from TrySecureConnection, but I think it has less issues than the other choices.

如果客户更喜欢一个安全的连接，但不要要求一个 - 然后1的缺点是需要重载或客户端检查他们的IObject是否真的是一个ISecurableObject。两者都有点难看。 2有同样的问题，但没有麻烦的新/阴影技巧。但是，如果某些客户端需要安全连接，则此（或2）可能是要走的路 - 否则，您无法真正使用类型安全来强制执行安全连接。

If clients prefer a secure connection, but don't require one - then 1 has the disadvantage of either requiring overloads or the client to check if their IObject is really a ISecurableObject. Both of which are kind of ugly. 2 has the same problem, but without the troublesome new/shadows trickery. However, if some clients require a secure connection, then this (or 2) is probably the way to go - otherwise, you can't really use type safety to enforce a securable connection.

4，虽然有效的设计IMO（有些人不同意 - 看到对IO.Stream的反应）很容易让客户出错。如果90％的实施者都是安全的，那么很容易不检查SupportsSecureConnection。还有一个实现者选择抛出异常或丢弃IsSecureConnection = true调用（如果它不受支持），要求客户端捕获并检查IsSecureConnection的新值。

4, while a valid design IMO (some would disagree - see reactions to IO.Stream) is easy for clients to get wrong. If 90% of implementers are securable, it's easy to not check the SupportsSecureConnection. There's also an implementer's choice of either throwing an exception or discarding the IsSecureConnection = true call if it's not supported, requiring clients to both catch and check the new value of IsSecureConnection.

这篇关于该属性应该是我对象界面的一部分吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！