“Sloppiness with dependencies. If two classes are independent of each other, and do not provide different implementations of the same interface, think twice about putting them in the same project/dll. Minimizing dependencies is the bread and butter of loose coupling. Break dependence on implementations by introducing interfaces in a separate project/dll.”
His suggestion of refactoring at the physical design level and moving groups of classes from one package (dll or static library) to another to ensure that your project only depends on things that it actually uses is sound advice. Unfortunately it’s one of those really important things that many developers simply do not ever even consider.
If you’re working in C++ and you haven’t read Large-Scale C++ Software Design (APC) by John Lakos then you really should. It covers all of this kind of stuff. Failure to understand the things that you need to do to build large systems in C++ is one of the things that leads people to ask questions like: “Is C++ still needed?”. Yes you can build horrible messes with C++ but no, it doesn’t have to be that way.
As Udi says, “design is about managing dependencies between classes and dlls”. Personally I’d replace ‘dlls’ with ‘packages’ but that’s a minor nit-pick. I often prefer my packages to be static libraries and what Udi says is equally relevant to all other forms of code packaging. You have to actively manage your dependencies all the time, no matter what language you’re working in. If you don’t do it in C++ you can end up in a hell of slow compiles and horribly entwined code that all needs to be rebuilt if you ever change one class. If you do it right you rebuild just what needs to be built and you depend on just what you need, and no more. As always, easier to use languages remove much of the easy to remove pain of uncontrolled dependencies. Compile times may be better which often stops developers realising that their dependencies need managing at all…