Building the Object Model The careful design of these object models is the key to building good software. We're now going to embark on the design, and start the construction, of the business tier for Jo's Coffee. This business tier will consist of a number of objects whose interrelationships are defined by their position in the object model. Implementing the object model will define what we can do within the application. During the course of the chapter we'll be discussing the object-oriented approach to programming as well as ActiveX and COM technology; all topics that directly influence the way we construct the application.

These topics merit whole books on themselves, and we are merely going to provide the background you need for our project. If you wish to know more try Beginning Visual Basic 6 Objects, ISBN 186100172x and VB COM, ISBN 1861002130. Both by Wrox Press.

There are going to be three basic parts to this chapter - we're going to start off with the theory (concepts behind object-oriented programming, COM and ActiveX) then we'll move onto see how that theory influences our design of the object model for Jo's Coffee. Finally we'll begin to implement the design in the WroxCommerce VB project.

More specifically our path through the chapter will involve:

• Looking at object-oriented programming
• Understanding a little about components
• Designing an object model for Jo's Coffee
• Creating a project in Visual Basic
• Building the Visit object
• Building the Database object
• Building the Catalog object

Let's start by looking at object-oriented programming.

Object-Oriented Programming

Object-oriented programming (OOP) is based on the idea that real-world entities or relationships can be represented in code as objects. These code objects have associated with them data and behave in certain ways when asked to. Objects can be linked together to form programs and applications.

Objects may be regarded as black-boxes - the user of an object may know what information needs to be input to the object to get a certain result out, but does not need to know what process goes on inside the object.

OK, let's step back from that rather terse summary and use the metaphor of a television set to explain this concept. We're all pretty conversant with televisions in so much as we know if we input a signal (from aerial, cable, video or wherever) and we use the control set properly we'll get sound and vision. Pushing the buttons allows us to vary the channel we watch, raise or lower the volume, alter the picture brightness, and so on. Most of us don't know the precise workings of the electronics that control the TV, and neither do we care, because we know enough to be able to control it.

Object Behavior

In the first paragraph we said that objects contain data and have behavior; in programming data is represented as variables while behavior is represented by terms familiar to all VB programmers; properties, methods and events. So to continue our TV analogy we could have a property called channel which you could query to discover what channel was being displayed, or alternatively you could set that property to actually change the channel. Note, a property is different to the underlying data - in the case of the channel property the underlying variable may be the actual frequency of the input signal that gives the picture corresponding to that channel number. Methods describe something the object can do, so our television may have IncrementVolumeOneStep or SwitchToVideo methods that are invoked in response to input from the control set. Events occur when an action or state occurs, so the event of pushing the Increase Volume button would fire the IncrementVolumeOneStep method.

Incidentally, the process of objects hiding their internal design and data from the outside world is termed encapsulation. It means an object can hide data and not allow it to be accessed. So on a TV there maybe a TVMustNotBeOnForLongerThan property that controls the maximum length of time a TV can be on before it automatically turns off to ensure it doesn't overheat.

The properties, methods, and events an object has form the interface through which that object can be manipulated.

All this is very familiar in VB where a control like a CommandButton is an object and has, for example, a Caption property and a Click event to which you can attach a method. It acts as a black-box, as you the programmer do not have to worry how the button responds to the click input or how it looks - that has been sorted out for you.

Classes

A class is basically a template from which we stamp out objects (like a biscuit punch) with each created object being termed an instance of the class and the process of creating the object being termed instantiation. In Visual Basic, classes are defined using class modules (in C++, they are simply known as a class).

OOP in Action

The vast majority of object-oriented programming work is concerned with building objects that have no user interface. These objects provide some function to an application. Imagine you are working on a development project in a team and you need access to a billing system that your company owns. One of your colleagues has built a set of objects for talking to this billing system, but it is used on another application. In an object-oriented world, if your colleague has done their job properly, they can give you a copy of the objects, you can plug them into your application and now your application code has access to a billing system through those objects. You haven't had to learn anything about how the billing system works; you've just plugged the objects in.

Let's say our colleague gives us their class module called BillingSystem, (and provides us with information about its properties, methods, and events) in VB we can create instances of it like this:

Dim MyBillingSystem
Set MyBillingSystem = New BillingSystem

Once we've created a billing system object, we can use it:

MyBillingSystem.BillCustomer "Neil", "Mcevoy", "$500", "1/27/2000"

What's happening there is that we know that the BillingSystem object supports a method called BillCustomer. We also know that the code that drives the BillCustomer object is something that we don't understand the internals of - our colleague has been through all that hard work, so we are reusing their efforts. The term reuse is something that comes up time and time again in software development and is an important facet of object-oriented programming. It means that the cost of the time and money we put into developing something can be offset by the fact that whatever original work we come up with can be reused in other applications. This is one of the reasons why people actually sell objects for use in other applications.

Similarly the use of objects within large projects allows for easier maintenance and more flexibility and this is something we will see clearly exemplified when we come to Chapter 9 and talk about the order processing pipeline in the Jo's Coffee project.

Interfaces

We talked above about the interface that a class can present to the world being defined via the public properties, events, and methods it exposes - in fact classes can actually present multiple interfaces to the world via use of the Implements command. Let's say for an instance we develop a new black-box - one that will work as a TV and an Internet access device. When we are programming this device up we start a new class module say ClassInternetBrowser; now we know that this unit should have all the functionality of the TV, so we could add to our new module something like:

Implements ClassTelevision

This would mean that we have to use all the methods, properties, and events we used with a television then additionally we could add properties, methods, and events specifically related to Internet access which would then form a second interface. As an added benefit, although we have to use the same methods etc. for Television we could provide slightly different code, for instance changing the step size in the IncrementVolumeOneStep method.

Components

Building on the idea of object-oriented programming comes component-oriented design, which facilitates even better reuse of the objects we design and build.

Continued...