Reputation: 16794
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.
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?
Upvotes: 6
Views: 9962
Reputation: 1
components are subsystems of classes.Classes provide the basic low level blueprint of an object interface while components adds some functionality to it.
Upvotes: -2
Reputation: 66733
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.
Upvotes: 1
Reputation: 116334
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.
Upvotes: 14
Reputation: 10493
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.
Upvotes: 1
Reputation: 54695
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:
Hope that helps.
Upvotes: 2
Reputation: 55082
Eh?
The "File Uploading" component may consist of lots of classes: Page to receive the file, class to save it, etc.
Upvotes: -1