7.2 Benefits

Benefits

Since I'm a very optimistic person, I'll start out with the benefits. However, I want you to understand that all those benefits are based on properly applying object-oriented technology. None of them comes for free just because you use an object-oriented language.

Faster development

The obvious benefit of object-oriented programming is faster development. Fast development is based on a couple of techniques. One of them is rapid prototyping. This technique is especially important for Visual FoxPro programmers because it's one of the strengths of the product. Another fast-development-technique is reuse. There are different kinds of reuse. Code reuse is the most obvious and most popular one. However, design reuse is usually just as important. As a consultant, I often help customers get started with an entirely new project. Very often I reuse a certain framework design that I've had for the last couple of years, but I hardly ever reuse the actual implementation. I have reused this design successfully on a number of projects. Over time, myself and others spent about 8,000 man-hours to design this framework. The time spent to actually implement this design in all the projects together is roughly 3,000 hours. Reusing only small parts of the implementation keeps the system young. I hardly ever use code that's old and outdated. Adjusting the design to match new technologies is a lot easier than adjusting an existing implementation. Nevertheless, it still cuts a major part of development time as the numbers demonstrate.

Unfortunately, creating reusable design and reusable code is not trivial. For this reason, I will talk about this issue in great detail in Chapter 8.

A further promising technique for improving development speed is using components. They can be class libraries that you can use and subclass, or they might be compiled components you can use as ActiveX controls or as COM components. Components have been around for quite a while, but they've just become popular. Their popularity is based on new technology like Microsoft's ActiveX and COM/DCOM standard.

Despite all these techniques, I'm not suggesting that starting your first project in OOP will be faster than going the procedural way. None of the benefits I discussed in the previous paragraphs comes for free. In fact, they are hard to achieve and require extra work.

If you count the number of lines and compare that to the time it took to write those lines, you will find that code is written faster in non-object-oriented projects. That's not unusual. Object-oriented projects are hard to manage because it's very hard to measure their progress. (That's why I devoted a chapter to this topic.) Object-oriented projects don't grow in a linear fashion like procedural ones. This makes them appear slow in the beginning. Later on, things speed up but they slow down again in the end. Don't be fooled by these slightly different dynamics of software development.

Understanding object-oriented technology is crucial for gaining an advantage in development speed. Don't get frustrated when things don't seem to work out right away. After mastering the learning curve, you'll be paid back for all the trouble you went through.

Higher quality

When applying techniques like reuse or implementing existing components, you might be able to drastically increase application quality. Not only is it faster to reuse classes from another project, but a class that worked fine somewhere else is also likely to work fine in the current scenario.

However, this requires following the rules of object-oriented programming. A class that isn't properly encapsulated and self-contained might work in one scenario but not in another. Not only can you take advantage of bug-free components, but you might also end up trapped with bugs or design flaws caused by improper use of object-oriented technology.

Object-oriented technology itself does not guarantee better code quality. Creating high-quality code is still the responsibility of the programmer and not the environment he uses. It's just as easy to write a bad object-oriented program as it was to write a bad procedural one. In fact, bad OOP code tends to be even worse than bad procedural code, because code is spread over many different classes and places. This not only makes it hard to find bad code, it also makes it hard to figure out why code is bad, since you never see the overall picture. However, writing high-quality programs seems to be easier in an object-oriented world, at least for those who know what they're doing.

After all, in many highly complex projects, the difference between good and bad is being able to finish the project at all. In the modern and fast-moving world of computer programs, it seems almost impossible to create complex applications without applying object-oriented technology.

Easier maintenance

Easier maintenance is partly based on higher quality. If the application has fewer defects, it will be easier to maintain. Detecting and fixing defects becomes easier due to the modular architecture of the system. Object-oriented programs are usually better organized because most parts of an application are stored in some kind of library. Libraries typically host a certain group of behavior. This makes it easy to spot where certain defects can be fixed.

However, techniques like inheritance and aggregation may also make it easier to find code that's responsible for possibly buggy behavior.

A typical problem in procedural systems is that one fix usually causes two new bugs. Thanks to the self-contained nature of object-oriented technology, fixes are less likely to break other things. Of course, one might still break code within each class, but the consequences are usually less critical and easier to fix than the defects that might exist throughout the whole system.

An important point when trying to create an easy-to-maintain application is documentation. An object-oriented application that is well documented is much easier to maintain than a well-documented procedural program. However, a poorly documented one will be more difficult to handle than an undocumented procedural application. Inheritance, aggregation and messaging can make it hard to see how things work together, for reasons we discussed earlier.

Reduced cost

The first three benefits result in a fourth benefit: reduced cost.

It's obvious that creating better code that's easier to maintain and can be built in less time must save some money as well. However, keep in mind that none of the three advantages we discussed earlier comes for free. Especially in your first project, where you don't have a lot of classes that can be reused, savings might be little. In fact, you might find yourself spending more money and more time on your first object-oriented project than it would have taken doing it the procedural way. This is not unusual. You have to consider your first object-oriented project as a learning experience and an investment in the future. Don't get frustrated if you don't see the advantages right away. Back home in Austria we have a saying: "Good things take time." This seems to be more true for object-oriented technology than for anything else. Keep in mind: Unless you are willing to do a little extra work and create reusable classes, you might not be able to take advantage of the cost benefits at all.

Using ready-to-go, third-party class libraries and frameworks helps to save some money (and time, but that's the same thing) as well. Even if you might not have the experience to create reusable components right away, other people do. With procedural systems, your problem is that you're stuck with other people's ideas. Somebody might have a tool or code that does almost what you want, but not quite. Changing this product might be just as expensive as creating a new one. However, with object-oriented technology, you can subclass the original components and make all the changes you need. The result is a custom program for the fraction of the cost of creating a new one.

Another way to be more cost efficient is to sell more copies of your product. If you are a tool or component provider, object technology might help you a great deal to sell your products. We already discussed the reasons: Because people will find more components that match their needs if they can modify them a little bit, it is easier to find customers that might have a use for your component.

Increased scalability

Scalability is one of the biggest issues when creating modern software.

Scalability is concerned with application size, the amount of traffic an application can handle, the size of the database that can be managed, and the speed the application maintains when moved from a small scale to a larger one.

Object technology itself is a great tool to create scalable applications. The modularized nature makes it easy to deploy single components over multiple machines. When upsizing a small-scale application, you might face some serious problems that may force you to rewrite. A typical example would be a system using native FoxPro data that has to be migrated to a client/server system. In this scenario, you most likely have to rewrite the part of the application that handles the data. However, rewriting object-oriented software and removing bottlenecks is usually a lot easier than rewriting procedural programs. In a typical scenario, you only have to rewrite a couple of data handling classes or maybe just some methods. As long as the interface remains the same, the rest of the system remains untouched.

New technologies like Component Object Model (COM) components and Distributed COM (DCOM) make it easier to deploy applications over multiple computers. Microsoft Transaction Server (MTS) is doing a great job when it comes to component-based applications. These technologies promise truly fascinating possibilities and make Visual FoxPro 6.0 a great new product.

Better information structures and complexity management

As mentioned earlier, object-oriented applications are better organized than procedural ones. You just can't help but put your classes in libraries and break the application into pieces. Huge and complex tasks are mastered in little steps. Modern and highly complex tasks can hardly be accomplished efficiently in one monolithic step.

This also helps for team development and for testing. Each component, class or method can be tested on its own, possibly even outside the whole system. Clearly defined interfaces allow you to monitor whether the resulting output is according to all specifications and therefore correct. One of the main problems with testing is that the test team can only feed input to the application and monitor the output. Testers have little knowledge about what's going on internally. And even if they did, they couldn't see it. Output might look proper, even if there are serious internal problems. This might be caused by other objects that interact with the tested one, or by preventive programming techniques inside the object that might hide bugs. Even if output looks incorrect, it might be hard to locate the source of the problem. The smaller the pieces are that we can test, the easier it is to spot and fix defects.

Computers may be able to handle extremely complex and huge scenarios, but humans cannot. After all, it's still the programmer who has to make sure his algorithms work. If they become so complex that he has a hard time understanding them himself, code quality will decrease and bugs are unavoidable and hard to fix. Creating many little methods, each just a few lines long and simple to understand, helps to accomplish greater tasks.

Increased adaptability

The best application is useless if it doesn't match the current needs of the users. In the fast-moving and constantly changing modern business world, it's extremely important to be able to change an application quickly and painlessly.

Object-oriented technology makes it easy to make system-wide changes or to add entirely new objects that were never part of the original design. Clearly defined interfaces and standards, as well as the use of object-oriented design patterns, make it possible to plug in new objects without running into many related changes. In procedural systems, scenarios like these are real nightmares, extremely expensive and a serious quality concern.

Better mapping to the problem domain

Everyone thinks that object-oriented programming is terribly abstract. In fact, if you go into a room filled with programmers and say "You know, you really have to think in abstract terms when you do object-oriented programming," you would probably get a universal nodding of heads. If you think about it, that's not the way it is. Procedural applications are the most abstract way to create computer programs that I can think of. Objects, on the other hand, reflect the real-world problem in a more realistic fashion they just do it in a different way.

When creating computer programs, the majority of time and effort goes toward solving technical problems, rather than the business problems the application is meant to solve. This, of course, is a horrible, inefficient scenario. Everything that helps to get away from this technical point of view will help us to be more productive. Object-oriented technology is at least one step toward this goal.

This advantage is a big one for FoxPro programmers. Most xBase programmers aren't technical people. Many have been businessmen that weren't satisfied with the applications they were given and decided to create their own ones. Therefore, they aren't interested in solving technical problems at all. Object-oriented programming will help these people more than anyone else.