Использование «Base» в имени класса

Question

Допустимо ли использовать слово «Base» в имени класса, являющегося нижней частью дерева наследования?

Я всегда находил это немного отговоркой, просто интересно, согласен ли кто-нибудь со мной.

Например, если я реорганизую определенные элементы из MyClassA и MyClassB в общий базовый класс, у меня возникнет соблазн создать MyBaseClass, от которого они наследуются.

Но что произойдет, если мне когда-нибудь понадобится провести рефакторинг MyBaseClass? MyBaseBaseClass? Теперь это просто глупо.

Я знаю, что Роки Лхотка не возражает против его платформы CSLA, но я всегда беспокоюсь о «определенных» в программировании.

Мысли

Позвольте мне уточнить почему Я даже беспокоюсь об этом.

У меня есть два пространства имен - MySpecificNamespace и MyCommonNamespace. MyNamespace использует MyCommonNamespace, как и следовало ожидать.

Теперь я хотел бы максимально использовать пространства имен, где это возможно, для описания контекста проблемы и избегать добавления контекста к имени класса. Так, например, учтите, что у меня есть класс в MyNamespace, который происходит от класса в MyCommonNamespace.

Вариант А

Я мог назвать это

MySpecificClass: MyClass
{
}

Но затем я добавляю 'Specific' (контекст) к имени - которое является избыточным, поскольку оно уже находится в MySpecificNamespace.

Вариант B

MyClass: MyCommonNamespace.MyClass
{
}

Вы видите, как мы можем запутаться здесь, верно?

Вариант C

Тот, кого я считаю подозрительным:

MyClass: MyBaseClass
{
}

Answer 1

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

Answer 2

Я согласен с «нет» именно по той причине рефакторинга, которую вы указали.

Класс должен быть назван в честь того, что он логически представляет, и только класс Object является действительно Base Метафизика ftw:)

---

re: Вариант B, в

нет ничего странного

namespace MySpecificNamespace
{
  MyClass: MyCommonNamespace.MyClass
  {
  }
}

Answer 3

"Все ваши базовые классы принадлежат нам."

У меня определенное нет, за одним исключением. Если вы пишете приложение для управления военными объектами или бейсбольными стадионами, сделайте это.

Answer 4

Классы с тем же именем, что и их родительские классы, беспокоят меня. В Java java.sql.Date расширяет java.util.Date. Это очень раздражает, потому что вы должны указать точный класс, который вы хотите импортировать, или указать полное имя класса (включая пакет / пространство имен).

Лично я предпочитаю называть вещи такими, какие они есть; если класс Base или Abstract существует только для обеспечения частичной реализации чего-либо и не представляет интерфейс для этой вещи, часто допустимо помещать слово Abstract или Base в его имя. Однако, если этот класс также представляет интерфейс, вам следует просто назвать его в честь того, что он делает.

Например, в Java у нас есть интерфейс Connection (для соединений с БД). Это просто называется Connection, а не IConnection. Вы используете это так:

Connection con = getConnectionFromSomewhere();

Если вы создаете драйвер JDBC и вам необходимо реализовать соединение, у вас может быть ConnectionBase или AbstractConnection, который является нижним уровнем деталей реализации вашего конкретного соединения. Вы могли бы иметь

abstract class AbstractConnection implements Connection

class OracleConnection extends AbstractConnection

или что-то в этом роде. Однако клиенты вашего кода никогда не видят AbstractConnection и OracleConnection, они видят только Connection.

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

* ps Ненавижу называть интерфейсы буквой I. Люди называют все свои классы буквой C? Это 2009! ваша IDE может сказать вам, что это за тип объекта, в нечетном случае, когда даже важно, является ли он интерфейсом или классом.

Answer 5

Я бы тоже предложил Нет, но не в камне ...

Следуя ОО-мантре, ваша система именования должна наилучшим образом представлять базовые объекты, которые код должен инкапсулировать. Там действительно не должно быть «метаязыка», связанного с фактической синтаксической структурой выбранного языка программирования.

Тем не менее, если ваш объект действительно абстрактный, и вы действительно не увидите его изменения в ближайшее время, есть аргумент, что добавление 'Base' помогает с общей читабельностью.

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

База используется где-нибудь еще?

Answer 6

Я думаю, что этот вопрос стоит задать вики.

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

Answer 7

Я тоже на стороне нет лагеря ... разместите там базу сегодня, и через 6 месяцев кто-то ударит класс MyDerivedClass в вашей кодовой базе, пока вы не ищете.

Answer 8

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

Answer 9

В Java я склонен предоставлять базовую реализацию интерфейса Foo в абстрактном классе FooBase. Я думаю, что это совершенно нормально и делает соединение с интерфейсом очень четким и регулярным.

Без интерфейса я бы назвал абстрактный базовый класс Foo.

Answer 10

"Абстрактный" префикс возможно?