This blog post I’ve found from 2009 has a nice way of looking at the problem of comparing the ease of use with the ability to reuse. It claims that usability and reusability is always a tradeoff between building
- a heavyweight, coarse-grained software component with few dependencies (very usable)
- a lightweight, fine-grained software component with complex dependencies (very reusable)
The following picture nicely depicts this relationship:
Indeed, coarse-grained components are hard to reuse because they try to solve too many problems in the context of the coarse overall point of view. But I’m not sure if they’re necessarily easier to “use”. Being coarse, and thus complex, they may have solved the problem in the wrong way. And since they’re so complex, they cannot be changed easily to fit a slightly different problem domain. Since time can change the original problem setup (and it will in any project), heavyweight, coarse-grained components often cannot even be used nor reused for their “original” purpose. I.e. a coarse solution that is developed in a project over several years cannot be finished, because it cannot be changed after those four years.
And fine-grained components aren’t necessarily hard to use. It is possible to create components with very little dependencies, such that they do not introduce a lot of complexity. jOOQ is one example of such a component, which has no dependencies itself, apart from the JDK. But jOOQ is a library and not a business module, i.e. it implements horizontal reusability, not vertical reusability.
So, let’s hope the original post was not entirely correct and there is a good, middle way! See for yourself:
http://techdistrict.kirkk.com/2009/07/08/reuse-is-the-dream-dead
I definitely agree with your point of view. Why should coarse-grained, heavyweight components (if you can call them “components” at all) automatically be easier to use? The ease of use depends on the API of a component, after all. And you can definetly create APIs with multiple small components that are still easy to use. If you cannot, you can still create a “wrapper” component around multiple of your smaller ones as an abstraction.
I might’ve brought in some confusion by referencing jOOQ, which is a “horizontal” library and not a “vertical” business component. The original article is mostly about vertical use / reuse as advocated by tools that have failed, such as:
– UDDI
– Portlets
– Masheable Widgets, etc