CSC/ECE 517 Fall 2009/wiki3 4 br: Difference between revisions
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 { | ||
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 - 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
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 - 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.