Можно ли использовать слово Base в имени класса, которое является дном дерева наследования?
Я всегда находил, что это немного покончил, просто интересно, согласен ли кто-нибудь со мной.
Например, если я реорганизую некоторые элементы из MyClassA и MyClassB в общий базовый класс, у меня возникнет соблазн создать MyBaseClass, из которого они наследуют.
Но что произойдет, если мне когда-нибудь понадобится рефакторинг MyBaseClass? MyBaseBaseClass? Теперь это просто глупо.
Я знаю, что Rocky Lhotka не возражает против своей структуры CSLA, но я всегда беспокоюсь о "определенных" в программировании.
Мысли?
Позвольте мне пояснить, почему я даже беспокоюсь об этом.
У меня есть два пространства имен - MySpecificNamespace и MyCommonNamespace. MyNamespace использует MyCommonNamespace, как и следовало ожидать.
Теперь мне нравится максимально использовать пространство имен везде, где это возможно, чтобы описать контекст проблемы и не добавлять контекст к имени класса. Так, например, подумайте, что у меня есть класс в MyNamespace, который спускается из одного в MyCommonNamespace.
Вариант A
Я мог бы назвать это
MySpecificClass: MyClass
{
}
Но затем я добавляю "Специфический" (контекст) к имени, который является избыточным, как и в MySpecificNamespace.
Вариант B
MyClass: MyCommonNamespace.MyClass
{
}
Вы можете видеть, как мы могли бы запутаться здесь, верно?
Вариант C
Тот, который я считаю подозрительным:
MyClass: MyBaseClass
{
}
Я обычно добавляю базовый суффикс к имени базового класса, только если он существует с технической точки зрения (для обмена некоторым кодом) и на самом деле не представляет собой какой-либо пригодный для использования класс (так что все эти классы Абстрактные). Однако это довольно редкие случаи, и их следует избегать так же, как и классы-помощники.
Я согласен с "нет" в точности для причины рефакторинга, которую вы указали.
Класс должен быть назван в честь того, что он логически представляет, и ничего, кроме класса Object, действительно является базой. Метафизика ftw:)
re: Вариант B, нет ничего путающего в
namespace MySpecificNamespace
{
MyClass: MyCommonNamespace.MyClass
{
}
}
Классы, имеющие то же имя, что и их родительские классы, меня не пугают. В Java java.sql.Date расширяет java.util.Date. Это очень раздражает, потому что вы должны указать точный класс, который хотите импортировать, или полностью указать имя класса (включая пакет/пространство имен).
Лично я предпочитаю называть вещи такими, какие они есть; если базовый или абстрактный класс существует только для обеспечения частичной реализации чего-либо и не представляет собой интерфейс для этой вещи, часто бывает принято помещать слово Abstract или Base в его имя. Однако, если этот класс также представляет интерфейс, тогда вы должны просто назвать его после того, что он делает.
Например, в Java у нас есть интерфейс Connection (для соединений DB). Он просто называется Connection, а не IConnection. Вы используете его следующим образом:
Connection con = getConnectionFromSomewhere();
Если вы создаете драйвер JDBC и вам необходимо реализовать соединение, вы можете иметь ConnectionBase или AbstractConnection, который является нижним уровнем детализации реализации вашего конкретного Connection. Возможно, у вас
abstract class AbstractConnection implements Connection
class OracleConnection extends AbstractConnection
или что-то в этом роде. Однако клиенты вашего кода никогда не видят AbstractConnection и не видят OracleConnection, они видят только Connection.
Итак, в общем, классы, которые должны быть в целом полезны, должны быть названы в честь того, что они представляют/делают, тогда как классы, которые являются помощниками для обслуживания/организации кода, могут быть названы после того, что они есть.
* ps Я ненавижу именовать интерфейсы с I. Люди называют все свои классы с помощью C? Это 2009! ваша среда IDE может рассказать вам, какой тип объекта есть, в нечетном случае, когда это даже имеет значение, если это интерфейс или класс.
"Все ваши BaseClass принадлежат нам".
Я сторона с окончательным no, с единственным исключением. Если вы пишете приложение для управления военными объектами или стадионами бейсбола, идите на это.
Я думаю, это стоит того, чтобы вики-финал этого вопроса.
FWIW, я согласен. Обычно я пытаюсь найти более "общий" термин для базовых классов. Поэтому, если у меня есть класс "Клиент" и вам нужно ввести для него новый базовый класс, я бы пошел с "Contact" или что-то, а не "CustomerBase".
Я тоже предлагаю "Нет", но не бросать в камень...
Следуя OO мантре, ваша система именования должна наилучшим образом представлять базовые объекты, которые предполагается инкапсулировать в код. На самом деле не должно быть "метаязыков", связанных с фактическим синтаксическим составом выбранного языка программирования.
Тем не менее, если ваш объект является действительно абстрактным, и вы действительно не видите его изменения в ближайшее время, есть аргумент, что добавление "Base" помогает с общей читабельностью.
Как и в большинстве случаев, нет никакого правильного правильного и неправильного ответа - это зависит от общей компоновки вашей кодовой базы, от того, что этот конкретный код должен представлять, и внутреннего стиля, который у вас есть. Просто старайтесь быть последовательными.
Используется ли база где-нибудь еще?
Я также выступаю против лагеря no... поставьте базу там сегодня и через 6 месяцев кто-то будет бить класс MyDerivedClass в вашей базе кода, пока вы не смотрите.
В Java я обычно предлагаю базовую реализацию интерфейса Foo в абстрактном классе FooBase. Я думаю, что это нормально, и делает соединение с интерфейсом очень четким и регулярным.
Без интерфейса я бы назвал абстрактный базовый класс Foo.
Я согласен, AbstractFoo - достойное решение. Я пытаюсь выбрать имена, которые не нуждаются в дополнительных прилагательных. Я бы уклонился от использования Base.
Я думаю, что, вероятно, следует избегать там, где это возможно, в пользу идентификатора, который фактически описывает, что это такое!
Этот вопрос трудно ответить, потому что он абстрактный. Я мог бы, например, рассмотреть возможность вызова базы MyClassA и MyClassB, "MyClass".
"Абстрактный" префикс может быть?
Обычно я использую IFoo для интерфейса и AbstractFoo для реализации скелета, который представляет собой смесь соглашений .NET и Java.