Prefactoring

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 ...