Некоторые проблемы дизайна с C ++ - PullRequest
Новая
       4

Некоторые проблемы дизайна с C ++

0 голосов
/ 14 апреля 2011

У меня есть следующая дилемма: у меня есть несколько классов, скажем, A, B, C и D. A имеет открытый интерфейс и имеет связь с B (например, A имеет переменную-член типаB) и один из методов A возвращает этот объект B, B - это просто класс, который предоставляет некоторые методы, C - другой класс, который предоставляет другие методы, а D - одноэлементный объект.Открытый интерфейс D имеет ссылки (указатели, если вам больше нравится) на объекты класса C.

Итак, очевидно, когда я хочу нарисовать диаграмму отношений на этом шаге, у меня будет связь между A и Bи C будет нанесен на диаграмму, без видимой связи с двумя другими.Итак, это основано на файлах заголовков (.h), которые содержат объявление класса A, B, C. Я немного запутался в отношении D прямо сейчас.

С другой стороны:

  1. обе реализации (в файлах .cpp) A и B сильно зависят от объектов, созданных из класса C (нет, C не является чем-то стандартным, таким как список, строка, очередь, но другой значимыйкласс в моем приложении).
  2. обе реализации A и B используют синглтон D с локальными объектами C.

И вот мои вопросы:

  1. Какие отношения я должен поставить на диаграмме классов между A, B, C и D, не считая того, который я идентифицировал (A имеет-a B)?Меня особенно интересует отношение одиночного D к классу С.
  2. Какова общепринятая методология для такого рода ситуаций (когда интерфейс не имеет отношений между объектами, потому что их нет, но вреализация они интенсивно используются)?
  3. Будет ли разница, если у меня будет один и тот же вопрос в соответствии с Java, а не C ++ (потому что в Java все, что связано с классом, находится в одном файле, так что легчепосмотрите, что на самом деле использует метод класса, а в C ++ вы обычно просто видите заголовок).

Большое спасибо за ваше руководство.

Ответы [ 2 ]

1 голос
/ 16 апреля 2011

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

@startuml
class A
A o--> B
A : + method()
A : + B& getB()
A : - B m_B
A --> "getC" D 

class B
B : + method()
B --> "getC" D 

class C
C : + method()

class D <<Singleton>>
D --> "0..n" C
D : + C* getC( int index )
D : - list<C> m_containerOfC

@enduml

Относительно второго вопроса: я думаю, что цель рисования диаграмм UML (я полагаю, для проектирования) в основном заключается в абстрагировании, следовательно, игнорируя детали.Нет смысла пытаться выразить полную программу C ++ на UML после того, как вы написали программу.Вы можете купить программы, которые (пытаются) сделать это для вас, но я не думаю, что эти диаграммы полезны.

Ответ на ваш третий вопрос заключается в том, что на этапе проектирования UML для реализации java и c ++ должен быть равен или, по крайней мере, для значительной части.Проектирование - это выбор и подключение шаблонов проектирования и т. Д., И они не зависят от языка.Когда вы начинаете детализировать свои диаграммы, чтобы представить больше деталей реализации (например, тип используемых контейнеров и т. Д.), Тогда вступает в игру выбранный язык для реализации.Однако на этом этапе вы должны спросить себя, дает ли ваша диаграмма достаточную уверенность в вашем дизайне, а затем начать кодировать ее.

1 голос
/ 14 апреля 2011

Вы должны окончательно прочитать книгу Крупномасштабный программный дизайн C ++ .

В частности, речь идет о моделировании зависимостей между интерфейсами и реализацией путем введения двух новых взаимосвязей использует-в-интерфейсе и использует-в-реализации просто традиционного "has-a".

Затем продолжаются принципы проектирования, применяемые для такого моделирования (такие как изоляция , изоляция , инкапсуляция и т. Д.). Это действительно очень техническая книга. Так что будьте готовы!

...