Terminology: What's the difference between a class and a component?

Question

Within the OO paradigm, we choose to use classes because they help us to break the system down, and provide nice side benefits such as encapsulation, separation of responsibilities, inheritance, modularity, etc.

If we look at a software system at the component level, can we simply treat components in the same conceptual way, i.e. a component is simply a "Big Class"? Or is there more to it than that?

What extra considerations must be given when designing components?

EDIT:

I know that a class and a component are different things. I also understand that a component may contain many many classes, each of which have their own roles and responsibilities.

I'll see if I can explain myself better.

• Classes allow us to solve bigger problems because they allow us to think and design more abstractly.
• There are rules & techniques to determine how to break down and assign data and functionality to classes.

This seems like a very similar situation to that of component design, just at a higher level of abstraction. Do the techniques used to determine what classes are needed scale up to components, and/or are there other things that affect a high-level system design that don't apply at the class abstraction level?

Answer 1

Eh?

The "File Uploading" component may consist of lots of classes: Page to receive the file, class to save it, etc.

Answer 2

I often think of Component in the UML sense (see Wikipedia description), whereby it represents a "modular part of a system". In this sense it tends to represent a larger piece of functionality than a class and could in fact be composed from multiple classes.

Considerations I would give to designing components are:

• How it could be re-used. In particular what are the use cases that warrant implementing something as a component rather than bespoke code (As a grad I used to make everything re-useable!)
• Providing sensible interface(s), and in some cases additional simplified interfaces, perhaps using the Facade pattern.

Hope that helps.

Answer 3

In this (hypothethical) context a component can be thought of as a series of classes.

However depending on the technology you use, components can be more then a set of classes. i.e. They may have additional properties and functionality which is not part of the classes which form them. e.g. a COM+ component.

So it depends on a specific situation really.

Answer 4

what about using the project phase or role to differentiate them?

For example a component is a design-time unit (system architects, designers) whereas a class is an implementation-time unit (programmers). So designers speak about components (or subsystems or modules, the hight-level boxes in your architecture drawing) whereas programmer speak about components and classes (that implements components).

Under this view a component is implemented by one or more classes.

Answer 5

According the UML v2 specification:

8.3.1 Component (from BasicComponents, PackagingComponents)

A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.

A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics). One component may therefore be substituted by another only if the two are type conformant. Larger pieces of a system’s functionality may be assembled by reusing components as parts in an encompassing component or assembly of components, and wiring together their required and provided interfaces.

When you use this definition, components appear to be all about Inversion Of Control.

Looking at the .NET framework for an example, the IComponent interface indeed provides IComponent.Site.GetService to achieve inversion of control through the service provider pattern. A more light-weight alternative is dependency injection.