7.3 Concerns

Concerns

As always, there is no such thing as a free lunch. There are some disadvantages to OOP as well. Most of them are concerned with applying the technology properly, mastering the learning curve, and making the switch to the new paradigm. This last seems to be the major disadvantage. However, object-oriented technology itself is not perfect. There are some downsides attached to the technology that you should be aware of.

Need for standards

Object orientation is a relatively young and steadily developed technology. For this reason, we face a lack of standards. Many systems are still monolithic and hard to link to other environments. However, Microsoft's COM and ActiveX technologies promise some solutions. There are other standards as well, like CORBA for instance, but since they aren't supported by Visual FoxPro, they aren't important to us.

Even COM lacks some features that are crucial for object-oriented programming. Inheritance is one example. However, Visual FoxPro deals better with this problem than any other language I know. It's the only tool that introduces OLE subclassing, which allows you to modify ActiveX controls and apply the rules of programming by exception. Note that this doesn't work for other COM components. (ActiveX is only one of many possible implementations of the COM standard.)

In addition to these global standards, you also need to develop your own. The old saying "Any standard is better than no standard" comes to mind, and I have to agree. Standards are crucial to creating reusable classes and components. Whether or not you want to use a standard like Hungarian Notation, or implement certain patterns, is up to you. No matter which way you want to go, make sure you stick to it. Otherwise, objects won't be able to communicate with each other.

Speed of execution

Objects add overhead to an application. Technologies like inheritance or composition add even more. This results in a speed disadvantage compared to procedural programs. For example, in order to instantiate a program, Visual FoxPro has to go up the inheritance tree to check for a member that needs to be inherited.

However, most modern languages (including Visual FoxPro) are highly optimized to deal with these scenarios. Most concerns with the speed of object-oriented technology are remains of early measurements and observations, which are outdated today. Nevertheless, slight speed penalties will always be the result of the richer set of features that object-oriented technology offers.

Availability of qualified personnel

Although object-oriented programming has been around for some time, it hasn't been widely accepted until recently. This leaves us with a lack of qualified personnel.

The most obvious aspect is the shortage of good object-oriented programmers. However, since object-oriented technology requires a totally different way of doing things, managers and other people involved in a project need to understand this new technology as well. As mentioned above, the dynamics of object-oriented projects are very different from procedural ones. Projects don't grow in a linear fashion. I've worked on many projects that went through crises created by the project manager just because he didn't understand the technology or had wrong expectations.

Training people is extremely important. Unfortunately, the road from procedural programming to real object-oriented development is rather long. Often, sending people to a training class isn't quite enough to make them go through an entire paradigm shift. And making the paradigm shift is required to successfully undertake object-oriented projects. For your first projects, I strongly recommend hiring a consultant or employee who is an expert with object technology. A consultant can guide you through that process and allow everyone to catch up and learn new ways of doing things, which is better than painfully discovering them yourselves or never realizing the advantages.

Costs of conversion

Converting existing procedural applications to object-oriented technology isn't cheap. Costs can result from rewriting and converting the actual application as well as from training people, buying new tools, and replacing outdated components.

Training people will be the biggest initial cost. This includes actual classes and hiring consultants, as well as a likely initial loss of productivity.

Once this hurdle is overcome, you will face creating a base set of classes and components. In this phase, you might encounter a good amount of useless code and classes that have to be replaced later. In many cases, big parts of the system will have to be redesigned as a result of trying to take a procedural path through the jungle of object-oriented technology.

Finally, you face the actual rewrite of the existing application. In the FoxPro world, one typically ends up rewriting the interface. It's often possible to reuse existing code in the methods of behavioral objects. However, it seems that in many cases it turns out to be cheaper to rewrite the whole application in a truly object-oriented fashion, than to convert the old code.

Support for large-scale modularity

Objects do an excellent job of encapsulating functionality and hiding behavior from the outside world on a small-scale level. However, this doesn't work as well on a larger scale. You can combine objects into larger modules using composition, but the basic principles of hiding information and providing clean interfaces are hard to follow, and rules are broken back and forth. External objects are able to access the internals of composite objects in ways they couldn't on smaller scale objects, and even if one manages to hide this information, interfaces become huge and cluttered.

Microsoft's COM components try to resolve this problem. However, they usually don't hide internals properly, and on top of that, they lack some object-oriented features, as discussed above.

Learning curve

There is no doubt that the learning curve is steep. The path between initially understanding object-oriented technology to applying it in real-life projects is long and rocky.

Object-oriented programming is not just about learning a couple of new features. It is about doing things in a totally different way. This paradigm shift cannot be overcome within a couple of days or weeks. You must remember that Visual FoxPro is a hybrid language. It allows you to apply object-oriented technology while continuing to go the procedural way. Unfortunately, semi-object-oriented programs usually lack many advantages that truly object-oriented systems offer, but they still introduce some of the overhead, the leaning curve and possible performance disadvantages.

Don't expect that simply using object-oriented technology without fully understanding it will give you all the advantages you've heard about. If you want to go the object-oriented route, go it all the way! Once you master the learning curve, you'll discover a whole new world of programming. Object-oriented technology makes programming a lot easier, but only for those who know what they're doing. And that's what we're going to spend the rest of the book talking about.