CSC/ECE 517 Fall 2009/wiki3 4 br: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 17: Line 17:
==='''DRY principle - related to code'''===
==='''DRY principle - related to code'''===


The idea why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync.  As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation."
The idea why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync.  As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]


:*'''''Example''': DRY  
:*'''''Example''': Not applying DRY
   class Person
   public class Student {
     attr_accessor :name
    private String name;
   end
    private String address;
    private String gpa;
    public String getName() { return name; }
    public String getAddress() { return address; }
    public String getGPA() { return gpa; }
    ... other methods and data ...
  }
  public class Employee {
    private String name;
    private String address;
    private String salary;
    public String getName() { return name; }
    public String getAddress() { return address; }
    public String getSalary() { return salary; }
    ... other methods and data ...
  }
 
  public class Person {
     private String name;
    private String address;
    public String getName() { return name; }
    public String getAddress() { return address; }
  }
  public class Student {
    private Person me;
    private String gpa;
    public String getName() { return me.getName; }
    public String getAddress() { return me.getAddress; }
    public String getGPA() { return gpa; }
    ... other methods and data ...
  }
  public class Employee {
    private Person me;
    private String salary;
    public String getName() { return me.getName; }
    public String getAddress() { return me.getAddress; }
    public String getSalary() { return salary; }
    ... other methods and data ...
   }


==='''DRY principle - related to data'''===
==='''DRY principle - related to data'''===

Revision as of 01:24, 10 November 2009

Topic: DRY principle for data Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.


An overview of the concepts

DRY (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) do not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave the same code (or functionality) somewhere else unmodified.


Don't Repeat Yourself

File:DRY.jpg


DRY principle - related to code

The idea why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

  • Example: Not applying DRY
 public class Student {
   private String name;
   private String address;
   private String gpa;
   public String getName() { return name; }
   public String getAddress() { return address; }
   public String getGPA() { return gpa; }
   ... other methods and data ...
 }
 public class Employee {
   private String name;
   private String address;
   private String salary;
   public String getName() { return name; }
   public String getAddress() { return address; }
   public String getSalary() { return salary; }
   ... other methods and data ...
 }
 public class Person {
   private String name;
   private String address;
   public String getName() { return name; }
   public String getAddress() { return address; }

 }
 public class Student {
   private Person me;
   private String gpa;
   public String getName() { return me.getName; }
   public String getAddress() { return me.getAddress; }
   public String getGPA() { return gpa; }
   ... other methods and data ...
 }
 public class Employee {
   private Person me;
   private String salary;
   public String getName() { return me.getName; }
   public String getAddress() { return me.getAddress; }
   public String getSalary() { return salary; }
   ... other methods and data ...
 }

DRY principle - related to data

DRY principle - bad when used with data

DRY principle - good when used with data

Conclusion

References

1. http://en.wikipedia.org/wiki/DRY

2. Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II

3.

4.

5.

6.

7.

8.

9.