Yesterday a team member asked me to explain what a software component is. Even though I was able to provide a reasonable answer, the question fascinated me to do a bit of research on the topic.
Let’s start with the definition. Here’s what Google returned:
A reusable piece of software in binary form that can be easily integrated with other components with relatively little effort.
An alternative definition is:
A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.
One of the primary features of software component is information hiding. The component can be treated as a black box which defines a crisp interface to the outside world. The implementation is carefully hidden from the end user, thus allowing for implementation change at a later point in time. Components are easily usable in different application contexts. As a consequence, components need to be self-contained software entities.
The most common example of a component that comes to my mind is JDBC drivers. They have
- Contractually defined interfaces – They implement the JDBC specifications.
- Context Independence – The JDBC jars do not depend upon any other component besides the Java runtime for their execution.
- High Reuse – They do not need any further code customization i.e. they are ready-to-use.
Another example of a software component would be EJB. The application developer needs to implement the home, remote and ejb bean and is provided with out-of-the-box support for transaction management, security, persistence etc.