Wrapper Classes for Third Party Components

May 28, 1998
by Paul Hemmer

The decision to use a third party xtra as a major component in a system can be daunting. The decision needs to be made early on, as portions of the system which use this xtra will rely heavily on the its interface. What if the wrong decision is made? What if a better solution comes along? Such a change would require modifications to several parts of the system to reflect the changing component. As an Object Oriented developer, one of your goals is to design classes in such a way that changes go unnoticed in the surrounding system.

At first glance, this goal might seem insurmountable when a third party component enters the picture. You would never want to pull a component out of a completed system and replace it with a new component that the rest of the system has no idea how to talk to. When using a third party xtra however, a system is forced to rely on the implementation details of a specific xtra. If the choice of xtra should change, you will have to revisit completed classes in the system and fix them to reflect the interface of the new xtra. This presents a problem. How can you protect your system from changes in the choice or the implementation of a third party xtra? The answer is quite simple, you use a wrapper class.

A wrapper class is essentially a layer between your system and a third party component. It's a form of "information hiding", a key concept in OOP, in which the actual xtra is hidden from the system. More importantly, it makes flexible an otherwise inflexible system, a system restricted by the selection of a specific third party xtra. With a wrapper class, you can define a static interface that the rest of the system can talk to regardless of which xtra is being used. The choice of xtra can be delayed if need be while system implementation moves forward. Wrapper classes also allow for the choice to be easily changed in the future if a more suitable product comes along. When such changes are required, no modifications will be needed elsewhere in the system. Simply change the implementation of the methods in the wrapper class to reflect the interface to the new xtra and the change will be made, invisible to the rest of the system. See Figure 1.

Figure 1.

As an example of this technique, consider a system which is going to be driven by the popular v12 Database Engine for Director. Adding a record to a database is a common function to any database xtra. This example will only include one method, that of adding a record to a table in a database. When you are implementing a wrapper class, the entire interface of the xtra you do choose will need to be modeled as in the following example :

-- Parent Script : classDatabaseWrapper
property mDatabaseXtraInstance
on new me, dMode, dPath
    set mDatabaseXtraInstance = new(xtra "v12dbe", ¬
           dPath, dMode, " ")
    return me
end

v12 happens to use the name mAddRecord also. You can give methods in a wrapper class any names you wish -- as it is the communication channel between your system and the third party component. Be sure to document the interface you develop for your wrapper class.

on mAddRecord me, dWhichTable
   mAddRecord(dWhichTable)
end

Notice that mAddRecord is simply calling the mAddRecord method in the v12 Table Xtra. By implementing methods in a similar fashion for every method available through the v12 Database Xtra, the rest of the system can use an instance of this wrapper class as "the database" rather than the actual xtra. The actual database xtra is thereby hidden beneath a layer that you have control over.

At any point during or even after implementation of a system, a new product could very well hit the marketplace which better suits your needs. Or you might have developed a system of classes to perform the needed functionality, and no longer need an xtra. Regardless of the reason, these types of changes could very well occur. Without the existence of a wrapper class in the system, changes like these would lead to potentially radical modifications in portions of your system which relied on the interface of the original xtra, portions of your system which may have been considered finished. But since you had the good sense to see the possibility of change, and you implemented a wrapper class, changes will only need to be made in the wrapper class. Remember, if such a change should occur, all methods in the wrapper class must maintain the same interface so that the rest of the system can remain unaffected. For example, if you were no longer going to use the v12 Database Xtra, you would re-write the implementation of mAddRecord in the wrapper class, without modifying its interface, as follows:

The interface to the method remains the same. Perform the new set of necessary steps to add a record to the specified table. Notice the implementation has changed, but because the interface is the same, the change is invisible to the rest of the system.

on mAddRecord me, dWhichTable
end

Wrapper classes can be easily used to provide a layer between an Object Oriented system and a third party external component. They present a clear example of information hiding, and greatly facilitate system modification. Wrapper classes are an essential component of any Object Oriented programmers bag of tricks.

Paul Hemmer received a BS in Information Technology from Rochester Institute of Technology. He is Senior Developer for a Rochester NY multimedia company. He primarily does Object Oriented Lingo development and lately has doing quite a bit of ASP programming. Paul is very much an advocate of OOP and always tries to push Director beyond its limits. He is committed to increasing awareness of the power and importance of the object oriented mindset and he does his best to make sure everybody on DirectL knows how he feels. Paul's real love is music. He is a bass player who happens to enjoy slinging Lingo by day. ;)