Лучшая практика для именования подклассов

Используйте то, что Вы любите, это - субъективная вещь. Важная вещь состоит в том, чтобы ясно дать понять, что представляет каждый класс, и имена должны быть таковы, что отношения наследования имеют смысл. Я действительно не думаю, что это - все это важное для кодирования отношений на имена, хотя; это - то, для чего документация (и если Ваши имена подходят для объектов, люди должны смочь высказать хорошие предположения относительно того, что наследовалось какой).

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

Вы могли найти некоторое руководство в документе стандартов кодирования, например, существует документ IDesign для C# здесь.

Лично, я предпочитаю опцию 2. Это обычно - способ, которым Платформа.NET называет свои объекты. Например, взгляд на классы атрибута. Они все заканчивают в Атрибуте (TestMethodAttribute). То же идет для EventHandlers: OnClickEventHandler является рекомендуемым названием обработчика событий, который обрабатывает событие Click.

Я обычно пытаюсь следовать за этим в разработке моего собственного кода и интерфейсов. Таким образом IUnitWriter производит StringUnitWriter и DataTableUnitWriter. Таким образом, я всегда знаю то, что их базовый класс, и он читает более естественно. Самодокументирование кода является конечной целью для всех гибких разработчиков, таким образом, это, кажется, работает хорошо на меня!

Я обычно называю подобными опции 1, особенно когда классы будут использоваться polymophically. Мое обоснование состоит в том, что самый важный бит информации перечислен сначала. (Т.е. то, что подкласс в основном, каков предок с (обычно) 'добавленными' расширениями). Мне нравится эта опция также, потому что при сортировке списков имен классов, связанные классы будут перечислены вместе. Т.е. Я обычно называю единицу перевода (имя файла) то же как имя класса, таким образом, связанные файлы класса будут естественно перечислены вместе. Так же это полезно с возрастающим поиском.

Хотя я был склонен использовать опцию 2 ранее в моей карьере программирования, я избегаю его теперь, потому что, как Вы говорите, это - 'inconsistant', и не кажутся очень ортогональными.

Я часто использую опцию 3, когда подкласс обеспечивает существенное расширение или спецификацию, или если имена были бы довольно длинны. Например, мои классы имени файловой системы получены из Строки, но они значительно расширяют Строковый класс и имеют существенно отличающееся использование/значение:

Directory_entry_name, полученный из Строки, добавляет широкие функциональные возможности. File_name, полученный из Directory_entry_name, скорее специализировал функции. Directory_name, полученный из Directory_entry_name также, скорее специализировал функции.

Также наряду с опцией 1, я обычно использую неполное название интерфейсного класса. Например, у меня мог бы быть класс interence цепочка:

• Текст (интерфейс)
• Text_abstract (абстрактный (основной) класс обобщения)
• Text_ASCII (реальный класс, специфичный для кодирования ASCII)
• Text_unicode (реальный класс, специфичный для unicode, кодирующего)

Мне скорее нравится этот, интерфейс и абстрактный базовый класс автоматически кажутся первыми в отсортированном списке.

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

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