Components vs Frameworks

ABSTRACT: One of Razie's infamous uber-principles: I see frameworks as being the opposite of components. When architecting parts of a system, use this to decide on one or the other - this point of view could enrich the designer's arsenal of decision principles.
TAGS: architecture, design, principle

When you're talking about "writing code", the best option is generally reusing an existing piece of code and customizing it. Reusable pieces of code are normally in the category of either components or frameworks.

Components are more or less black boxes with well defined inputs/outputs and customization settings.

Frameworks, while they may also have defined inputs/outputs, they generally cannot be used as is. You write "plugins" (i.e. proxies or strategies) that customize a piece of the puzzle and then combine them to achieve the functionality the framework is intended for.

I see frameworks as being the opposite of components, given how they're used: while components are pre-determined pieces of functionality, which you combine to achieve a flexible structure, frameworks define first an immutable structure and then allow you to customize some aspects of it.

Patterns fall sqarely in the framework category, since they prescribe a structure with roles to fill out.

In terms of initialization and configuration, components get everything up-front, while frameworks usually will use a callback to retrieve configuration, when needed. At least it's easier to always follow this pattern: use of factories indicates frameworks, for instance.

Depending on the level you're at and your point of view, it is relative whether a given library falls in either category. For instance, a component could take a "strategy" as an input.

When you look at a system, you will see components made of frameworks, made of components, made of frameworks etc. A system is made of sub-systems, which can only be of either kind :) since they're the two opposite forms of sub-system architecture.

CONCLUSION

Making the distinction and decision between component vs. framework, when designing, is important, since the denomination of "component" carries lots of semantics: independence, self-sufficiency, black-box, upfront initialization etc.

Frameworks allow flexibility in the detail but are inflexible structure-wise. A framework that is too flexible is called a mess.

A framework with all variabilities fixed is a component.

Keep thinking and have fun, eh? I certainly am!