Duplication

Introduction

Duplication can become annoying and unmanagable just like Carrot Top.   Computer technology is constantly changing and if a product has several different implementations, maintenance will become a nightmare. To see what happens when duplication turns evil click here...

Concepts of Duplication

• DRY - Don't Repeat Yourself
  Every piece of knowledge must have one, unambiguous, authoritative, representation within a system.
  
  
• Knowledge is never constant
  
  • Code needs to be upgraded frequently.
  • Duplicate knowledge in several places is a maintenance nightmare.
    One change will require you to find and change all the other places the knowledge is duplicated.
    
  
  
• The DRY principle lessens the total volume of code.
  
  
• May take more time to avoid duplication, but it will save you time in the long run.
  i.e. Do not copy and paste code.   It may save you time now, but will cost you later.
  
  
• The DRY principle should be used in documentation, code, and group work.
  
  
• Duplication is NOT a kind of reuse.
  Reuse is a good alternative to duplication.   i.e. Inheritance or composition.
  
  
• EXCEPTION TO THE RULE
  For GUIs, duplication through the copy and paste method is a good practice.

Duplication can also be avoided in code by:

• creating a separate method containing common code.
• creating a superclass if duplication occurs in two separate classes.

Imposed Duplication

• Wrong way:
  public class BasicApp2 {
        public static void main(String[] args) {
              //Process each parameter
              for (int i=0; i < args.length; i++) {
                    //process args[i];
                    //prints the top of the heart
                    System.out.println("  *      *  ");
                    System.out.println("***  ***");
                    System.out.println("*******");
                    // prints out the argument
                    System.out.println(args[i]);
                    // prints the bottom of the heart
                    System.out.println("  *****  ");
                    System.out.println("    ***    ");
                    System.out.println("      *      ");
              }
  
              // Output a message to the console
              System.out.println("Hello World!");
        }
  }
  
  This code sample contains comments that are much too descriptive.   They are a duplication of the code, since they just repeat what the code says.
  
  
• Right way:
  /*
        This class prints out each argument in a heart of stars and prints "Hello World!".
  */
  
  public class printHearts {
        public static void main(String[] args) {
              for (int i=0; i < args.length; i++) {
                    System.out.println("  *      *  ");
                    System.out.println("***  ***");
                    System.out.println("*******");
                    System.out.println(args[i]);
                    System.out.println("  *****  ");
                    System.out.println("    ***    ");
                    System.out.println("      *      ");
              }
              System.out.println("Hello World!");
        }
  }
  
  This version of the code is much cleaner.   It is easier to read without all the unnecessary comments cluttering it.   The overview before the program simply describes its purpose.
  
  

Inadvertent Duplication

• Wrong way:
  class Line {
      public:
        Point start;
        Point end;
        double length;
  };
  Just glancing at this version, it seems like it will work just fine.   Looking more closely we see length is dependent upon the start and end points.   Whenever the start or end points are moved, the length must be reset.
  
  
• Correct way:
  class Line{
      public:
        Point start;
        Point end;
        double length( ) { return start.distanceTo(end); }
  };
  This way is more reasonable. Since the length is dependent on the start and end points, it is written as a function of these two variables. This way when the start or end points are moved, the new length will automatically be reset.

Impatient Duplication

Software Maintenance Nightmare
Situation
A software company makes a printing and book-binding machine.   Twenty different businesses own this product.   Each business's printing and binding machine has a different version of the software to run their machine.

When the software company realizes that their software is expressed in twenty different ways, they ask each business if they can standardize the software.   Each business is skeptical.   Their own printing and binding machine is functioning properly and has been for years.   They do not see any reason why the software should be tampered with.   Their mentality is, "If it ain't broke, don't fix it."

A necessary upgrade to the printing and binding machine surfaces.   This machine prints envelopes and a zip code has changed.   Since each machine has different software on it, twenty different, specialized fixes are needed for each of the twenty machines.   Not only is this a waste of time and money, but it could have been avoided years before.

How could this have happened?
Each machine may have started out with the same code.   The code was copied, pasted, and edited for use in all twenty machines.   If any code changes were made, the company had to go get the source code for that particular machine and then make the change.   These changes expanded the code in each machine into its own version.

How could this have been avoided?
Instead of using the "copy and paste" method, which falls under impatient duplication, ACTUAL reuse should have been used, meaning composition and inheritance.   If time had been taken to include these techniques, time and money would have been saved in the long run.

Avoid Magic Numbers

What is a magic number?
A magic number is a numeric constant/numeric literal embedded in code.   This may include 0, 1, or 2 depending upon the language you are using.

Why are magic numbers bad?

• The number may change in the future due to new requirements, design changes, or code rewrites.   You will have to change every instance of the number.
  
  
• They are not descriptive.
  A person reading your code can't immediately determine what the number describes.
  
  
• A number could change if moved to another platform.

How do you get rid of magic numbers?
Define the literal using a descriptive name.   This name is then used in place of the number throughout your program.

These names gives your code advantages:

• If the number changes, the number only has to be altered in one place (where it is defined).
• Your code is more readable.   A descriptive name reveals more than a literal number.

Examples

1. Eliminate Several Instances of Literal Number
   
   public static final int currentAge = 23;
   
   Every time your age changes, this will be the only place it has to be changed.   This is easier than changing every instance of the numeric literal each time you have a birthday.
   
   
2. Make the Code More Readable
   
   • Wrong way:
     bool apartmentsAvailable = (tenants < 200);
     This way 200 is an ambiguous number.
     
     
   • Correct way:
     public static final int NumberOfApartments = 200; ...
     bool apartmentsAvailable = (tenants < NumberOfApartments);
     Now we can easily see that the tenants variable must be less than the number of Apartments. Also, if the apartment complex expands, then the number of apartments can be easily changed.
   
   
3. Make Sure the Name is Descriptive
   
   • Wrong way:
     for(int i=0; i < 100; i++) {
         ...
     }
     Here 100 is an ambiguous number.
     
     
   • Still wrong:
     public static final int X = 100;
     
     for(int i=0; i < X; i++) {
         ...
     }
     This time X is chosen to represent 100, so we can use X in every instance of 100.   The problem is, we still don't know what X represents since the name is not descriptive.
     
     
   • Correct way:
     public static final int NumOfRecords = 100;
     
     for(int i=0; i < NumOfRecords; i++) {
         ...
     }
     Finally, we can see that the counter must be less than the number of records.   This also gives us some insight into what the loop contains.   It most likely will manipulate each record in some way.
   
   

Reuse VS. Duplication

Reuse and duplication each have their advantages and drawbacks.   Reuse is illustrated using three examples: inheritance, composition, and interfaces.   Duplication is represented by the copy and paste practice.

The main issues considered in making the choice between these four options are ownership, trust, and time.

• Ownership
  Ownership is how much control you have over your class.
  Do other people have access to this class or is it yours alone?
  To what extent do others have access?
  
  
• Trust
  If you trust that the class you want to reuse is reliable, then you will be apt to give up ownership of your own class and trust that the reused class will do the job.
  How much do you trust others' classes?
  
  
• Time
  • Immediate time
    Time that is saved right now.
    
    
  • Long-term time
    Time that is saved in the future.
  
  Is saving a little time now more important to you than saving a lot of time in the future?

Copy and Paste
	Copy and pasting a class creates two separate entities of that class.   This way you will have total ownership of both of these classes.   This may be a good thing in some cases since only changes you make will affect your code.   It will become unmanageable since this one change will have to be made in all copied versions of the code.   This links in with the trust issue.   If you have full ownership of this code then you know you can trust it since you have full control over it.   As far as time is concerned, you will save a lot of time immediately.   In the long run, you will lose time.   One change multiplies into how many copies of the code you have floating around. In the example you can see that the student class has been copied and pasted to make the grad student class.   Duplicating methods saves us time up front.
Inheritance
	A class using inheritance acquires all the methods of the class it inherits from.   You do not have ownership of the inheriting class since it is the parent class plus its own details.   This "is-a" relationship makes the inheriting class vulnerable to any changes made to the parent class.   This is good in the sense that all changes are made down the inheriting line automatically.   This may not be what you want or may happen unexpectedly.   This is where trust comes in.   Your class relies on the trust of the other classes preceding it in the inheritance tree.   Time may not be saved up front, but in the long run less time will be spent on changes since a change to the parent class will make that change for all classes beneath it. In the example Grad Student is a Student plus its own details.   Anything that is added or changed for the Student class will be applied to the inheriting Grad Student class.   A downside is that it makes the classes tightly coupled.
Composition
	A class using composition can use other class' methods.   You have more ownership of your class than with inheritance because the relationship is "has-a" rather than "is-a".   Your class "has-a" class that it can borrow methods from.   You still need to trust the class whose methods you have access to, because a change in them can still affect you.   You are not as reliant on this class in composition as you are with inheritance.   In terms of time, you have the advantages of reuse in the long run, but will use a bit more time up front. In the example Grad Student can use all of Student's methods without relying on it as much as with inheritance.   The classes are less tightly coupled than with inheritance.   You still are liable to be affected by changes made to classes your class is composed of.
Interfaces
	An interface defines a set of methods but does not implement them.   This essentially calls for better specifications for your code and in Java, each program using this interface is checked to make sure it meets all the criteria of the interface.   Interfaces give you ownership of your code.   Since you have ownership, there is less need to worry about trust.   If your interface has been properly defined, then you should find no trouble trusting it.   Plus, Java won't let anyone compile code that does not follow the interface.   This will take more time up front but save you time later. In the example both Student and Grad Student use the Student interface.   They both must implement the methods described in the Student Interface.   This may be a sort of duplication, but it is kept under control by the interface.   It allows programmers who have never talked before to have their programs work together and follow a similar design.   Their systems can use Student and Grad Student almost interchangeably by attaching the interface.   If ownership is more important to you, this might be a good technique to use.

Class Exercise

• Exercise with Duplication
  
  This piece of code contains duplication in the forms of bad comments, magic numbers, and copied and pasted code.   The exercise is to rewrite this class with the duplication taken out.
  
  public class BasicApp {
        public static void main(String[] args) {
              //Sets x to 0
              //Traverses loop until x = 7, incrementing by 1 each time
              for (int x=0; x < 7; x++) {
                    // Sets y to 7 - x
                    // Traverses through
                          for (int y=7-x; y > 0 ; y--) {
                          System.out.print("*");
                          }
                    System.out.println(" ");
              }
  
              //Sets x to 0
              //Traverses loop until x = 7, incrementing by 1 each time
              for (int x=0; x < 7; x++) {
                    // Sets y to 7 - x
                    // Traverses through
                          for (int y=7-x; y > 0 ; y--) {
                          System.out.print("*");
                          }
                    System.out.println(" ");
              }
  
              //Sets x to 0
              //Traverses loop until x = 7, incrementing by 1 each time
              for (int x=0; x < 7; x++) {
                    // Sets y to 7 - x
                    // Traverses through
                          for (int y=7-x; y > 0 ; y--) {
                          System.out.print("*");
                          }
                    System.out.println(" ");
              }
        }
  }
  
  
• Answer Key
  
  Here is one possible solution.   The comments have been removed in favor of a simple but descriptive overview.   The magic numbers have been removed and have been declared as static finals with descriptive names.   The class has even been given a name that clearly indicates what it will do.   The copied and pasted code has been deleted and a for loop is used instead.
  
  /*
        Prints indicated number of triangles of given size.
  */
  
  public class printTriangles {
  
        public static final int numOfTriangles = 3;
        public static final int size = 7;
  
        public static void main(String[] args) {
              for (int reps=0; reps < numOfTriangles; reps++) {
                    for (int row=0; row < size; row++) {
                          for (int col=size-row; col > 0 ; col--) {
                                System.out.print("*");
                          }
                          System.out.println(" ");
                    }
              }
        }
  }