We’ve been learning about Object Oriented Programming over the last several months now and hopefully it’s starting to make some sense. You’re probably wondering how much of this Object Oriented stuff is there to learn. Well, the basic concepts are a little hard to understand at first but eventually that light bulb will go on and you’ll be thinking wow, this is pretty cool! If you haven’t started using your skills in the OOP world yet, this article will teach you about using your OOP objects. Last month’s article described Class Definitions. Now we need to know how to use these Classes that we create in your application development. Different languages support different ways of using what we call "Objects". These objects can be of different types depending on what we are discussing. Some objects are visual objects such as text boxes, forms, windows, or list boxes. Other objects are non-visual objects such as logic objects that are simply objects that contain code that perform business rules for the object. So we’ve been learning about these objects that we can create to do whatever we want them to. They make it easier to do the same or similar functions or jobs over and over. It’s always more productive to use something over than reinvent the wheel every time.

For a quick review, last month I covered the topic of Class Definitions. They are the definitions of the objects we create in source code. Object Oriented Classes are defined by their Properties, Events and Methods. You can think of Properties as variables to hold values needed by your program that are used as temporary storage for calculations and manipulation of data, however, they are part of the object and exist only with the object. The Events and Methods are where the logic to perform the calculations and manipulation of data are stored. In the past public variables were used a lot to store information needed throughout an application. However, with multiple developers working on the same project and in different modules the protection of the values in these variables being used is very important. Consider if you wrote some business logic that used a public variable to store a customer’s account balance. Now if another developer writes a subroutine that changes the variable holding the balance without your knowledge it could be very damaging to the stability of your application.

It’s easy to understand how we can use visual objects such as text boxes and forms in an application because we can visually see them on the screen. Usually your development tool allows you to click on a visual object and place it on a form that you are designing for use in your application. These objects are easier to understand since they have physical parameters that can be seen visually such as width and height and font size. Code can typically be attached to these objects to perform validations or perform calculations. For example when you click on a command button object you may add code into the Click event of the button to add a line item to an invoice. Typically though this code is specific to the form you may be working on and may not be easily reused. However, sometimes you could make a more generic add line item method in a non-visual object that could be called from the command button’s click method with a simple line of code like:

The non-visual object oBusinessObject’s AddLineItem() Method would then have the code in it to add the line item to the current invoice on the form that the command button was on.

Non-visual objects are those that don’t have a visual interface to them and only exist in memory as a type of black box collection of algorithms. Prior to OOP development, programmers created libraries of code that contained all sorts of algorithms such as character string encryption, mortgage calculations or jet engine exhaust velocity calculations (college stuff). These libraries were typically stored in individual source code files or possibly in a library file that contained hundreds of algorithms. These new non-visual objects are basically the same as a library file that contains multiple subroutines in them. However, these subroutines are now referred to as the object’s methods. The nice thing about packaging your source code library in a class definition and instantiating them as an object in your application is the encapsulation of your logic. You as the developer now have a great way to protect your internal variables and properties from becoming corrupted from outside programs since the scope of your variables are limited to the methods in your object, provided you code your classes properly.

Another benefit of creating objects in memory is that you can instantiate more than one object at the same time. This means that you can have multiple independent black boxes all doing their own thing without colliding with each other. For example you could model a business object and then allow the application to open up multiple businesses simultaneously all within the same application but using the same rules without interfering with each other.

Now that we’ve written the code that defines our non-visual objects in a class, we need to use them in our applications. So how do we use them? The first thing that must be done is to create the object in memory from the class definition. In Visual FoxPro we create an object in memory using the CreateObject() method. A memory variable or property is used when creating the object as a reference to the newly created object. For example an object can be created with code like:

So what does this code mean? The oObject variable on the left of the assignment above is a reference to the newly created object in memory based upon the class definition SomeClassDefinition. Once the variable oObject is assigned, we can begin setting properties and calling methods of the object SomeClassDefinition. For example let’s say that the object we created had a method called PrintReport(). In order to execute the code in the PrintReport method, a line of code in your program would be:

Now, the code in the PrintReport method would execute until it was completed. That is if we were working in a single threaded application. But we won’t get into those details at this time. Some objects however, when created in memory have several events that are fired when user interaction occurs with the object. For example if a command button was created and a user clicks on the button then the Click event will fire and whatever code was placed into the click event will be executed.

Hopefully, this helps to give you a better idea of how we use our objects that you define in your application.

The other day a posting was made on a developer’s forum asking why we sometimes refer to what we do as "The art of software development." I would have to say it’s because you must be extremely creative to get around all of the glitches in the operating system and development tools. OK, sometimes it’s the creativeness of figuring out the solution to the problems presented to us by our customers.