Question

I’m not sure if it’s possible to give general advice on this topic, but please try. It’s hard to explain my case because it’s too complex to explain. And that’s exactly the problem.

I seem to constantly stumble on a situation where I try to design some part of my project, but it has so many things to take into consideration that I’m unable to get a grasp of it.

Are there any general tips or advice on how to look at my system in smaller pieces at a time? How to find smaller portions that could be designed separately on their own?

Answer 1

Your key goals are:

• High cohesion: Code (methods, fields, classes) within one piece/module/partition should interact intensively; it should make sense for these elements to know about each other. If you find that some of them don’t interact much with the rest, they probably belong somwhere else or should form their own partition. If you find code outside interacting intensively with the partition and knowing too much about its inner workings, it probably belongs inside. The typical example is found in OO code written in procedural style, with “dumb” data objects and “manager” code that operates on them but should really be part of the data objects.
• Loose coupling: Interaction between pieces/modules/partitions should only happen through narrow, well-defined, well-documented APIs. Try to identify such APIs and see what code is needed to implement them and what code will use them.