I've been looking across the web for a simple explanation about the differences between the two. I understand composition is "bottom-up" design while decomposition is "top-down" design. However, aside from that - are there any further differences? If a program implements the "composability" principle, does it necessarily also implement the "decomposability" principle, and vice-versa?
It's obvious how these two can lead to different designs, but all in all, it seems they represent exactly the same thing from different point of views.
Clarifications will be highly appreciated. Cheers!
Some reference links:
As the first link you've provided shows it, these two approaches are not incompatible. You just need to know when to use one or the other.
From my experience, top-down design is a good approach when you start designing, as you need to discover your system, understand the requirements and making something works quickly. As you add more and more features, specific responsibilities start to emerge and this is where decomposing your problem is required. This will prevent to duplicate code from one feature to another, and lower the efforts required to compose new ones.
Choosing between one approach or the other is just a matter of figuring out the right design decision to take at a proper time. If you feel that some aspects of a problem are still unclear, there is no reason to decompose it. Just wait until your module cries out for modularization (for example, having a hard time to understand what you wrote some days ago would be a good sign, same for duplicated code).
Is this answering your question ?