What Design Patterns for encouraging component reuse?

Looking for design patterns?

Design patterns are useful tools. But you should not choose them from a catalogue to solve your problems. Starting with the choice of a tool will make you a subject of the law of the instrument:

if you have a hammer in the hand, every problem will start to look like a nail.

You need to first design the reusable component. Maybe at a moment of your reengineering you’ll recognize a nail and take the hammer, and then a screw and take the screwdriver. The tool should be chosen to solve very specific parts of your design.

With design patterns, it’s the same: Try to rework the identified components to isolate them in a library with a well identified API that can be used in several projects. When doing so on your own, you’ll find some coupled elements glued together. Try to understand the reason and what you should do to go further. In some cases you may recognize a close match with some design patterns you know.

Or in need for some general design principles?

Believe it or not, isolating your identified features in self-contained components is a first step towards reuse. In this regard, some more general principles aim at facilitating decoupling of conponents, in particular:

  • Your component should be open for extension (to account for special needs) but closed for modification (because if you modify the component, for a specific application, it’s no longer reusable as such).
  • Your component should not depend on application-specific code. If there is some application specific dependency, you should invert this dependency, for example with dependency injection.

There are a couple of other such principles. Together they are called SOLID.