Section 1.1. Basic Terminology

1.1. Basic Terminology

The term component is probably one of the most overloaded and therefore most confusing terms in modern software engineering, and the .NET documentation has its fair share of inconsistency in its handling of this concept. The confusion arises in deciding where to draw the line between a class that implements some logic, the physical entity that contains it (typically a dynamic link library, or DLL), and the associated logic used to deploy and use it, including type information, security policy, and versioning information (called an assembly in .NET). In this book, a component is a .NET class. For example, this is a .NET component:

     public class MyClass     {        public string GetMessage(  )        {           return "Hello";        }     } 

Chapter 2 discusses DLLs and assemblies and explains the rationale behind physical and logical packaging. It also discusses why it is that every .NET class, unlike traditional object-oriented classes, is a binary component.

A component is responsible for exposing business logic to clients. A client is any entity that uses the component, although typically, clients are simply other classes. The client's code can be packaged in the same physical unit as the component, in the same logical unit but in a separate physical unit, or in separate physical and logical units altogether. The client code should not have to make any assumptions about such details. An object is an instance of a component, a definition that is similar to the classic object-oriented definition of an object as an instance of a class. The object is also sometimes referred to as the server, because the relationship between client and object is often called the client/server model. In this model, the client creates an object and accesses its functionality via a publicly available entry point, traditionally a public method but preferably an interface, as illustrated by Figure 1-1. Note that in the figure an object is an instance of a component; the "lollipop" denotes an interface.

Figure 1-1. A client accessing an object

I'll discuss .NET interface-based programming in detail in Chapter 3. For now, it's important to emphasize that while .NET doesn't force you to do interface-based programming, as you will see shortly, you should strive to do so whenever possible. To emphasize this practice, I represent the entry points of the components that appear in my design diagrams as interfaces rather than mere public methods.

Although the object depicted in Figure 1-1 is drawn like a COM object, with its characteristic lollipop icon, use of this icon isn't restricted to COMit is accepted as the standard UML symbol for an interface, regardless of the component technology and development platform that implement it.

Interface-based programming promotes encapsulation, or the hiding of information from the client. The less a client knows about the way an object is implemented, the better. The more the details of an implementation are encapsulated, the greater is the likelihood that you can change a method or property without affecting the client code. Interfaces maximize encapsulation because the client interacts with an abstract service definition instead of an actual object. Encapsulation is key to successfully applying both object-oriented and component-oriented methodologies.

Another important concept that originated with object-oriented programming is polymorphism. Two objects are said to be polymorphic with respect to each other when both derive from a common base type (such as an interface) and implement the exact set of operations defined by that base type. If a client is written to use the operations of a base type, the same client code can interact with any object that is polymorphic with that base type. When polymorphism is used properly, changing from one object to another has no effect on the client; it simplifies maintenance of the application to which the client and object belong.