11.3. Unwritten Code

Suppose that we decided to log every call in ZipCodeVerificationTracker 's TRack_this_call( ) method (Example 11-6). There are a number of possibilities for implementing a set of operations, such as a logging class. First, we can write just the features we need for the current situation (the YAGNI [You Ain't Gonna Need It] approach). Second, we can add features that we are sure we will need in the near term . Third, we can look for a prewritten and tested standard library component.

Tim and I have a logger library we have used on several previous projects. We found it as freeware many years ago. The user calls a method to output a comment and a value. The comment and the value converted to a string, along with the time, are placed on a line in a file. The library did the job and we have never had to investigate its internals.

THE EASIEST CODE TO DEBUG IS THAT WHICH IS NOT WRITTEN

Never write functionality that already exists in usable form .

11.3.1. Aspect-Oriented Programming

Another way to avoid writing code is to use Aspect-Oriented Programming (AOP), if your language supports it. With AOP, you can easily add common functionality to classes. AOP modularizes crosscutting concerns , which is behavior that cuts across classes. These crosscutting aspects can include logging, security authorization, performance optimizations, and so forth. So instead of using proxies and a logging library as shown above, you can add logging as an aspect.

Here is a brief introduction to aspects, For more information on aspects, see Aspect-Oriented Software Development by Robert E. Filman, Tzilla Elrad, Siobhan Clarke, and Mehmet Aksit (Addison-Wesley Professional, 2004), or visit http://aosd.net/.

Aspects are coded using either a syntax that closely matches the program language, or XML. Either a preprocessor or a compiler creates extended classes that add the aspect functionality to the application classes.

At particular places in a program, called join points , the regular program and aspects meet. Types of join points include the invocation of a method, the construction of an object, or the execution of an exception handler. ^[*]

^[*] Depending on the implementation of aspects, you can also introduce a new method or attribute to all join points specified by a pointcut.

A pointcut identifies a set of join points. Advice specifies an action to take at a join point. An aspect contains the advice to apply to all the join points in a pointcut.

For example, you can denote a pointcut that identifies all methods . The advice could be to call a log routine. The aspect connects that advice to the pointcut. With a few lines of aspect definition, you add logging of all method calls. For Sam's system, we could identify the find_zip_code_for_address( ) method as the pointcut. The action of logging would not require any changes to the existing code.

11.3.2. More or Less

We decided we needed some more functionality in our logging system for Sam's application. In a few instances in the past, we had to write short programs to analyze the log for certain events. In particular, the ability to count events appearing in a log seemed to be a desirable feature.

We determined that the track_this_call( ) method in Example 11-6 could output a log message every time the method is called. We needed a report of how many times these messages appeared, as well as some other statistics.

We could create our own analyzer. Instead, we searched for a logging package that came with an analyzer that could easily perform the message counting. We found several packages that had many more features than we could imagine ever using. But sometimes, more is less. Often it is easier to take a tool that can do more than you need instead of developing an entirely new tool. ^[*]

^[*] One reviewer noted that sometimes tools have so many features, that it takes longer to learn the tool than it does just to write some code that does just what you want.

We wrote an adapter to simplify the package interface only to those operations we required. The adapter also transformed the package's naming convention to the style of Sam's system.

MORE IS SOMETIMES LESS

Use a prewritten module with more features than you currently need and adapt it to your current needs .

Using a log to get a count might seem like overkill. But using features that already exist is not overdevelopment. We might find that using individual messages impinges on performance. Then we can make the implementation faster ("Don't Speed Until You Know Where You Are Going"). If the number of calls is high, TRack_a_call( ) might output a message every hundredth or millionth time it is called.