The problems with code reuse

Reading this set of guidelines before considering code reuse could facilitate system management and reduce performance errors.

In the ‘90s, there was an explosion of object-oriented programming technologies that promised to reduce the time that humans spent designing and coding computer systems. The 21st century brought us Simple Object Access Protocol (SOAP) and Web services. One of the more useful features from these ideas was code reuse -- a cleverly-built class or service that only has to be written once and is then subsequently reused by everyone.

Is code reuse a new idea?
This wouldn’t be an old man’s column without some grousing. The idea of code reuse isn’t entirely new. Even the oldest programs use subroutines to perform repetitive or low-level tasks. In some sense, COBOL copy books and assembler macros could be said to support a primitive form of reuse. Any mature mainframe shop will have entire libraries of corporate utilities that do everything from addressing envelopes to formatting dates. And finally, a well-designed application might provide an interface module to serve as a gateway for access to its databases.

However, these ideas fall short in some important ways. Subroutines are only useful to the program calling them. Copy book change management can be tricky, as all the programs using it must be recompiled. And corporate utilities are generally limited in functionality and difficult to change.

OOP, Web services and code reuse
OOP hit the big time in the ‘90s with the rise of C++ and Java. These languages broke with previous mainline programming techniques and sequential processing. Instead, OOP gave us classes with attributes (data) and logic (methods). Constructs around the data ensured a class shared only a subset of attributes and kept the rest private, thus forcing callers to use the class’ methods to make state changes. Because of the nature of classes, the methods themselves were kind of disjointed pieces of code that were meant to do something simple, which allowed their logic and length to be smaller and easier to manage.

In the 21st century, service-oriented architecture (SOA) presented itself with the stunning idea that disparate platforms could exchange information through structured, self-defining interfaces. Reusability became a key element as Web services, exposed to the network, could be used by any client that needed the information as long as it provided a well-formed request message.

Blessings and curses
OOP has certainly made life easier for a lot of programmers. It is uniquely suited for graphical user interface applications that are driven by asynchronous messages instead of master files. Inheritance allows any programmer to pick a class off the shelf and add something to make it even better. Finally, code reuse may have finally broken the cycle where each generation of programmers reinvents the wheel.

But there are problems with reuse. For example, some classes may make database calls in their constructor routines, which leads to potential problems when programmers instantiate multiple objects and drive higher I/O rates. The problems get even worse if such a class is instantiated and destroyed several times during a single transaction. Each instantiation reloads the same database records each time.

Problems may also arise if a programmer is unfamiliar with the class and tries to use it as a hammer, when he or she really needs a screwdriver. A bad example may be when someone uses a method to calculate date intervals from a class that was designed to scan the accounts payable database.

SOA is not immune to issues either. While Web services are convenient for cross-platform communication, a project leader with a tight deadline may decide to use an existing Web service instead of creating a new one. Only later does someone realize that calling the old service in batch drives is an unreasonable load to an operational back-end.

The answer
Unfortunately, there are no easy answers to the problems with code reuse. Instead, there are a set of guidelines:

  • Programmers should be aware of a class’ original intent and know what it does behind the scenes. Or, classes should be documented well enough for the programmer to get this information easily.
  • Web services may look at secondary data sources (SDS) if the requestor doesn’t need current data. Getting information from an SDS is cheaper and quicker, which may be important for batch and online systems.
  • Clients should not blindly submit to a Web service without first ascertaining its intended purpose and knowing what happens on the service provider side. If it still makes sense to use the existing Web service, it could be valuable to build a new operation that provides suitable functionality with less drag on the back-end.
  • Programmers should be aware of a class’ functionality before bringing it into their own classes. Using a class for retrieving bank account information might be good for formatting financial fields, but is reading a customer’s full transaction history necessary?
  • Application programmers should consider building an object cache. Caching saves CPU and I/O by storing and reusing data from previously instantiated objects of the same class. This avoids thrashing when the same object gets instantiated multiple times within a transaction.

About the expert: For almost 30 years, Robert Crawford has worked as a mainframe systems programmer. Crawford has experience in system administration as well as debugging and tuning applications. He has coded in COBOL, Assembler and C++ using VSAM, DLI and DB2.

Dig Deeper on Data center design and facilities