ch02.htm

好书《C++ Builder高级编程技术》

of this book. I have included this much only because I feel many of the issues addressed
here are not immediately obvious when you first open BCB, and yet you absolutely
have to know these facts in order to get any serious work done in the 
environment.
<H3><A NAME="Heading24"></A><FONT COLOR="#000077">Core Technology: Components, Properties,
Delegation</FONT></H3>
<P>Many people are confused about Borland C++Builder. They are not used to the idea
of having a RAD tool that works with 
C++, and they don't know quite what to make
of it when they see it.</P>
<P>Some people think they are seeing a code generator; others think this is a visual
tool meant for programmers who don't want to write code. Some people think they have
found a 
great tool for building databases, and others a tool for prototyping applications.</P>
<P>There is some truth to all of these ideas, yet they all miss the mark if your
aim is to find the essence of Borland C++. The core pieces of the technology are

threefold:

<UL>
	<LI>Right up front you have components and properties.
	<P>
	<LI>Buried a little deeper you have the delegation model, which involves events and
	method pointers.
	<P>
	<LI>Tying the whole picture together are exceptions and a very 
sophisticated RTTI
	system located in a file called <TT>TYPINFO.HPP</TT>. Most programmers rarely have
	to deal with this side of the product, but it is part and parcel of what makes the
	tool possible in its current form.
</UL>

<P>These are things 
that lie at the core of C++Builder. Don't let anyone else lead
you astray with tales about prototyping or about BCB being a replacement for PowerBuilder.
This tool may in fact perform those roles at times, but that's not what it is all
about.

<DL>
	
<DT></DT>
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>It may be that from a commercial
	perspective the majority of programmers will find the database support to be the
	most valuable aspect of this tool. Indeed, I 
spend a large portion of this book covering
	that subject. However, the emphasis on databases is market-driven, while the technological
	core of the product lies elsewhere. 
<HR>


</BLOCKQUOTE>

<P>To get at the heart of BCB, you have to understand 
components, you have to understand
the delegation model, and you have to understand RTTI. In particular, the first two
points are essential to an understanding of how this product works, while the third
helps you understand why it works.</P>
<P>You 
have, no doubt, either already noticed or have heard talk about the fact that
BCB has some proprietary extensions to C++. These extensions are there to support
the creation and use of components as well as the associated concepts of properties
and 
events that make components so powerful.</P>
<P>There was no way to create a product like BCB without extending C++ to support
components, properties, and the delegation model. This is a better way to program,
and there is no force in the world that 
can suppress it. I have no problem at all
asserting that in five years time, all compilers will support these features and
most programmers will use them by two years from now (1999).</P>
<P>Let me say it one more time, because this is so crucially 
important: What's key
is the component model, and its reliance on properties and events. Components, properties,
the delegation model. Those are the things that stand at the heart of this technology.
The three tools make it easy to build databases or 
multimedia applications. To say
that the tool is primarily about building games or databases or Web sites is putting
the cart before the horse. The tool is primarily about components, properties, and
the delegation model. The other strengths of the 
tool fall out more or less automatically
once the ground work has been laid.
<H4><A NAME="Heading26"></A><FONT COLOR="#000077">Why the VCL?</FONT></H4>
<P>Now that you know something about the environment in which BCB exists, it's time
to dig a little 
deeper and start examining the VCL object model used by BCB. The
VCL (Visual Component Library) is an object-oriented library designed to ease the
process of creating visual components.

<DL>
	<DT></DT>
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT 
COLOR="#000077"><B>NOTE:</B></FONT><B> </B>When I say that BCB uses the VCL,
	I mean for the phrase to be taken in at least two distinct ways. BCB uses the VCL
	in the sense that the physical IDE is literally built into VCL, and also in the sense
	
that we, as BCB programmers, use the VCL as the object model of choice when creating
	applications. Borland is not asking you to do anything they wouldn't do. Delphi is
	built into the VCL. BCB is built into the VCL, and much of Latte, the new Java 
product,
	is built into the VCL. The VCL is the tool of choice for people who have a choice.
	
<HR>


</BLOCKQUOTE>

<P>Many C++ programmers who come to C++Builder find themselves wondering why the
VCL exists in the first place. What was wrong with 
OWL or with MFC? Why should there
be yet another object framework?</P>
<P>The simple answer is that visual programming, RAD, needed a whole new framework
with new features. RAD relied on new concepts such as event handlers, properties,
property 
editors, components, component editors, experts, forms, and a slew of other
features. The language that implemented these new syntactical elements also desperately
needed improvements in the areas of streaming, string handling, object initialization,

and referencing.</P>
<P>These features simply were not available in either the C++ or Object Pascal versions
of OWL. As a result, a new framework was created that supported these features; it
is called the VCL, or Visual Component Library. The name 
goes a long way toward explaining
why OWL could never do this job correctly. This is an object-oriented library built
around visual components, and visual components do not have even the most oblique
reference anywhere in OWL or MFC. They are a 
completely new entity and required their
own object-oriented framework.</P>
<P>Having said that, I should add that VCL is closely related to OWL, just as the
current version of OWL is closely related to the 16-bit version of OWL from which
it grew. If 
you know OWL, you will find much in VCL that is familiar. Indeed, even
MFC is a good background for understanding VCL. However, this is a fundamentally
different kind of beast, one that is built around a new concept called a visual component.

<DL>
	
<DT></DT>
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>I am aware, of course, that ActiveX
	is another specification for building visual components. The difference between ActiveX
	and the VCL is that the VCL is 
specifically designed to be used with advanced programming
	languages such as C++ or Object Pascal. ActiveX was designed to be used in a broader
	context featuring a wide variety of languages and operating systems. ActiveX is more
	powerful than VCL, 
but it is also much bigger, much more complex, and slower. 
<HR>


</BLOCKQUOTE>

<H4><A NAME="Heading29"></A><FONT COLOR="#000077">Come on Charlie, Tell Us What You
Really Think!</FONT></H4>
<P>To conclude this brief introduction to the long 
discussion of the VCL found in
this chapter, I feel it is important to explicitly state that I am aware that many
hardcore C++ programmers will not automatically greet the VCL and its occasional
bits of nonstandard C++ syntax with open arms. When 
writing this chapter, I am conscious
of the need both to explain the VCL and also explain exactly why the VCL exists.</P>
<P>I want to make it absolutely clear that I am one hundred and ten percent committed
to the VCL, and have absolutely no doubt 
that it represents the correct model for
programming at this point in the ongoing development of programming tools and languages.
I will occasionally make statements that explicitly justify some part of the VCL
in the face of possible criticisms. 
These statements do not in any sense represent
doubts in my own mind about the VCL. I prefer the VCL to OWL or MFC, and I am absolutely
certain that all of the extensions to the C++ language that it introduces are necessary
and represent significant 
advances for the language.</P>
<P>I am aware that some readers have large quantities of legacy OWL and MFC code
that they want to preserve. I do not take those needs lightly and feel it is my obligation
to state explicitly why changes have been made 
to the C++ object model.</P>
<P>BCB enables you to use MFC and OWL code, but the only reason this feature exists
is to support legacy code. I personally do not think either MFC or OWL is the best
choice any longer for large programming projects. The 
introduction of the component,
property, delegation model offers such vast improvements in our ability to write
code, that I don't think it's advisable to use OWL or MFC simply because of the poignant
weight of all that legacy code. This is not a 
criticism of these two excellent object
frameworks. The point is simply that they do not support components, properties,
or events, and without that support they don't meet my current needs. I simply cannot
imagine that anyone else who works with BCB 
for any significant length of time could
possibly come to any other conclusion.</P>
<P>I am aware, however, that this is a controversial subject. Over the last four
years I have been using the VCL almost every day. Most of that experience is on the

Delphi side, but I have also been using BCB every day for about five months at the
time of this writing. During the last four years, I have had many occasions to also
use MFC and OWL. After my first six months with the VCL, there was never one single

time that I went back to MFC or OWL without the feeling that I was using a much loved
but outdated system that lacked fundamental features that have become a necessary
part of what I believe to be the best contemporary programming model. This doesn't

mean that I won't use OWL or MFC if it has an existing object in it that I find appealing,
but only that I prefer to use the VCL if that is an option. Indeed, in most cases,
the VCL provides for all my needs.</P>
<P>If a language or programming model 
does not support properties, components, and
delegation, I personally find it lacking, no matter how many other fine features
it may present to the user. VCL is the right way to go, and it would be absurd to
read my occasional arguments on its behalf 
as representative of doubts in my own
mind about this programming model.</P>
<P>In a sense, my job would be easier if the VCL were harder to use. It was very
frustrating for me to realize that I had to start leaving behind all that detailed
knowledge 
about OWL in order to use a system that was so much simpler to use. Wasn't
there something that the VCL was missing? Didn't there have to be a catch? How could
the solution to so many long-term problems turn out to be so simple?</P>
<P>Well, I believe 
that there isn't a catch, and that the VCL does everything that
OWL or MFC did, but does it better. Of course, OWL and VCL have tremendous depth
in terms of the number of objects in the existing hierarchy, which is one reason
why BCB supports them. 
You will find, however, the VCL has great depth itself, and
that it supports all the features, if not all the objects, found in MFC and OWL.
In other words, if you find that a particular object you used in OWL is not part
of VCL, you could either use 
the existing object or create a new one that does the
same thing in the VCL. The VCL supports all the features of OWL, but may not at this
time have duplicates of all its objects. Furthermore, there is tremendous existing
third-party support for the 
VCL that helps fill in some of the gaps.</P>
<P>For good measure, the VCL adds some new tricks regarding components, properties,
and events that can't be found in either OWL or MFC. The kicker, of course, is that
the VCL produces code that is at least 
as fast and small as OWL or MFC, but it is
literally about ten times easier to use.</P>
<P>Let me give it to you straight. Back in the old days I loved OWL and thought it
was the greatest thing I had ever seen. I used it all the time and was a 
fanatical
adherent of that programming model. I now use VCL for everything, and go back to
OWL or MFC only when I absolutely must. To my eyes, the support for components, properties,
and events makes VCL clearly better than OWL or MFC in the same 
sense that OWL was
clearly better than structured programming. If you love OWL, it is sad to hear this
kind of thing, but components, properties, and events simply bring something new
to the table that OWL and MFC simply can't emulate.</P>
<P>It is 
hard to accept the rate at which programming languages are evolving at this
time. The burden this places on programmers is immense. The size of this burden is
one of the key reasons I advocate, again and again, doing things the simplest, easiest,

safest way. You have enough to worry about without trying to figure out the last
picayune details of constantly changing standards!</P>
<P>The learning curve associated with the onrush of progress, our attachment to legacy
code, a sentimental 
attachment to the ANSI committee (of all things!)--none of these
represent a reason to stick with an outdated technology when a clear advancement
in programming tools appears. I obviously have a involvement with Object Pascal.
But I am also a 
long-term (10 years) C++ programmer, and I know about the deep attachment
we all feel to the rules of this language, and I know what a huge improvement OWL
and MFC represent over structured programming. However, things have changed again,
and 
personally, I love it! VCL is wonderful. I never waste two seconds thinking about
going back to the old way of doing things.

<DL>
	<DT></DT>
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>One final note on this 
subject ought
	to go out to readers of my Teach Yourself Windows and Teach Yourself Windows 95 Programming
	books. Those books talk about straight C Windows API programming (a la Petzold) without
	the aid of any object framework. I do not believe 
there is anything in this book
	that makes the material in those books obsolete. <BR>
	<BR>
	To be a good Windows programmer you still have to know the Windows API, and you still
	have to know about message loops and window procedures. Indeed, in 
Delphi 2 Unleashed,
	I went on for several hundred pages about material of that sort. I do not include
	any of that kind of material in this book because there are many C++ programming
	books that cover that material. (There were not any, as far as I 
knew, Pascal books
	that covered that material, which is why I included it in Delphi 2 Unleashed.) <BR>
	<BR>