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.

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

Objects vs Components
Objects are created from classes and classes are made up of source code – which is language specific and thus can only be used, easily, in one environment. In contrast components are pre-compiled units of binary code – thus they are language independent.

A component based approach to software design enhances the OO approach we first looked at – in the case that a component consists of a group of objects, we can actually define which objects are accessible outside the component (and hence keep some objects restricted to being accessed by other objects inside the component) by defining the interface of the component.

In our application we are going to see that we build a number of class modules that represent the objects we define in our object model; these objects will be tied together in the WroxCommerce ActiveX component. By carefully designing our object model and building a component interface we control how the whole component can be accessed by our presentation layer.

COM
Of course the above section rather glosses over at least one very important topic; how do we get all these components talking to each other? That's where the Component Object Model (COM) comes in – it's Microsoft's standard for allowing objects and components to interact irrespective of the language in which the components were first built. So, using COM technology we can call up a component, and providing we know what interface it has, we can get it to go away and do things for us.

We'll see this in action later this chapter when we build the database class module – we add a reference to the Microsoft ActiveX Data Objects 2.1 Library, which is a COM based library. Using the methods and properties exposed by the ADO 2.1 library we can communicate with a database without worrying about how it's done at the base level.

As part of the COM mechanism, components that we create in VB actually have a number of interfaces that are provided as part of the standard architecture in addition to any interfaces we define. We'll discuss this further at the appropriate time, but the important thing to note is that VB fits seamlessly into COM and as VB developers we are insulated from a great deal of complexity.

ActiveX
ActiveX technology is a wide-ranging term that has evolved alongside the development of distributed computing. It does not generally mean one thing; broadly one can say that the term ActiveX encompasses a set of technologies that each define interfaces between software components to implement some type of functionality. Within this book we are primarily concerned with ActiveX components and Active Scripting (discussed below).

An ActiveX component is an application that stands alone and lets other applications use the classes and objects it contains. The WroxCommerce object model is implemented as an ActiveX DLL and, as we'll see is controlled programmatically – it won't have a user interface itself.

ActiveX component

Active Scripting
ASP pages are able to access ActiveX components through a technology called Active Scripting. We've skated over the previous general theory pretty quickly (as we alluded to, there are whole books written on the subject) but it's probably worth lingering over this particular aspect.

Active Scripting is a reusable scripting engine that, if you want, you can use in your own application. It can be found in use in Active Server Pages (ASP) and Windows Script Host (WSH).

Active Scripting is capable of supporting many languages by allowing developers to write supporting language plug-ins. Active Scripting ships with VBScript (a cut down version of Visual Basic) and JScript. Other vendors have developed PERL plug-ins, as well as support for other languages. Broadly, this means that you can write ASP code in whatever language plug-in you have available, as Active Scripting and the plug-in work together to make the call into the component and, through that call, tell Visual Basic to execute the code contained within the method or property.

ASP works (as illustrated below) by stripping out all of the VBScript code, creating an instance of Active Scripting, and asking it to execute the code on its behalf. ASP presents a set of its own ActiveX components to the context of the script (the environment that the script runs in). So, the Response object we call in ASP is actually an ActiveX component that ships with ASP, and when ASP fires up Active Scripting to run your code, it passes a reference to this component to Active Scripting and asks for it to be made available to your code as Response.