Должно ли это свойство быть частью интерфейса моего объекта?

Question

У меня есть свойство IsSecureConnection, которое является частью интерфейса моего объекта. Это имеет смысл для большинства реализаций интерфейса, однако в некоторых реализациях я хотел бы сделать свойство ReadOnly.

Должен ли я опустить это свойство в интерфейсе объекта, даже если оно требуется для всех реализаций (хотя иногда немного отличается)?

Спасибо!

Answer 1

Просто добавьте геттер в интерфейс.

public interface Foo{
  bool MyMinimallyReadOnlyPropertyThatCanAlsoBeReadWrite {get;}
}

Интерфейсы определяют минимум, который объект должен реализовывать; это не говорит о том, что объект не может сделать. Для этого вам нужно изучить создание базовых классов.

Answer 2

Интерфейсы подобны соли: посыпьте их повсюду:

public interface ICanBeSecure
{
    bool IsSecureConnection { get; }
}

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

Answer 3

Это действительно зависит от того, что наиболее читабельно для ваших клиентов. Я могу придумать пару вариантов:

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) Измените семантику на , попробуйте и получите безопасное соединение, которое разработчик может просто вернуть false из:

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 4

Вам нужно оценить дело. Если не имеет смысла иметь его всегда доступным для записи, разделите его на второй интерфейс.

public interface IFoo {
   bool SecuredConnection{ get; }
}

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