Monday, February 27, 2012

Building the Object Model (concepts behind object oriented programming, COM and ActiveX)

Most modern software can be controlled programmatically through its exposed object models. In fact, most of the applications you use everyday on your Windows PC have an object model, including Microsoft Word, Excel, and Internet

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 Ecommerce application. 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.

There are going to be three basic parts to this article - 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 Ecommerce application . Finally we'll begin to implement the design in VB project.
More specifically our path through the chapter will involve:

  • Looking at object-oriented programming
  • Understanding a little about components
  • Creating a project in Visual Basic
  • 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.


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/2012"

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.

I will cover rest of the bullet points in next article 

1 comment: