Inheritance Pattern

Question

Я нахожу свои соглашения об именах довольно назойливыми. Кажется, я слишком сильно переписываю дочерние конкретные имена. В моем примере ниже у меня есть виджет, который имеет -Соединение, которое имеет-Config. Каждый из этих объектов имеет специализированные классы для типов Foo и Bar.

Так что у моего FooWidget есть Foo-Connection, у которого есть Foo-Config. То же самое для Бар. В C++ я получил девять разных файлов заголовков.

• widget.h
• connection.h
• config.h
• foo_widget.h
• foo_connection.h
• foo_config.h
• bar_widget.h
• bar_connection. h
• bar_config.h

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

Итак, я думаю, мой вопрос следующий: Есть ли шаблон дизайна, который улучшит этот дизайн?

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

Answer 1

Прежде всего, ничего нет Неверный с тем, что делает. Многим нравится ставить один класс на заголовок, в общем. Если вам не нравится смотреть на множество заголовков, вы можете организовать их по каталогу или фильтру проекта дерева и т. Д.

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

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

Если они относительно небольшие классы, не может быть вреда при объявлении классов Foo и Bar в определении их базового класса. Тогда нет FooConnection - это фактически Connection::FooConnection. В этом случае Connection не просто определяет базу для FooConnection, ее владеет своим самым определением. Это означает, что каждый раз, когда вы используете FooConnection в своем коде, вы думаете в контексте Connection.I редко делаю это сам, в первую очередь потому, что мне не нравится набирать Connection:: все время, но также и потому, что так мало случаев, когда я использую только класс в одном контексте.

Если инкапсулированные классы protected или private, то они используются только самого родительского класса (и friend классов и подклассов, может быть, что там у вас). Затем, так как ограниченный контекст установлен, и если объявления классов невелики (< 50 или < 100 строк), вы можете объявить FooConnection и BarConnection в пределах Connection и по-прежнему поддерживать читаемость.

Бонусная точка: если вы заканчиваете объявление классов внутри классов, вы можете использовать разделение пространства имен. Я не знаю использования этих классов, но я предполагаю, что FooConnection не является самим соединением, а Foo, принадлежащим Collection. Итак, вы можете объявить Foo и класс Bar для каждого из Widget, Connection и Config.

Answer 2

Я не думаю, что что-то не так с структурой ваших классов, но, не видя, что делают эти классы, трудно будет дать советы о том, как улучшить свой дизайн.

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

|--Foo 
    |--foo_widget.h 
    |--foo_connection.h 
    |--foo_config.h 
|--Bar 
    |--bar_widget.h 
    |--bar_connnection.h 
    |--bar_config.h 
|--widget.h 
|--connection.h 
|--config.h