Thefashion2day Popular Fashion News Website
Related Articles
The cdate Class
One of the biggest problems in the software-development world is maintaining code that we did not design or implement in the first place. Often the hardest thing to do in such cases is to figure out exactly how the code was meant to work. Usually, there is copious documentation that tells you what the code is doing (or what the original programmar thought was going on), but very rarely does it tell you why. The reason is that the business rules and the data that implement those rules are usually embedded somewhere in the code. Hard-coded dates, values — even user names and passwords — can be hidden deep inside the code base. Wouldn’t it be nice if there was some way to extract all of that data and those business rules and put them in one place? This really does sound like a case for encapsulation, now doesn’t it? Of course it does. As I discuss in Technique 1, encapsulation allows us to insulate the user from the implementation of things. That statement is ambiguous and means quite a few things, so to clarify, let me show you a couple of examples. First, consider the case of the business rule. When you are creating code for a software project, you must often consnider rules that apply across the entire business — such as the allowable number of departments in an accounting database, or perhaps a calculation to determine the maximum amount of a pay raise for a given employee. These rules appear in the form of code snippets scattered across the entire project, residing in different files and forms. When the next project comes along, they are often duplicated, modified, or abandoned. The problem with this approach is that it becomes harder and harder to keep track of what the rules are and what they mean.
Testing the cdate Class
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? Ofcourse 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 compennants 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.
Last word
This, then, is the advantage to working with objectoriented programming in C++: You can make changes “behind the scenes” without interfering with the work of others. You make it possible for people to get access to data and algorithms without having to struggle with how they’re stored or implemented. Finally, you can fix or extend the implementations of your algorithms without requiring your users to change all their applications that use those algorithms.
