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

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 для реализаций. Хотя это имеет свою цель, им становится еще труднее выяснить, какой класс даже используется.

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

Отредактировано: 24.10.2008 20:40

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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