Cure

 < Day Day Up > 



Once Over Simplification has reared its ugly head within your code, it will continue to cause problems as long as it is there. Let us look at how to remedy the problem to save time and money.

More Sacred Code

Just as programmers defend the code they have written against replacement by outside code when suffering from NIH Syndrome, they also defend their code against added complexity when suffering from Over Simplification. Treating their code as sacred, they will defy reason in their desire to maintain its simplicity. Before you can consider refactoring, you must convince the owner of the code, which could very well be you, to consider the reasons why added complexity to the code might reduce the overall complexity of the entire code base.

As with NIH Syndrome, the defense of code simplicity might indeed be valid. Before ignoring the sacred code of the programmer, you must be disciplined enough to consider all consequences of the proposed change. The objective of a change that increases the complexity of a particular section of code should be to reduce the overall complexity of the entire code base. Resist the temptation to shift complexity to another programmer when it only benefits you and not the entire development effort.

When to Refactor

Over Simplification causes complexity to appear in the wrong areas of the code. As this complexity appears you should consider the benefits of refactoring, whether you are working on it at the time or just encounter it while browsing the code. It is possible to allow one instance of misplaced complexity to rest, if you are reasonably sure that the particular functionality will not be required again. As soon as similar functionality occurs more than once, the complexity should be refactored because the maintenance of the complexity increases substantially for each occurrence. Chances are high that more occurrences of that complexity will continue to occur.

Up and Down

Refactoring Over Simplification in most cases requires the movement of code between layers of functionality (Figure 5.1). In an object-oriented language, this might be represented by movement within a class hierarchy, but it might also involve movement between hierarchies. Do not constrain your movement of functionality by arbitrary language constructs. Over Simplification is a design problem and is not particular to any programming language features.

click to expand
Figure 5.1: The progression of class complexity over a typical group of classes suffering from Over Simplification. The size of the rectangle representing a class represents the classes’ complexity. Once it becomes obvious that one or more of the classes has become overly complex, refactoring can redistribute the complexity to a more maintainable level.

For example, if you find a function in one class that primarily uses access to members of another class, the function should be moved to the class with the members it is accessing. If you see:

   class Object1 {              // ...       public void someFunction(Object2 object)       {          int someValue = object.getSomeValue();          int someOtherValue = object.getSomeOtherValue();          // Do some stuff with someValue and          // someOtherValue that does not use          // any private members of Object1.          object.setYetAnotherValue(result);       }       // ...    }

This should become:

   class Object2 {              // ...       public void someRefactoredFunction()       {          // Do some stuff with someValue and          // someOtherValue which are already // members of Object2.          yetAnotherValue = result;       }       // ...    }

Duplicate code in multiple derived classes can also indicate an instance where the simplicity of the base class is being preserved at the cost of the derived classes. By moving these functions to a single function in the base class, the overall complexity of the class hierarchy will be reduced even though the base class complexity will rise. These, and other refactorings, should be done as soon as they are found to get the most benefit from the redistribution of complexity.

Libraries for Reuse

Future projects can also increase the benefits of refactoring. After your project discovers the proper level of functionality for a module, through experience and refactoring, that module can be separated into an independent library. This lasting benefit of refactoring is often overlooked because of production deadlines and the excuse that you will never use the code again anyway. To be competitive in the modern world of software development, however, rewriting everything from scratch is no longer a reasonable option. Managers are demanding more code reuse, and you could be stuck with old code despite your desire to throw it away. Since refactoring does have benefits for your project and it will save you headaches if you must reuse the code, it is only logical to maintain the simplicity and reusability of the code without concern for future assumptions.



 < Day Day Up > 



Preventative Programming Techniques. Avoid and Correct Common Mistakes
Preventative Programming Techniques: Avoid and Correct Common Mistakes (Charles River Media Programming)
ISBN: 1584502576
EAN: 2147483647
Year: 2002
Pages: 121
Authors: Brian Hawkins

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net