Использование "Base" в имени класса
Допустимо ли использовать слово "Base" в имени класса, которое является нижней частью дерева наследования?
Я всегда находил это немного отговоркой, просто интересно, согласен ли кто-нибудь со мной.
Например, если я реорганизую определенные элементы из MyClassA и MyClassB в общий базовый класс, у меня возникнет соблазн создать MyBaseClass, от которого эти два объекта наследуются.
Но что произойдет, если мне когда-нибудь понадобится рефакторинг MyBaseClass? MyBaseBaseClass? Теперь это просто глупо.
Я знаю, что Роки Лхотка не возражает против его платформы CSLA, но я всегда беспокоюсь о "определенных" в программировании.
Мысли?
Позвольте мне объяснить, почему я даже беспокоюсь об этом.
У меня есть два пространства имен - MySpecificNamespace и MyCommonNamespace. MyNamespace использует MyCommonNamespace, как и следовало ожидать.
Теперь я хотел бы максимально использовать пространства имен везде, где это возможно, для описания контекста проблемы и избегать добавления контекста к имени класса. Так, например, учтите, что у меня есть класс в MyNamespace, который происходит от класса в MyCommonNamespace.
Вариант А
Я мог бы назвать это
MySpecificClass: MyClass
{
}
Но затем я добавляю "Specific" (контекст) к имени - которое является избыточным, поскольку оно уже находится в MySpecificNamespace.
Вариант Б
MyClass: MyCommonNamespace.MyClass
{
}
Вы можете видеть, как мы могли запутаться здесь, верно?
Вариант С
Я думаю, что это подозрительно
MyClass: MyBaseClass
{
}
12 ответов
Я склонен добавлять суффикс Base к имени базового класса только в том случае, если он существует с технической точки зрения (для совместного использования некоторого кода) и на самом деле не представляет собой какой-либо пригодный для использования класс (поэтому все эти классы являются абстрактными). Это довольно редкие случаи, и их следует избегать так же, как и вспомогательные классы.
"Все ваши BaseClass принадлежат нам".
Я на стороне категорического нет, за одним исключением. Если вы пишете приложение для управления военными объектами или бейсбольными стадионами, сделайте это.
Я согласен с "нет" именно по той причине рефакторинга, которую вы указали.
Класс должен быть назван в честь того, что он логически представляет, и только класс Object на самом деле является базовым. Метафизика фтв:)
Re: Вариант B, ничего не смущает
namespace MySpecificNamespace
{
MyClass: MyCommonNamespace.MyClass
{
}
}
Классы, имена которых совпадают с именами родительских классов, беспокоят меня. В 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 может сказать вам, что это за тип объекта, в нечетном случае, когда даже имеет значение, является ли он интерфейсом или классом.
Я думаю, что этот вопрос стоит википедии.
FWIW, я согласен. Я обычно пытаюсь найти более "общий" термин для моих базовых классов. Поэтому, если у меня есть класс "Клиент" и мне нужно ввести новый базовый класс, я бы выбрал "Контакт" или что-то в этом роде, а не "Клиентская база".
Я бы тоже предложил Нет, но не в камне...
Следуя ОО-мантре, ваша система именования должна наилучшим образом представлять базовые объекты, которые код должен инкапсулировать. Там действительно не должно быть "метаязыка", связанного с фактической синтаксической структурой языка программирования там.
Тем не менее, если ваш объект действительно абстрактный, и вы действительно не увидите его изменения в ближайшее время, есть аргумент, что добавление "Base" помогает с общей читабельностью.
Как и в большинстве случаев, нет правильного и неправильного ответа - это зависит от общей компоновки вашей кодовой базы, того, что должен представлять этот конкретный код, и от того, какой у вас внутренний стиль. Просто постарайтесь быть последовательным.
База используется где-нибудь еще?
Я также согласен с тем, что нет лагеря... разместите там базу сегодня, и через 6 месяцев кто-то ударит класс MyDerivedClass в вашей кодовой базе, пока вы не ищете.
В Java я обычно предоставляю базовую реализацию интерфейса Foo в абстрактном классе FooBase. Я думаю, что это нормально, и делает соединение с интерфейсом очень четким и регулярным.
Без интерфейса я бы назвал абстрактный базовый класс Foo.
Я согласен, AbstractFoo - достойное решение. Я пытаюсь выбрать имена, которые не нуждаются в дополнительных прилагательных. Я бы уклонился от использования базы.
Обычно я использую IFoo для интерфейса и AbstractFoo для скелетной реализации, представляющей собой смесь соглашений.NET и Java.
Похоже, что любой принципиальный ответ в конечном итоге окажется отрицательным... Однако запятая, когда я смотрю на код, с которым я не особо знаком, что часто случается в python (где исходный код иногда является единственной надежной документацией.), Я считаю очень полезным, когда в классе Baseв этом. Python отличается от других объектно-ориентированных языков, в которых класс определен с помощью спецификатора "абстрактный" или "интерфейс". Что касается именования, мне нравится спрашивать себя: "Если бы я никогда раньше не видел этот код, как мне было бы легче понять этот код?" (Затем, в зависимости от того, насколько я ленив, я называю это соответствующим образом).
Я думаю, что, вероятно, следует по возможности избегать в пользу идентификатора, который фактически описывает, что это такое!
На этот вопрос сложно ответить, потому что он абстрактный. Я мог бы, например, рассмотреть возможность вызова базы MyClassA и MyClassB "MyClass".