Соглашение об именах для не виртуальных и абстрактных методов

Question

Я часто создаю классы, которые используют эту форму (A):

abstract class Animal {
  public void Walk() {
    // TODO: do something before walking

    // custom logic implemented by each subclass
    WalkInternal();

    // TODO: do something after walking
  }
  protected abstract void WalkInternal();
}

class Dog : Animal {
  protected override void WalkInternal() {
    // TODO: walk with 4 legs
  }
}

class Bird : Animal {
  protected override void WalkInternal() {
    // TODO: walk with 2 legs
  }
}

Вместо этой формы (B):

abstract class Animal {
  public abstract void Walk();
}

class Dog : Animal {
  public override void Walk() {
    // TODO: do something before walking

    // custom logic implemented by each subclass
    // TODO: walk with 4 legs

    // TODO: do something after walking
  }
}

class Bird : Animal {
  public override void Walk() {
    // TODO: do something before walking

    // custom logic implemented by each subclass
    // TODO: walk with 2 legs

    // TODO: do something after walking
  }
}

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

Каково стандартное соглашение для именования этих методов?
Мне нравится называть публичный метод Walk с тех пор, как я могу назвать Dog.Walk(), который выглядит лучше, чем Dog.WalkExternal(). Однако мне не нравится мое решение добавить суффикс "Внутренний" для защищенного метода. Я ищу более стандартизированное имя.

Кстати, есть имя для этого шаблона дизайна?

Answer 1

Я не уверен, существует ли стандартное соглашение об именах для этого.Помимо WalkInternal, другие альтернативы могут быть DoWalk или WalkImpl.

Answer 2

Кстати, есть ли название для этого шаблона проектирования?

Ваш первый пример использует аспекты шаблона Template Method и похож на то, что Херб Саттер называет «Не виртуальный интерфейсИдиома ":

• http://www.gotw.ca/publications/mill18.htm

Answer 3

Я предпочитаю называть свои виртуальные или абстрактные методы суффиксом Core, чтобы указать, что метод должен содержать основную логику, чтобы что-то делать.

Все проверки аргументов и создание возможных событий, которые я делаю в методе, который вызывает Core-Methods.

  abstract class Animal {
    public void Walk() {
      // TODO: do something before walking 
      // possible Argument checks and event raising

      // custom logic implemented by each subclass
      WalkCore();

      // TODO: do something after walking
    }

    protected abstract void WalkCore();
  }

  class Dog : Animal {
    protected override void WalkCore() {
      // TODO: walk with 4 legs
    }
  }

  class Bird : Animal {
    protected override void WalkCore() {
      // TODO: walk with 2 legs
    }
  }

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

"Руководство по проектированию платформы" предлагает использовать суффикс Core , если вы следуете методу шаблона и хотите указать точки расширяемости.

Answer 4

Хороший вопрос. Шаблон действителен, и я часто его использую. Я также согласен с тем, что WalkInternal не является идеальным именем.

В этом примере я считаю, что вы неправильно формулируете проблему.

Вместо того, чтобы переименовывать «внутренний» метод, посмотрите на ваш «внешний» публичный метод. Он называется Walk, но у него есть фрагменты кода (//do something before walking и //do something after walking), которые ясно показывают, что он содержит больше, чем просто логику для «ходьбы». Возможно, этот метод должен называться Exercise или GoToTheShops - или любое другое творческое имя, которое вы можете придумать, которое описывает то, что вы делаете. Каким бы ни был метод, это определенно расширенный набор «Ходьбы» + некоторые другие действия до / после прогулки.

В похожем примере, который я недавно разработал, был открытый метод Complete и виртуальный Save, так что

• Каждый класс, необходимый для завершения,
• Различные реализации будут иметь свой собственный метод «Сохранить»
• «Complete» также выполнит некоторую проверку, уведомление и т. Д.

Таким образом, абстрактный метод должен называться Walk, и вместо этого вы должны переименовать ваш публичный метод во что-то, что более точно описывает процесс «что-то сделать / пройти / сделать что-то».

---

edit: Если класс Walk не добавляет какого-либо значительного значения или логики к классу WalkInternal, я бы спросил, требуется ли это. Если он добавляет логику, его следует переименовать, чтобы отразить его новую функцию.

Answer 5

Я использую условное обозначение подчеркивания с заглавной буквы для абстрактных переопределений, поэтому Dog._Walk, хотя мне более чем иногда интересно, не было ли лучшего способа.

Мне нравится DoWalk лучше, чем WalkInternal - он короче и передает идею о том, что переопределение происходит быстро и заранее. «Делать» все, что угодно, втирает меня не в ту сторону, хотя вроде как «Мой» объект. Мне больше нравится мое подчеркивание, за которым следует заглавная буква.

Хороший вопрос из реальной жизни, хотя

Приветствия
Berryl

Answer 6

Для метода, который обеспечивает основное поведение метода шаблона, я использую имена вроде WalkOverride.Базовый класс реализует его как метод protected abstract (производный класс требуется для обеспечения реализации) или protected virtual пустой / непустой (производный класс может необязательно обеспечивать/ переопределить реализацию).Примеры можно найти в различных платформах Microsoft XAML с такими методами, как MeasureOverride и ArrangeOverride.(Шаблон WalkCore, о котором упоминает @Jehof, используется для именования самого метода шаблона.)

Для «событий», на которые производный класс может необязательно отвечать для своих собственных целей (какв отличие от определения поведения метода шаблона), я использую такие имена, как OnWalking и OnWalked.Каждый из них обычно реализуется в базовом классе как метод protected virtual с пустым телом метода.

Answer 7

Методы - это средство для принятия действий и использования этого правила. Имена методов должны быть либо глагольными, либо глагольными фразами. И это применимо к методам независимо от того, где они объявлены. Для меня Dog.Walk выглядит более естественно, чем Dog.WalkInternal.Andда, именование метода - это скорее руководство, чем шаблон проектирования :). Если вы парень .Net, то я порекомендую книгу «Framework Design GuideLines» Брэда Адама и Кшистофа Квалина, в которой четко рассматриваются такие проблемы.