What is a good way to show the relationship between loosely coupled classes and interfaces?

Question

I have introduced the SOLID principles to my team and they understand and are excited about using the principles.

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

I have given them a couple of projects that have already been re-factored to use these principles. The biggest problem that I see if they have a hard time seeing the connections between the very loosely coupled classes within the project. Even if I create a class diagram it won't show any connections. One particular project I am referring too uses Dependency Injection and XML configuration for the implementations. While, this has it's purpose it makes it even harder for them to find out what class is even being used.

What is the best way to visually show the relationships between the classes and how they are used within the project?!

Edited: 2008/10/24 8:40 PM

Based on the UML comment I attempted to turn to the built in Visual Studio class diagram to build a model of an application. I can give descriptions of each interface but still not sure that they are clearly connected.

Visual Studio Class Diagram

Answer 1

UML interaction diagrams can explicitly show such relationships: this calls that ...

UML class diagrams can show both this class uses that interface and this interface is implemented by that class.

Now such diagrams are "point in time" statements about a particular choices made for a particular execution, which particular injections might have happened. So to some extent in providing the diagrams you are moving away from the generally flexible design you are using, however I can understand that folks do find such pictures helpful.

I try to think about aspects of design in relationship to the interfaces, I really should not need to understand "how" the methods described by an interface atually work, understand what the implementations are doing. Onde idea is that we do need to take a Black Box approach to our dependencies. So I'd recommend encouraging folks not to need such diagrams, instead to think in terms of responsibilities. (which is all very well until things don't work, then diagnosis may well require more) but consider: when you are using many operating system and .NET capabilities do you actually know what's really going on? Can you take the same mental approach with other parts of your applciation's code?

Answer 2

I tend to think about interfaces only when it comes to relationships so I can't really help you with broad overviews / class diagrams for concrete types. As someone has already pointed out, if you want to show concrete types on the diagram, it will only be relevant for a snapshot of one particular run -- it will change every time the object graph is wired differently.

I think it's generally more helpful to lay out the interfaces in diagrams, then browse the code base to find the implementations. One tip that makes code browsing much, much simpler:

Get the ReSharper plugin for Visual Studio and use the following shortcuts (when your caret is over a class/interface):

Alt + Home -- Go to base / interface

Alt + End -- Go to derived / types implementing interface

These two shortcuts are absolutely essential for browsing a codebase with a lot of loose coupling.