What is a component

Question

I listen to the podcast java posse, on this there is often discussion about components (note components are not (clearly) objects). They lament the fact that Java does not have components, and contrast with .NET that does. Components apparently makes developing applications (not just GUI apps) easier.

I can figure from the discussion certain qualities that a component has, its something to-do with decoupling (substituting one component for another is just a matter of plumbing). It has something to-do with properties, it definitely has something to-do with events and delegates.

So to the questions:

./ can anyone explain to me what a component is. (and why java beans are not components).

./ can anyone explain how they help development.

./ can anyone explain why java does not have them if they are so useful.

Answer 1

Software Engineering Radio has an episode on exactly this topic: http://se-radio.net/podcast/2008-02/episode-87-software-components

The general idea is that a software component can describe what its own dependencies and services are, in the form of metadata. I don't know why you might have heard that Java does not have components, since you can certainly imagine an architecture in Java where components do describe themselves through metadata. I suppose it's just that the Java platform definition by itself doesn't really have a component architecture.

Update: Indeed, one need not imagine such an architecture because as others pointed out, Java Beans or Servlets could certainly be considered component-based architectures.

Answer 2

The term component is one of the most ambiguous and overused ones in OO.

Most people would agree that a component is made up of a group of classes, which collaborate together to implement one or more interfaces. One of the classes takes on the role of the 'front-end' i.e. it implements the interface but delegates the work to the other classes within the group. As you say components should be replaceable without the rest of the system knowing.

A great example of a component based architecture was COM. Its a great example because it was so heavily used and rigidly specified. But note that the need for this architecture was based on the inflexibility of the C++ compilation and deployment model.

in Java you can do an awful lot to a class without breaking binary compatability with the rest of the system. So there is not as much need to build rigid, component based architectures. But it all depends on how you define the term, e.g any project built using dependency injection could count as 'component based'.

Answer 3

I don't know .NET components particularly, but from the Java POV, I'd say that a component is some functional unit that should have a defined interface/usage principle. While Java does not have components as a language concept, there are IMHO components in Java. Technical components would be e.g.:

• EJBs
• Servlets

Functional components would be e.g.:

• Automatic Update for an application
• Formula mechanism that enables calculations on a data model

Architectural components could be JAR files or OSGi bundles.

Of course, there is always room for interpretation ;)

Answer 4

It depends on what you mean by "component". The term can mean lots of different things in a lot of different contexts, so it can easily get confusing. With that said, here's my understanding of the subject:

A component is different from an object (although objects are often used to represent and build components). The difference being a couple of things:

1. Objects tend to just be "things" whereas components are actors. The difference being that a component is a part of a process, while an object represents some kind of abstract idea.
2. Components help ensure code re-use and pluggability because they are basically small "sub-programs" (or sometimes programs in their own right) that ideally can be adapted to work well with other components.
3. You tend to see components more in "nothing shared" message-passing systems like Erlang or Kamaelia, mainly because those types of frameworks tend to be best suited for component-oriented design.

There are a lot of good examples of component-oriented design, but my first choice would be UNIX. The basic idea behind UNIX is that it is more a set of small programs designed to work together rather than being made up of several more monolithic programs.

Answer 5

Software comes in several groupings. Here are the Java chunks.

• Statements.
• Method functions. Multiple statements.
• Class. Multiple attributes and method functions.
• File. One or more classes. One class is the public class in the file, other classes are hidden in the file.
• Package. Multiple classes. These form a hierarchy.

"Component", "Layer", "Tier" and other philosophical groupings are -- generally -- notional. The VB COM environment had a formalism for components. Everyone else treats them as just ideas.

Beans are classes. Can be single class be a component? Maybe. A component is usually a bunch of classes. Sometimes as few as two - a formal interface and an implementation.

Components help you focus on a logical grouping of classes, packages, groupings, etc.

Since a component is notional, every language more-or-less has them. There are few language formalisms for components. They aren't really needed. It's an idea or a principle you use to structure your thinking.

You can, with some care, define an approach to "components" with an interface and metadata and numerous other features.