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 areclasses 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 thatyou 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 arigorously 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 obscuremethods 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 tothe 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 aremore self-sufficient than the average class. They represent reusable functionality at its best.
One subtle difference between components and assemblies is that components define a logicalgrouping 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, andthe 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...