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

Я часто нахожу себя созданием классов, которые используют эту форму (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(). Однако мне не нравится мое решение добавить суффикс "Внутренний" для защищенного метода. Я ищу более стандартизованное имя.

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

Ответы

Ответ 1

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

Ответ 2

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

В первом примере используются аспекты шаблона Template Method и аналогично тому, что Herb Sutter называет "Инимом не виртуального интерфейса":

Ответ 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
    }
  }

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

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

Ответ 4

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

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

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

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

  • Каждому классу необходимо "Завершить"
  • У разных реализаций будет свой собственный метод "Сохранить".
  • 'Complete' также выполнит некоторую проверку, уведомление и т.д.

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

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

Ответ 5

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

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

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

Cheers,
Berryl

Ответ 6

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

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

Ответ 7

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