Каков хороший способ показать взаимосвязь между свободно связанными классами и интерфейсами?

Question

Я внедрил принципы SOLID моей команде, и они понимают и очень рады использованию принципов.

S - SRP - Single Responsibility Principle 
O - OCP - Open/Closed Principle 
L - LSP - Liskov Substitution Principle 
I - ISP - Interface Segregation Principle 
D - DIP - Dependency Inversion Principle 

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

Каков наилучший способ визуально показать отношения между классами и как они используются в проекте ?!

Отредактировано: 2008/10/24 8:40 вечера

На основе UML комментарий, я попытался обратиться к встроенной в схеме Visual Studio класса для построения модели приложения. Я могу дать описание каждого интерфейса, но все еще не уверен, что они четко связаны.

Answer 1

диаграммы UML взаимодействия может явно показать такие отношения: это требует, что ...

диаграмма классов UML может показать, как этот класс использует этот интерфейс и этот интерфейс реализован этот класс.

Теперь такие диаграммы являются «моментальными» утверждениями о конкретном выборе, сделанном для конкретного выполнения, которые могли бы иметь определенные инъекции. Таким образом, в некоторой степени, предоставляя диаграммы, которые вы удаляете от общего гибкого дизайна, который вы используете, я могу понять, что люди действительно находят такие снимки полезными.

Я стараюсь думать об аспектах дизайна в отношении интерфейсов, мне действительно не нужно понимать, «как» методы, описанные интерфейсом, на самом деле работают, понять, что делают реализации. Идея Onde заключается в том, что нам нужно принять подход Black Box к нашим зависимостям. Поэтому я бы рекомендовал поощрять людей не нуждаться в таких диаграммах, а не думать об ответственности. (это все очень хорошо, пока все не работает, тогда диагноз может потребовать больше), но подумайте: когда вы используете многие операционные системы и возможности .NET, вы действительно знаете, что происходит на самом деле? Можете ли вы принять тот же умственный подход с другими частями кода вашего приложения?

Answer 2

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

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

ReSharper plugin for Visual Studio Получить и использовать следующие ссылки (если ваша каретка находится над классом/интерфейсом):

Alt + Главной - Перейти к базовому интерфейсу/

Alt + Конец - Перейти к производным/типов, реализующих интерфейс

Эти две ярлыки абсолютно необходимы для просмотра кодовой базы с большим количеством свободной связи.