How do you define a software component?

Question

How do you define a software component and what kind of relationship is there between OOP and component programming? What are the pros and conns and what is the "golden ratio" of these paradigms?

Answer 1

The granularity of a software component should map to the granularity of reuse. If a lump of software is reused elsewhere then it should be versioned and released as it's own component. If it is not reused elsewhere then this adds little value.

It would be surprising if anything smaller than a complete class was considered a component and would anticipate a collection of classes would form a component.

Answer 2

I think of a Component as being a rather higher level organising concept than an Object.

Components are often units of release and deployment. You would expect to define both the interfaces they expose and the depdencies they have on other components and infrastructure aspects. Different components in a system might well be developed using very different technologies, and indeed a single component need not be homogeneous.

If developing a component in some OO language you would then decompose responsibilities, and arrive an OO design for that component.

Answer 3

I think component programming is essentially the reinvention of oo.

oo aimed to be black box ... but isn't, component programming is trying to be black box.

as a result i think component programming implies over engineering (in a positive way) - because in order to be black box you have to anticipate future use cases and have already catered for them.

It also implies a psychology of documentation of thorough testing which in my experience at any rate seems to take a back seat in oo coding.

So you would provide threading and async support. You would publish interfaces, documentation and unit tests. Have clear event structures and behaviours.

Essentially anything you can to allow someone to reuse it and help them do so.

The point is that a component has a well defined interface and a well defined function. The actual implementation details are not part of this because they are out of scope when considering how to use the component. Ie a component can be quite a complex set of objects.

Answer 4

I would think of a Component as a subsystem of an application that you can consider like a Black box.
So in OOD a group of classes and interfaces with a clear specification an ONE CLEAR purpose that allow you to perform some computation without having to know what the box is made of.

Input -> [ BlackBox ] -> Output

What furter identify a component is:

• High internal coesion
• No dependencies with respect to the rest of the application, so that a component can easily be imported in one or more project.

Component programming I think is actually assembling components to build larger applications.
In a very "utopistic" view there should be public repositories where you can look for a component that fullfills your specification. Once you have found the component you can integrate it in your app.