Является ли использование «базовой» плохой практики, хотя это может быть полезно для читабельности? - PullRequest
12 голосов
/ 26 июня 2009

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

base.DoCommonBaseBehaviorThing();

Хотя я ценю менталитет «чем меньше, тем лучше», я также потратил много времени на отладку / поддержку приложений с высокой цепочкой, и чувствую, что это может помочь узнать, что вызов члена является базовым объектом, просто посмотрев на него. Конечно, достаточно просто изменить правила ReSharper, но что вы думаете? Нужно ли использовать "базу" при вызове членов базы?

Ответы [ 5 ]

22 голосов
/ 26 июня 2009

Единственный раз, когда вы должны использовать base.MethodCall();, это когда у вас есть переопределенный метод с тем же именем в дочернем классе, но вы действительно хотите вызвать метод в родительском классе.

Для всех остальных случаев просто используйте MethodCall();.

Ключевые слова, такие как this и base, не делают код более читабельным, и его следует избегать во всех случаях , если они не необходимы - например, в случае, который я описал выше.

17 голосов
/ 26 июня 2009

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

6 голосов
/ 26 июня 2009

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

Во время предварительной обработки звонков с этим. не будет делать ничего, кроме уменьшения / увеличения читабельности (игнорируя ситуацию, когда две переменные в области имеют одно и то же имя) базы. Префикс изменит функциональность кода, который вы пишете во многих распространенных сценариях. Так что я бы никогда не добавил базу. если не требуется.

4 голосов
/ 26 июня 2009

Я думаю, что в общем случае вы должны использовать base только при переопределении предыдущей функциональности.

Некоторые языки (C # не) также предоставляют эту функцию, вызывая функцию по имени ее базового класса в явном виде, например: Foo.common() (конечно, вызывается откуда-то из Bar).

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

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

3 голосов
/ 26 июня 2009

Это действительно вопрос личных предпочтений. Если вам нравится видеть "базу". в начале ваших участников вы можете легко отключить правило (выберите «Параметры»> «Уровень проверки»> «Избыточность кода»> «Резервный базовый»). Не позволяйте правилам статического анализа, не относящимся к поведению, влиять на предпочитаемый стиль кодирования.

EDIT

Следует учитывать, что статический анализ кода в FXCop и R # предоставляет правила для всех возможных нужд. Фактически придерживаться всех правил одновременно немного обременительно. Вы должны определить предпочитаемый стиль кодирования (если вы работаете в команде, делайте это коллективно) и придерживаться его. Измените правила так, чтобы они соответствовали вашим стандартам кодирования, а не наоборот.

...