

                  Separate Views of Component Programming

                           (c) 1995  by  Herb Chong

  The face of Windows programming changed when Visual Basic entered onto
  the Windows programming landscape. Sure, there were other "visual"
  programming languages before Visual Basic appeared, and there were even
  other Windows visual programming tools before Visual Basic, but visual
  programming gained real popularity for business applications when Visual
  Basic appeared. Perhaps it was that Microsoft released it, or perhaps
  that it was mostly based on Basic, a programming language that many
  programmers started with when they were teenagers. No matter. Visual
  Basic is a force to be reckoned with in the Windows development arena.
  For all it's popularity and rapid development capabilities, Visual Basic
  still is a very limited tool in many ways. In this article, Ill look at
  one aspect of Visual Basic and Delphi, components, and how they differ
  in the way they approach components.

  Both Visual Basic and Delphi allow programming by using components. In
  Visual Basic, that mostly means Visual Basic Extensions (VBXs)  but it
  also can include regular Windows Dynamic Link Libraries (DLLs). For
  Delphi, it means VBXs that support Version 1.0 interfaces, DLLs, but
  also a third form, which I will call plain components. Ill first look
  at the component model that Visual Basic and Delphi have in common, and
  then the model which only Delphi has.

  Component Programming

  At first glance, Visual Basic and Delphi appear very much like one
  another. Their development environments look alike and work somewhat
  alike too. To give you an idea of how similar Visual Basic and Delphi
  appear, here are screen shots of each application, ready to begin a new
  programming project. Ive minimized or shut down other things I normally
  keep running so that you can get a better idea of what the development
  environments alone look like. (For those of you that notice these
  things, yes, this is a 1280x1024 desktop, the only way to program. The
  screen shots are full 1280x1024 bitmaps.)

  As you can see, the visual aspects of the two development environ-ments
  are very much like one another. I have deliberately arranged the windows
  of the design environments so that there is more correspondence than usual,
  but I find that I tend to arrange my windows similarly when  developing
  just because I like to keep certain things in certain places. I'm a firm
  believer in "form follows function" and so does Microsoft and Borland.
  To no-ones surprise, because both environments look much like one
  another, they work much like one another too.

  In both these programming tools, you develop new applications by first
  deciding what forms you need. These forms are what end users will see as
  dialogs and windows. Then you select components and draw them on your
  forms. This is part of the visual aspects of these programming tools.
  Another part of the visual aspect is the direct access to code by
  manipulating objects. When you double click on a control in Visual Basic
  or a component in Delphi, the design environment brings up the code for
  the default event of the control or the component. The fact that these
  are Windows development tools forces event-driven programming on you.
  The development tools makes things a bit easier because they know what
  event is most common for a given control or component and help you out
  by going right to it. Finally, you connect the forms together using
  program code to structure their relationships. In a nutshell, this the
  basic approach to Windows programming that you take with these and other
  "visual" programing tools.

  Each control or component has associated with it a set of properties.
  These properties are sometimes called instance data by computer
  scientists. The controls properties are a fundamental part of how you
  program using Visual Basic and Delphi. Properties can define appearance,
  how they interact with the rest of the program, or how they interact
  with the user. Some properties can be set only at design time, when you
  are programming. Others cant be set at all, and yet still others can be
  accessed only when the program is running.

  I'll skip over how the rest of the development environment functions
  because that isnt why I am here. Im here to talk about components and
  their evolution. Visual Basic was one of the first popular visual
  programming languages to come out that used a component model of
  programming. It uses components as a way to package function and data
  into a single object that programmers and users can interact with to do
  something. Components defined the Visual Basic way are pluggable objects
  that you can package up and put into programs when you need them, just
  like a mechanic puts the tools they need into their toolbox. While you
  are designing, its easy to add and remove components as needed. You
  dont finalize the component list until you are ready to build the
  executable version of the program. Delphi follows this model of
  components closely enough that, for all practical purposes, you can
  treat a Delphi component the same as a Visual Basic control if you want.

  So, at first glance, Delphi is nothing more than a refined Visual Basic
  with Borland benefiting from more than 4 years of industry experience
  with visual programming with Visual Basic. If that were all that made up
  Delphi, there wouldnt be much point in continuing this article and,
  frankly, not much point in this article in the first place. That clearly
  isnt the case though. Borlands strength and Microsofts weakness in
  programming languages is objects and object-oriented technology. Delphi
  is significantly more than just components, it uses
  object-oriented-components. Visual Basic 4.0 doesnt do objects, no
  matter what Microsoft says, because the underlying Basic language
  doesnt do objects. Delphi does objects, and that is where the future
  lies. Object-oriented Programming and Design

  So far, I've been talking about how Visual Basic and Delphi are alike.
  However much they are alike on first glance, Visual Basic and Delphi
  come from very different roots and design philosophies. The key to the
  most fundamental difference is that Visual Basics underlying language
  is a structured programming language while Delphis underlying language
  is an object-oriented programming language. What does this mean? Lets
  review some basics of object-oriented programming.

  What does it mean to say that a programming language is an
  object-oriented programming language? The four classic things that an
  object-oriented programming needs to have are: abstraction,
  encapsulation, modularity, and inheritance. What do each of these mean?
  Abstraction

  When programmers talk about abstraction, they talk about modeling
  complex things. Modeling is the process of capturing enough of the
  essential aspects of something complex so that you are able to
  understand and work with it, but at the same time not capturing so much
  that it is still too complex. This is not the only type of abstraction
  there is, but it is probably the most common one that programmers
  encounter.

  For example, creating an object model of your checkbook requires knowing
  that it needs to keep track of your bank transactions, checks you write,
  and your balance. It also requires knowing that you can make deposits
  and withdrawals and what they do to your balance. Knowing what kind of
  paper your checks are printed on and where you keep it are probably not
  important for a program that manages your checkbook. Everything about
  your checkbook gets stored in a class. Its this class definition that
  gets turned into a programming language and that you use in a program.

  An object-oriented programming language allows you to create and manage
  entities that model something that you work with in your program. What
  distinguishes an object-oriented programming language like Object Pascal
  from an ordinary structured programming language like Visual Basic in
  terms of abstraction is that the object-oriented programming language
  allows the programmer to enforce the abstraction. The abstraction is
  more than just a series of conventions that are shared by several
  procedures. The abstraction becomes a fundamental aspect of an object
  and the compiler can make sure that no-one using the object breaks the
  rules of how to use it.

  Encapsulation

  Object oriented programming languages also feature encapsulation. This
  is a fancy way of saying that an object class knows things about itself
  that it is not going to share with anyone else. If you want to know
  something about it from another object, you have to ask nicely. Asking
  nicely means using something the object supplies to obtain the
  information.

  Your class doesnt need to know how a checkbook object stores the
  current balance, or that it even stores one at all. Maybe, because of
  how your program needs to work with a checkbook, you dont even keep a
  running total. Maybe it calculates one each time someone needs to know
  the total. The details of what goes on inside the checkbook class are
  known only to the checkbook class itself. No other class needs to know.
  All they need to know is that the checkbook class has a procedure named
  Balance and that when they use it, they get the current balance of the
  account.

  Object-oriented programming languages allow you to enforce data hiding
  or encapsulation. You can tell the compiler that something isnt to be
  known outside of the object. The only way to access it is via member
  functions in C++ parlance, or methods in Object Pascal. Object Pascal
  enforces the object classs degree of encapsulation by the way the
  programmer designed the class. If the class implementation is written in
  Object Pascal, which they usually are, you can change the class to
  encapsulate differently using the language itself. Visual Basic enforces
  encapsulation by making a VBX something that is written in an entirely
  different language. You cant use Visual Basic to write VBXs.

  Modularity

  Modular programming has been around for a long time and has been seen as
  a good thing for nearly as long. Modularity is what most programmers
  think about when they think components. If you can take a component from
  one program and put it into another program (written in the same
  language usually) and have it work the same, youve got modularity.

  With good design, we should be able to use the checkbook class in both a
  investment management system and in a small business accounting system
  in addition to being part of your electronic checkbook. Modular
  components can do enough by themselves to be useful, but also can work
  well with other object classes to build something more powerful or more
  complex.

  Visual Basics components are essentially VBXs. The rest of the design
  of Visual Basic makes it hard to reuse code and forms in other projects.
  There is just, by nature too much interdependency to allow pulling a form
  out of a project and drop it into another project without a lot of work.
  Delphi's Object Pascal makes the process somewhat easier. You can, with
  good design, package anything from a simple control like a button to an
  entire application as a module and place it into a new application. Object
  oriented programming makes this easier than the older structured
  programming style of programming. This doesnt mean you cant do the same
  thing in Visual Basic, just that it is harder. You have to do the work on
  your own. You won't get any help from the compiler.

  Inheritance

  Up until now, I have only talked about features of an object-oriented
  programming language that exists to some degree in ordinary,
  non-object-oriented languages. Inheritance is where the two make a clean
  break. Inheritance exists only in object-oriented languages and nowhere
  else. Inheritance means that I can use a class as a model and inherit
  from it most of the things that it does, without copying the model
  class, and modify (override) what things I need changed.

  Suppose you needed to make a daily interest checking account class. In
  the non-objected-oriented way of programming, you would either go into
  the checkbook source code and make it know how to do both ordinary
  checkbooks and daily interest ones, or you would copy the checkbook code
  and change it to do daily interest calculations. In an object-oriented
  programming language like Object Pascal, you would derive a new class
  from the checkbook class, call it something different, like daily
  interest checkbook, and add a method to calculate interest daily and
  deposit it to the checking account. You don't look at the old source
  code, and you dont change the old source code. You say, in effect, Im
  just like that class over there, except for these differences. If
  someone using your new class needed to make a deposit, they would use
  the Deposit method, just like they used to with the old class. The same
  thing would happen, because its the old (we say ancestor) classs
  method gets called. It just so h pens that we have magically
  materialized a Deposit method in our own class, all because we inherited
  from the checkbook class. Our class is free to use all of the methods
  too. In the Daily Interest method, the simplest thing to do would be to
  calculate the interest earned and then call the our own

  Deposit method.

  Now how does this relate to VBXs and Delphi components. Well, you cant
  inherit from VBXs. Theres nothing to inherit from because VBXs  arent
  classes, and even if they were, they are written in a completely
  different programming language anyway. You could put an object oriented
  wrapper class around a VBX (something that happens in Delphi and other
  Windows C++ tools), but that still requires the language itself to
  support object oriented programming. Visual Basic doesnt. Delphis
  components are almost all written in Delphi itself. There are a few
  token VBXs to show that Delphi is compatible with them, but even then,
  they have object-oriented wrappers that make them look like classes.
  Where you are supposed spend your time is with components written in
  Delphi itself. They are true classes and follow all the rules of
  inheritance that is so key to this discussion.

  I Want a Widget Almost Like That One

  If you replaced the word widget with VBX, you would describe the anguish
  of many Visual Basic programmers. You cant modify how a VBX works except
  by changing its properties. If there isnt a property to change what you
  want, you are out of luck. You either have to make do without that
  feature, buy someone elses VBX, or write your own. Since you cant write
  a VBX in VB, you probably need a separate programming staff just for VBX
  writing, or you have to learn a lot more about Visual Basic than you want.
  This probably explains the huge VBX market. Most VBXs do almost what you
  want. The situation much different in Delphi. Because the components are
  written in Delphi itself and are written as classes, if you want something
  slightly different, you can derive a new object and make it slightly
  different. Deriving your own new object classes are a fundamental part of
  programming in Delphi, so you are not doing anything different from what
  you would do in normal programming. Just as important, if you derive a new
  class and find that its handy to have around for other project, you can
  make it a part of your standard component libraries, use it, and derive
  from it, just like you would from the components that Borland supplies
  with Delphi. Summary

  Inheritance, one of the most powerful features of object-oriented
  programming, makes Delphis components hugely more flexible than the
  VBXs in Visual Basic. VB 4.0s new OCXs are nothing more than VBXs with
  a new, and much more complex, mask. Visual Basic is still not object
  oriented and OLE components have not much to do with objects, despite
  what Microsoft says.

  Delphi has the foundation of an object-oriented programming language.
  With the foundation, you can use or build an entire object framework and
  class hierarchy to organize your components. Being object-oriented,
  standard object-oriented techniques of object-oriented design and
  programming extend the framework and component class hierarchy. If you
  have ever said to yourself that youd like a VBX almost like that one,
  but not quite, its time for you to switch to Delphi.


  Herb Chong continues to present technical material in very
  understandable language. Herb has been a Contributing Writer to various
  publications like Windows Sources  and Inside Microsoft Windows  as well
  as his leadership as the WindoWatch Contributing Editor. This article is
  the beginning of a Delphi Tutorial Series.


                                     ww


