Programming.NETComponents(2003), Programowanie, ! .net c#

[ Pobierz całość w formacie PDF ]
Design and Build Maintainable Systems
Using Component-Oriented Programming
Juval Löwy
Programming .NET
Programming .NET
Juval Löwy







Chapter 1
Introducing Component-Oriented
Over the last decade, component-oriented programming has established itself as the
predominant software development methodology. The software industry is moving
away from giant, monolithic, hard-to-maintain code bases. Practitioners have discov-
ered that by breaking a system down into binary components, they can attain much
greater reusability, extensibility, and maintainability. These benefits can, in turn,
lead to faster time to market, more robust and highly scalable applications, and
lower development and long-term maintenance costs. Consequently, it’s no coinci-
dence that component-oriented programming has caught on in a big way.
Several component technologies, such as DCOM, CORBA, and Java Beans now give
programmers the means to implement component-oriented applications. However,
each technology has its drawbacks; for example, DCOM is too difficult to master,
and Java doesn’t support interoperation with other languages.
.NET is the newest entrant, and as you will see later in this chapter and in the rest of
the book, it addresses the requirements of component-oriented programming in a
way that is unique and vastly easier to use. This is little surprise because the .NET
architects learned from the mistakes of previous technologies, as well as from their
In this chapter, I’ll define the basic terms of component-oriented programming and
summarize the core principles and corresponding benefits of component-oriented
programming. These principles apply throughout the book, and I’ll refer to them in
later chapters when describing the motivation for a particular .NET design pattern.
Component-oriented programming is different from object-oriented programming,
although the two methodologies have things in common. You could say that compo-
nent-oriented programming sprouted from the well of object-oriented programming
methodologies. Therefore, this chapter also contrasts component-oriented program-
ming and object-oriented programming, and briefly discusses .NET as a component
This is the Title of the Book, eMatter Edition
Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.
 Basic Terminology
The term
is probably one of the most overloaded and therefore most con-
fusing 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 DLL), and the associated logic used to
deploy and use it, including type information, security policy, and versioning infor-
mation (called the
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 physi-
cal and logical packaging, as well as why it is that every .NET class is a binary com-
ponent, unlike traditional object-oriented classes.
A component is responsible for exposing business logic to clients. A
is any entity
that uses the component, although typically, clients are simply other classes. The cli-
ent’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
is an instance of a component, a definition that is similar to the clas-
sic object-oriented definition of an object as an instance of a class. The object is also
sometimes referred to as the
because the relationship between client and object,
often called the
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 fig-
ure an object is an instance of a component; the “lollipop” denotes an interface.
.NET interface
Method call on
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 enforce interface-based program-
ming, as you will see shortly, you should strive to do so with your own code when-
ever possible. To emphasize this practice, I represent the entry points of the
Chapter 1: Introducing Component-Oriented Programming
This is the Title of the Book, eMatter Edition
Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.
[ Pobierz całość w formacie PDF ]