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

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

Cambridge

Farnham

Köln

Paris

Sebastopol

Taipei

Tokyo
Chapter 1
CHAPTER 1
Introducing Component-Oriented
Programming
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
successes.
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
technology.
1
This is the Title of the Book, eMatter Edition
Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.
 Basic Terminology
The term
component
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
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 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
client
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
object
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
server
because the relationship between client and object,
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 fig-
ure an object is an instance of a component; the “lollipop” denotes an interface.
Client
Object
.NET interface
Method call on
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 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
2
|
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 ]