Once upon a time, there was a project being done at a very large company. A software audit showed at least five different routines (functions, macros, and inline code) that computed whether a given year was a leap year. This was pretty surprising — but even more surprising was that of those five routines, three were actually wrong. If a bug occurred while the system was calculating whether the current year was a leap year, did the programmer have any idea where to look to solve the problem? Of course not.

In this example, despite the risk of bugs, you still have to determine whether a given date is valid — and whether the given year is a leap year. Your first two basic tasks are to set appropriate defaults for the date, and make sure you can retrieve all the components of the date. The same approach works for any business-rule encapsulation. First, you have to know the pieces of the puzzle that go into the calculations. That way, anyone looking at the code will know exactly what he or she needs to supply. There should be no “hidden” data unless it’s being retrieved from an external source. The code should be plug-and-play; you should be able to take it from one project to another with minimal changes.

Of course, it’s often impossible to completely remove application code from business rules. But that really shouldn’t be your goal when you’re writing business objects. Instead, you should worry about how those objects are going to be used.

When you separate the support code from the business rule that it supports, you separate the bugs that can occur into two types: physical errors and logical errors. This alone saves time in tracking down problems. A logical error won’t crash a program, but it will cause grief in other ways. A physical error isn’t likely to cause you to incorrectly generate checks for billions, but it will crash your application and annoy your users.

Your object should be portable; it is going to be used in multiple projects to support the “date rule.” You want your dates to be valid, and you want to be able to extract the components of the date in any project

that might need that data. At the same time, you don’t want to give people more than they need, so you aren’t going to bother supporting date math, such as calculations for adding days or years to a given date.

This is another important tip when designing classes for use in C++, whether they are business objects or full-blown application objects. Always keep the code down to a minimum; only include what people need. Do not simply add methods to a class for the sheer joy of adding them. If you bury people in code, they will look for something simpler. There is a common acronym for this in the engineering community, known as “KISS”: Keep It Simple, Stupid.

Always bear the error-handling process in mind when you write reusable objects. Your code is more reusable if it returns error messages instead of throwing exceptions or logging errors to some external source. The reason for this advantage is simple: If you require people to do more than check the return value of a method or function in your code, you force them to do a lot of work that they might not otherwise have to do. People resist doing extra work; they’ll avoid your code and use something simpler. (Once again, the KISS principle in action.)

The cDate Class

In order to best encapsulate all of the date information in your program, it is easiest to create a single class that manages date storage, manipulation, and output. In this section, we create a class to do all of that, and call it cDate (for date class, of course). With a date class, we are removing all of the rules and algorithms for manipulating dates, such as leap year calculations, date math, and day of week calculations, and moving them into a single place. In addition, we move the date storage, such as how the day, month, and year elements are stored, into one area that the user does not need to be concerned about.

3. In your code editor, add the code in Listing 5-2 to the source-code file for your application. Alternatively, you could create a new file called date.cpp to store all of this information separately.

These are the non-inline methods for the class. You can put them in the same file as your original source code, or create a new source file and add them to it.