Как назвать чисто виртуальное защищенное свойство

Question

предисловие:

У меня есть компонент, давайте назовем его IView. Этот компонент реализован классом BaseView, который содержит большую часть его функциональных возможностей. Мы используем шаблон шаблона, чтобы делегировать логику наследующим классам.

Проблема:

У нас есть свойство с именем IView.Visible, которое указывает, должен ли компонент быть видимым или нет. Это свойство не является виртуальным , поскольку оно включает некоторую логику в нашем BaseView.

Мы создали виртуальный защищенный метод IsVisible , который вызывается из BaseView.Visible для определения окончательного значения IView.Visible.

Мы считаем, что это имя свойства, IsVisible, не является описательным и достаточно понятным для разработчика производного класса.

Было предложено переименовать его в ShouldBeVisible, но мы все же заполняем, что есть лучшее имя.

Что ты думаешь? У тебя есть лучшее имя? Есть хорошее соглашение об именах, которое охватывает эту тему методов шаблона?

---

Обновление: Просто чтобы прояснить ситуацию, свойства Visible и IsVisible не оказывают побочного эффекта на компонент, свойство Visible использует значение из IsVisible, чтобы решить, должно ли значение Visible быть истинным , но это не единственное соображение и пара других внутренних состояний компонента, чтобы дать окончательный вердикт.

Answer 1

Я никогда особо не интересовался этим соглашением об именах, но в книге Framework Design Guidelines предлагается использовать "Core" в качестве суффикса для этого типа шаблона. Этот код взят из класса Microsoft System.Windows.Forms.Control

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

internal virtual bool CanSelectCore()
{
    ...
}

Мое беспокойство в связи с этим решением заключается в том, что вы представляете метод неизвестной сложности с возможными побочными эффектами в качестве свойства, но поскольку вы можете порыться в коде платформы .NET и увидеть, что это соглашение используется довольно часто, если вы ищете для стандарта это может быть как можно ближе.

Answer 2

Поскольку рассматриваемый метод является реализацией класса Visible, наследуемой классом, я бы использовал ужасное, но очень описательное имя VisibleImplementation или VisibleImpl, если необходимо. Для разработчика очень ясно, что именно здесь он должен реализовать свою логику для того, чтобы сделать компонент видимым или нет.

 protected bool VisibleImplementation()  { ... }

В качестве альтернативы, вы можете присвоить ему то же имя Visible и потребовать, чтобы он принял логический параметр, указывающий, вызывается ли он из базовой реализации. Лично мне не нравится вводить параметры только для того, чтобы различать методы, но иногда приходится идти на компромиссы.

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

Answer 3

Реализует ли базовый класс свойство или оно должно быть реализовано наследующим классом, т. Е. Является ли оно абстрактным? Моя первая мысль заключается в том, что он должен быть назван так, как он будет в унаследованном классе. Если он контролирует, будет ли вывод класса видимым, тогда Visible будет выглядеть как правильное имя. Имя не должно, по крайней мере, на мой взгляд, отражать реализацию, а не цель.

Answer 4

Я думаю, что "виртуальная защита" действительно подходит для этой цели, она уже указывает, что она может и будет переопределена когда-нибудь и к ней будут обращаться дочерние классы.

Имена не должны быть слишком большими, чтобы кодировать снова и снова, а также IsVisible является стандартным способом именования. Также это должно подпадать под правильный английский. Должно быть BeBeVisible звучит так, будто это какое-то условие / проверка, а не свойство.

Имя члена должно только описывать цель, а не логику или слишком технические детали, которые только сделают имена больше и больше.

Answer 5

В этом вопросе нет «правильного» или «неправильного», только «лучше» или «хуже».

Лично я бы сделал Свойство, которое «включает в себя некоторую логику», методом GetVisible (), чтобы прояснить, что есть некоторая логика (даже если она настолько проста, что это также может быть свойство).

Свойство, содержащее информацию, может быть просто видимым.

Это похоже на понимание разных членов: свойство - это данные (или иллюзия данных), а методы - логика.