What Is a Component?

Often, developers distinguish classes from components based on their use. Classes enable you to break up the functionality of your program into logical units. Components are classes that have a greater destiny: they are intended for use in more than one program.

Technically, components encapsulate one or more classes in compiled binary form. Components represent code that you might want to provide to another developer or just reuse in more than one of your own applications. Therefore, components need to have a higher standard of self-protection and they need a rigorously standardized interface. For example, components must restrict invalid data using property procedures, refrain from using parameters with cryptic names, and never include a combination of obscure methods that must be invoked in a specific order. All these considerations also apply to classes, but they are more critical for components. It's usually acceptable for a class to be tested according to the set way in which it will be used. The component programmer, however, has less control over how the code will be used and must consider every possibility.

Components are also versioned, maintained, and deployed individually. A developer uses a component in an application by adding a reference to a compiled assembly, not by copying a source code file into the project. Therefore, components are more self-sufficient than the average class. They represent reusable functionality at its best.

Note

One subtle difference between components and assemblies is that components define a logical grouping of classes around a specific feature set while assemblies are the physical DLL or EXE files that contain the compiled code. An assembly is a unit for the purposes of versioning, deployment, and the code-access security mechanism discussed in Chapter 13. It can contain any number of related components. It's also possible, but less likely, to find a single component spread out over more than one assembly. As a seasoned .NET developer, you already know that classes are built from properties, methods, and events, and you'd rightly be insulted if I reminded you of that. What's more important is determining how classes interact in a distributed system and how they divide their functionality into methods and properties.