Images That Strike Fear In A Developer's Heart

Hey, it's the windows OS class diagram

Yes, scary. When I started my current job I ran an automated tool to build a class diagram. I mean, it's a non-trivial project, it's useful to see how it all links together.

On a standard page, the diagram is solid black. Not so much because there's a lot of classes (700), but because there are so many linkages and there's no way to arrange those to not look like a mess. Everything just links to everything. In every possible way: inheritance; encapsulation; references; interfaces, you name it.

Q: What do you need when the program/database is structed like that and you don't have a design tool available.


A: A .22 and 1 bullet

OKAY, you're going to need a stiff drink. But when I look closely, I see a cloud with 7 to 8 central blocks, and a lot of the other blocks only link to those center blocks. It seems that this is a model of an application that does 7 to 8 things. Something like a mini ERP system.
The question is if there is a way to develop an app like that without ending up with a class- or data-model like that. I'd like to hear your thoughts about that, as I'm working on an app that is heading the same way.

Jens:

The idea in your scenario would be to reduce the coupling between classes (modules, services, pieces of functionality) in the ERP system as much as possible.

I'd look at design patterns and tools that can give you inversion of control and dependency injection. Keep the modules as isolated as possible so that a change in A doesn't ripple into B, and both A and B can be tested in isolation.

You know what scares me worse than that? Starting a new gig, opening up a sql diagram with all the tables in the database, and seeing NO lines because they don't have any foreign keys in the db. THAT'S scary.

Scott,

I know that the idea would be to reduce the coupling, what I really wanted to know was how much less edges should there be on the diagram before the fear starts to disapear ?
After all, there is only so much coupling you can eliminate.

I'm a big fan of trees instead of nests. If you can keep things linking either up or across but very rarely both the whole system is easier to maintain. Admittedly I tend to leave data carriers out of that analysis, and in code use records/structs for that task so it's obvious which is which.

Jens:

Well, there will always be edges. I guess the answer would be "it depends".

If you can program to abstractions (like the interface IOrderService) instead of concrete implementations (OrderService) than it can help to keep these different modules/services/areas of functionality loosely coupled.