Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-08-01T02:44:21Z

Cadedam: /* Links */

= Problem Statement =
We introduced the idea of low coupling in Lecture 20, and used the Observer pattern as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling. Browse the Web and the ACM DL for other information, both theoretical and practical, and produce a guide to what there is to know about low coupling. Be sure to highlight those aspects that would be appropriate for inclusion in CSC/ECE 517.

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. Coupling between modules/components is their degree of mutual interdependence. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

Examples of low coupling include.
* size: low number of connections between routines
* intimacy: minimal number of connections between routines
* visibility: the prominence of the connection between routines
* flexibility: the ease of changing the connections between routines

= Coupling in Theory =

Coupling level names are presented in order from worse to better: (high coupling is bad)

* Content/Pathological Coupling : (worst) When a module uses/alters data in another
* Control Coupling : 2 modules communicating with a control flag (first tells second what to do via flag)
* Common/Global-data Coupling : 2 modules communicating via global data
* Stamp/Data-structure Coupling : Communicating via a data structure passed as a parameter. The data structure holds more information than the recipient needs.
* Data Coupling : (best) Communicating via parameter passing. The parameters passed are only those that the recipient needs.
* No data coupling : independent modules.

= Coupling in Practice =
http://www.leansoftwareengineering.com/wp-content/uploads/2007/08/abc.jpg

Coupling is easy to measure and understand because it is mechanical in nature and requires less interpretation. Suppose there are three components A, B, and C. A's behavior depends upon B in some way (any way), A’s behavior depends upon C in some way, and the behavior of B and C do not appear to depend upon anything else.

That is the coupling of the system and it is measureable.

= Links =
[http://leansoftwareengineering.com/2007/08/08/what-is-coupling-really/ What is Coupling Really?]

[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling on Wikipedia]

[http://c2.com/cgi/wiki?CouplingAndCohesion Coupling and Cohesion]

[http://pages.cpsc.ucalgary.ca/~eberly/Courses/CPSC333/Lectures/Design/coupling.html Coupling Theory]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-08-01T02:10:19Z

Cadedam:

= Problem Statement =
We introduced the idea of low coupling in Lecture 20, and used the Observer pattern as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling. Browse the Web and the ACM DL for other information, both theoretical and practical, and produce a guide to what there is to know about low coupling. Be sure to highlight those aspects that would be appropriate for inclusion in CSC/ECE 517.

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. Coupling between modules/components is their degree of mutual interdependence. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

Examples of low coupling include.
* size: low number of connections between routines
* intimacy: minimal number of connections between routines
* visibility: the prominence of the connection between routines
* flexibility: the ease of changing the connections between routines

= Coupling in Theory =

Coupling level names are presented in order from worse to better: (high coupling is bad)

* Content/Pathological Coupling : (worst) When a module uses/alters data in another
* Control Coupling : 2 modules communicating with a control flag (first tells second what to do via flag)
* Common/Global-data Coupling : 2 modules communicating via global data
* Stamp/Data-structure Coupling : Communicating via a data structure passed as a parameter. The data structure holds more information than the recipient needs.
* Data Coupling : (best) Communicating via parameter passing. The parameters passed are only those that the recipient needs.
* No data coupling : independent modules.

= Coupling in Practice =
http://www.leansoftwareengineering.com/wp-content/uploads/2007/08/abc.jpg

Coupling is easy to measure and understand because it is mechanical in nature and requires less interpretation. Suppose there are three components A, B, and C. A's behavior depends upon B in some way (any way), A’s behavior depends upon C in some way, and the behavior of B and C do not appear to depend upon anything else.

That is the coupling of the system and it is measureable.

= Links =
[http://leansoftwareengineering.com/2007/08/08/what-is-coupling-really/ What is Coupling Really?]

[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling on Wikipedia]

[http://c2.com/cgi/wiki?CouplingAndCohesion Coupling and Cohesion]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-08-01T02:09:22Z

Cadedam: /* Coupling in Theory */

= Problem Statement =
We introduced the idea of low coupling in Lecture 20, and used the Observer pattern as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling. Browse the Web and the ACM DL for other information, both theoretical and practical, and produce a guide to what there is to know about low coupling. Be sure to highlight those aspects that would be appropriate for inclusion in CSC/ECE 517.

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. Coupling between modules/components is their degree of mutual interdependence. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

Examples of low coupling include.
* size: low number of connections between routines
* intimacy: minimal number of connections between routines
* visibility: the prominence of the connection between routines
* flexibility: the ease of changing the connections between routines

= Coupling in Theory =

Coupling level names are presented in order from worse to better:

Coupling (interdependence between modules) level names: (from worse to better, high coupling is bad)
Content/Pathological Coupling : (worst) When a module uses/alters data in another
Control Coupling : 2 modules communicating with a control flag (first tells second what to do via flag)
Common/Global-data Coupling : 2 modules communicating via global data
Stamp/Data-structure Coupling : Communicating via a data structure passed as a parameter. The data structure holds more information than the recipient needs.
Data Coupling : (best) Communicating via parameter passing. The parameters passed are only those that the recipient needs.
No data coupling : independent modules.

= Coupling in Practice =
http://www.leansoftwareengineering.com/wp-content/uploads/2007/08/abc.jpg

Coupling is easy to measure and understand because it is mechanical in nature and requires less interpretation. Suppose there are three components A, B, and C. A's behavior depends upon B in some way (any way), A’s behavior depends upon C in some way, and the behavior of B and C do not appear to depend upon anything else.

That is the coupling of the system and it is measureable.

= Links =
[http://leansoftwareengineering.com/2007/08/08/what-is-coupling-really/ What is Coupling Really?]
[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling on Wikipedia]
[http://c2.com/cgi/wiki?CouplingAndCohesion Coupling and Cohesion]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-08-01T02:08:22Z

Cadedam: /* Low coupling. */

= Problem Statement =
We introduced the idea of low coupling in Lecture 20, and used the Observer pattern as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling. Browse the Web and the ACM DL for other information, both theoretical and practical, and produce a guide to what there is to know about low coupling. Be sure to highlight those aspects that would be appropriate for inclusion in CSC/ECE 517.

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. Coupling between modules/components is their degree of mutual interdependence. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

Examples of low coupling include.
* size: low number of connections between routines
* intimacy: minimal number of connections between routines
* visibility: the prominence of the connection between routines
* flexibility: the ease of changing the connections between routines

= Coupling in Theory =

= Coupling in Practice =
http://www.leansoftwareengineering.com/wp-content/uploads/2007/08/abc.jpg

Coupling is easy to measure and understand because it is mechanical in nature and requires less interpretation. Suppose there are three components A, B, and C. A's behavior depends upon B in some way (any way), A’s behavior depends upon C in some way, and the behavior of B and C do not appear to depend upon anything else.

That is the coupling of the system and it is measureable.

= Links =
[http://leansoftwareengineering.com/2007/08/08/what-is-coupling-really/ What is Coupling Really?]
[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling on Wikipedia]
[http://c2.com/cgi/wiki?CouplingAndCohesion Coupling and Cohesion]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-08-01T02:06:29Z

Cadedam: /* Links */

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-08-01T01:44:38Z

Cadedam:

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-08-01T01:44:20Z

Cadedam: /* Coupling in Practice */

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-08-01T01:44:06Z

Cadedam:

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-08-01T01:43:36Z

Cadedam:

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-31T21:21:23Z

Cadedam: /* Low coupling. */

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-31T21:18:59Z

Cadedam:

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:55:30Z

Cadedam:

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= Observer Pattern Example =

Here is an example that takes keyboard input and treats each input line as an event. The example is built upon the library classes <tt>java.util.Observer</tt> and <tt>java.util.Observable</tt>. When a string is supplied from System.in, the method <tt>notifyObserver</tt> is then called, in order to notify all observers of the event's occurrence, in the form of an invocation of their 'update' methods - in our example, <tt>ResponseHandler.update(...)</tt>.

The file myapp.java contains a main() method that might be used in order to run the code.

/* File Name : EventSource.java */

package OBS;
import java.util.Observable; //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable
{
public void run()
{
try
{
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true )
{
final String response = br.readLine();
setChanged();
notifyObservers( response );
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
</source>

/* File Name: ResponseHandler.java */

package OBS;

import java.util.Observable;
import java.util.Observer; /* this is Event Handler */

public class ResponseHandler implements Observer
{
private String resp;
public void update (Observable obj, Object arg)
{
if (arg instanceof String)
{
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}
</source>

/* Filename : myapp.java */
/* This is main program */

package OBS;

public class myapp
{
public static void main(String args[])
{
System.out.println("Enter Text >");

// create an event source - reads from stdin
final EventSource evSrc = new EventSource();

// create an observer
final ResponseHandler respHandler = new ResponseHandler();

// subscribe the observer to the event source
evSrc.addObserver( respHandler );

// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}
</source>

Also refer to an article in JavaWorld
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:54:22Z

Cadedam: /* highlights */

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:41:40Z

Cadedam:

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= Observer Pattern Example =

Here is an example that takes keyboard input and treats each input line as an event. The example is built upon the library classes <tt>java.util.Observer</tt> and <tt>java.util.Observable</tt>. When a string is supplied from System.in, the method <tt>notifyObserver</tt> is then called, in order to notify all observers of the event's occurrence, in the form of an invocation of their 'update' methods - in our example, <tt>ResponseHandler.update(...)</tt>.

The file myapp.java contains a main() method that might be used in order to run the code.

/* File Name : EventSource.java */

package OBS;
import java.util.Observable; //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable
{
public void run()
{
try
{
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true )
{
final String response = br.readLine();
setChanged();
notifyObservers( response );
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
</source>

/* File Name: ResponseHandler.java */

package OBS;

import java.util.Observable;
import java.util.Observer; /* this is Event Handler */

public class ResponseHandler implements Observer
{
private String resp;
public void update (Observable obj, Object arg)
{
if (arg instanceof String)
{
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}
</source>

/* Filename : myapp.java */
/* This is main program */

package OBS;

public class myapp
{
public static void main(String args[])
{
System.out.println("Enter Text >");

// create an event source - reads from stdin
final EventSource evSrc = new EventSource();

// create an observer
final ResponseHandler respHandler = new ResponseHandler();

// subscribe the observer to the event source
evSrc.addObserver( respHandler );

// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}
</source>

Also refer to an article in JavaWorld
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

= highlights =
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:19:32Z

Cadedam: /* Java */

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= Observer Pattern Example =

Here is an example that takes keyboard input and treats each input line as an event. The example is built upon the library classes <tt>java.util.Observer</tt> and <tt>java.util.Observable</tt>. When a string is supplied from System.in, the method <tt>notifyObserver</tt> is then called, in order to notify all observers of the event's occurrence, in the form of an invocation of their 'update' methods - in our example, <tt>ResponseHandler.update(...)</tt>.

The file myapp.java contains a main() method that might be used in order to run the code.

/* File Name : EventSource.java */

package OBS;
import java.util.Observable; //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable
{
public void run()
{
try
{
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true )
{
final String response = br.readLine();
setChanged();
notifyObservers( response );
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
</source>

/* File Name: ResponseHandler.java */

package OBS;

import java.util.Observable;
import java.util.Observer; /* this is Event Handler */

public class ResponseHandler implements Observer
{
private String resp;
public void update (Observable obj, Object arg)
{
if (arg instanceof String)
{
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}
</source>

/* Filename : myapp.java */
/* This is main program */

package OBS;

public class myapp
{
public static void main(String args[])
{
System.out.println("Enter Text >");

// create an event source - reads from stdin
final EventSource evSrc = new EventSource();

// create an observer
final ResponseHandler respHandler = new ResponseHandler();

// subscribe the observer to the event source
evSrc.addObserver( respHandler );

// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}
</source>

Also refer to an article in JavaWorld
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

= theoretical =

= practical =

and produce a guide to what there is to know about low coupling. Be sure to

= highlights =
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:18:50Z

Cadedam: /* Java */

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= Observer Pattern Example =

= Java =
Here is an example that takes keyboard input and treats each input line as an event. The example is built upon the library classes <tt>java.util.Observer</tt> and <tt>java.util.Observable</tt>. When a string is supplied from System.in, the method <tt>notifyObserver</tt> is then called, in order to notify all observers of the event's occurrence, in the form of an invocation of their 'update' methods - in our example, <tt>ResponseHandler.update(...)</tt>.

The file myapp.java contains a main() method that might be used in order to run the code.

/* File Name : EventSource.java */

package OBS;
import java.util.Observable; //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable
{
public void run()
{
try
{
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true )
{
final String response = br.readLine();
setChanged();
notifyObservers( response );
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
</source>

/* File Name: ResponseHandler.java */

package OBS;

import java.util.Observable;
import java.util.Observer; /* this is Event Handler */

public class ResponseHandler implements Observer
{
private String resp;
public void update (Observable obj, Object arg)
{
if (arg instanceof String)
{
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}
</source>

/* Filename : myapp.java */
/* This is main program */

package OBS;

public class myapp
{
public static void main(String args[])
{
System.out.println("Enter Text >");

// create an event source - reads from stdin
final EventSource evSrc = new EventSource();

// create an observer
final ResponseHandler respHandler = new ResponseHandler();

// subscribe the observer to the event source
evSrc.addObserver( respHandler );

// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}
</source>

Also refer to an article in JavaWorld
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

= theoretical =

= practical =

and produce a guide to what there is to know about low coupling. Be sure to

= highlights =
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:18:24Z

Cadedam: /* Java */

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= Observer Pattern Example =

= Java =
Here is an example that takes keyboard input and treats each input line as an event. The example is built upon the library classes <tt>java.util.Observer</tt> and <tt>java.util.Observable</tt>. When a string is supplied from System.in, the method <tt>notifyObserver</tt> is then called, in order to notify all observers of the event's occurrence, in the form of an invocation of their 'update' methods - in our example, <tt>ResponseHandler.update(...)</tt>.

The file myapp.java contains a main() method that might be used in order to run the code.

<source lang="java">
/* File Name : EventSource.java */

package OBS;
import java.util.Observable; //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable
{
public void run()
{
try
{
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true )
{
final String response = br.readLine();
setChanged();
notifyObservers( response );
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
</source>

<source lang="java">
/* File Name: ResponseHandler.java */

package OBS;

import java.util.Observable;
import java.util.Observer; /* this is Event Handler */

public class ResponseHandler implements Observer
{
private String resp;
public void update (Observable obj, Object arg)
{
if (arg instanceof String)
{
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}
</source>

<source lang="java">
/* Filename : myapp.java */
/* This is main program */

package OBS;

public class myapp
{
public static void main(String args[])
{
System.out.println("Enter Text >");

// create an event source - reads from stdin
final EventSource evSrc = new EventSource();

// create an observer
final ResponseHandler respHandler = new ResponseHandler();

// subscribe the observer to the event source
evSrc.addObserver( respHandler );

// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}
</source>

Also refer to an article in JavaWorld
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

= theoretical =

= practical =

and produce a guide to what there is to know about low coupling. Be sure to

= highlights =
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:18:02Z

Cadedam: /* Java */

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= Observer Pattern Example =

= Java =
Here is an example that takes keyboard input and treats each input line as an event. The example is built upon the library classes <tt>java.util.Observer</tt> and <tt>java.util.Observable</tt>. When a string is supplied from System.in, the method <tt>notifyObserver</tt> is then called, in order to notify all observers of the event's occurrence, in the form of an invocation of their 'update' methods - in our example, <tt>ResponseHandler.update(...)</tt>.

The file myapp.java contains a main() method that might be used in order to run the code.

<source lang="java">
/* File Name : EventSource.java */

package OBS;
import java.util.Observable; //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable
{
public void run()
{
try
{
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true )
{
final String response = br.readLine();
setChanged();
notifyObservers( response );
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
</source>

<source lang="java">
/* File Name: ResponseHandler.java */

package OBS;

import java.util.Observable;
import java.util.Observer; /* this is Event Handler */

public class ResponseHandler implements Observer
{
private String resp;
public void update (Observable obj, Object arg)
{
if (arg instanceof String)
{
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}
</source>

<source lang="java">
/* Filename : myapp.java */
/* This is main program */

package OBS;

public class myapp
{
public static void main(String args[])
{
System.out.println("Enter Text >");

// create an event source - reads from stdin
final EventSource evSrc = new EventSource();

// create an observer
final ResponseHandler respHandler = new ResponseHandler();

// subscribe the observer to the event source
evSrc.addObserver( respHandler );

// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}
</source>

Also refer to an article in JavaWorld
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

= theoretical =

= practical =

and produce a guide to what there is to know about low coupling. Be sure to

= highlights =
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:17:46Z

Cadedam: /* Java */

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= Observer Pattern Example =

= Java =
Here is an example that takes keyboard input and treats each input line as an event. The example is built upon the library classes <tt>java.util.Observer</tt> and <tt>java.util.Observable</tt>. When a string is supplied from System.in, the method <tt>notifyObserver</tt> is then called, in order to notify all observers of the event's occurrence, in the form of an invocation of their 'update' methods - in our example, <tt>ResponseHandler.update(...)</tt>.

The file myapp.java contains a main() method that might be used in order to run the code.

<source lang="java">
/* File Name : EventSource.java */

package OBS;
import java.util.Observable; //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable
{
public void run()
{
try
{
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true )
{
final String response = br.readLine();
setChanged();
notifyObservers( response );
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
</source>

<source lang="java">
/* File Name: ResponseHandler.java */

package OBS;

import java.util.Observable;
import java.util.Observer; /* this is Event Handler */

public class ResponseHandler implements Observer
{
private String resp;
public void update (Observable obj, Object arg)
{
if (arg instanceof String)
{
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}
</source>

<source lang="java">
/* Filename : myapp.java */
/* This is main program */

package OBS;

public class myapp
{
public static void main(String args[])
{
System.out.println("Enter Text >");

// create an event source - reads from stdin
final EventSource evSrc = new EventSource();

// create an observer
final ResponseHandler respHandler = new ResponseHandler();

// subscribe the observer to the event source
evSrc.addObserver( respHandler );

// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}
</source>

Also refer to an article in JavaWorld
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

= theoretical =

= practical =

and produce a guide to what there is to know about low coupling. Be sure to

= highlights =
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:17:26Z

Cadedam: /* Java */

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= Observer Pattern Example =

= Java =
Here is an example that takes keyboard input and treats each input line as an event. The example is built upon the library classes <tt>java.util.Observer</tt> and <tt>java.util.Observable</tt>. When a string is supplied from System.in, the method <tt>notifyObserver</tt> is then called, in order to notify all observers of the event's occurrence, in the form of an invocation of their 'update' methods - in our example, <tt>ResponseHandler.update(...)</tt>.

The file myapp.java contains a main() method that might be used in order to run the code.

<source lang="java">
/* File Name : EventSource.java */

package OBS;
import java.util.Observable; //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable
{
public void run()
{
try
{
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true )
{
final String response = br.readLine();
setChanged();
notifyObservers( response );
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
</source>

<source lang="java">
/* File Name: ResponseHandler.java */

package OBS;

import java.util.Observable;
import java.util.Observer; /* this is Event Handler */

public class ResponseHandler implements Observer
{
private String resp;
public void update (Observable obj, Object arg)
{
if (arg instanceof String)
{
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}
</source>

<source lang="java">
/* Filename : myapp.java */
/* This is main program */

package OBS;

public class myapp
{
public static void main(String args[])
{
System.out.println("Enter Text >");

// create an event source - reads from stdin
final EventSource evSrc = new EventSource();

// create an observer
final ResponseHandler respHandler = new ResponseHandler();

// subscribe the observer to the event source
evSrc.addObserver( respHandler );

// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}
</source>

Also refer to an article in JavaWorld
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

= theoretical =

= practical =

and produce a guide to what there is to know about low coupling. Be sure to

= highlights =
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:16:40Z

Cadedam: /* Java */

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= Observer Pattern Example =

= Java =
Here is an example that takes keyboard input and treats each input line as an event. The example is built upon the library classes <tt>java.util.Observer</tt> and <tt>java.util.Observable</tt>. When a string is supplied from System.in, the method <tt>notifyObserver</tt> is then called, in order to notify all observers of the event's occurrence, in the form of an invocation of their 'update' methods - in our example, <tt>ResponseHandler.update(...)</tt>.

The file myapp.java contains a main() method that might be used in order to run the code.

<source lang="java">
/* File Name : EventSource.java */

package OBS;
import java.util.Observable; //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable
{
public void run()
{
try
{
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true )
{
final String response = br.readLine();
setChanged();
notifyObservers( response );
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
</source>
<source lang="java">
/* File Name: ResponseHandler.java */

package OBS;

import java.util.Observable;
import java.util.Observer; /* this is Event Handler */

public class ResponseHandler implements Observer
{
private String resp;
public void update (Observable obj, Object arg)
{
if (arg instanceof String)
{
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}
</source>
<source lang="java">
/* Filename : myapp.java */
/* This is main program */

package OBS;

public class myapp
{
public static void main(String args[])
{
System.out.println("Enter Text >");

// create an event source - reads from stdin
final EventSource evSrc = new EventSource();

// create an observer
final ResponseHandler respHandler = new ResponseHandler();

// subscribe the observer to the event source
evSrc.addObserver( respHandler );

// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}
</source>

Also refer to an article in JavaWorld
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

= theoretical =

= practical =

and produce a guide to what there is to know about low coupling. Be sure to

= highlights =
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:15:48Z

Cadedam: /* Java */

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= Observer Pattern Example =

= Java =
Here is an example that takes keyboard input and treats each input line as an event. The example is built upon the library classes <tt>java.util.Observer</tt> and <tt>java.util.Observable</tt>. When a string is supplied from System.in, the method <tt>notifyObserver</tt> is then called, in order to notify all observers of the event's occurrence, in the form of an invocation of their 'update' methods - in our example, <tt>ResponseHandler.update(...)</tt>.

The file myapp.java contains a main() method that might be used in order to run the code.

<source lang="java">
/* File Name : EventSource.java */

package OBS;
import java.util.Observable; //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable
{
public void run()
{
try
{
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true )
{
final String response = br.readLine();
setChanged();
notifyObservers( response );
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
</source>
<source lang="java">
/* File Name: ResponseHandler.java */

package OBS;

import java.util.Observable;
import java.util.Observer; /* this is Event Handler */

public class ResponseHandler implements Observer
{
private String resp;
public void update (Observable obj, Object arg)
{
if (arg instanceof String)
{
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}
</source>
<source lang="java">
/* Filename : myapp.java */
/* This is main program */

package OBS;

public class myapp
{
public static void main(String args[])
{
System.out.println("Enter Text >");

// create an event source - reads from stdin
final EventSource evSrc = new EventSource();

// create an observer
final ResponseHandler respHandler = new ResponseHandler();

// subscribe the observer to the event source
evSrc.addObserver( respHandler );

// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}
</source>

Also refer to an article in JavaWorld
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

= theoretical =

= practical =

and produce a guide to what there is to know about low coupling. Be sure to

= highlights =
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T02:15:11Z

Cadedam:

= Low coupling. =

Coupling in Software Design can be either High or Low. What this means is that object and classes in your code can exist indepently of other objects or classes. For example a system that has high coupling might experience the following issues:

* Change in one module forces a ripple of changes in other modules.
* Modules are difficult to understand in isolation.
* Modules are difficult to reuse or test because dependent modules must be included.

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= Observer Pattern Example =

===Java===
Here is an example that takes keyboard input and treats each input line as an event. The example is built upon the library classes <tt>java.util.Observer</tt> and <tt>java.util.Observable</tt>. When a string is supplied from System.in, the method <tt>notifyObserver</tt> is then called, in order to notify all observers of the event's occurrence, in the form of an invocation of their 'update' methods - in our example, <tt>ResponseHandler.update(...)</tt>.

The file myapp.java contains a main() method that might be used in order to run the code.

<source lang="java">
/* File Name : EventSource.java */

package OBS;
import java.util.Observable; //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable
{
public void run()
{
try
{
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true )
{
final String response = br.readLine();
setChanged();
notifyObservers( response );
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
</source>
<source lang="java">
/* File Name: ResponseHandler.java */

package OBS;

import java.util.Observable;
import java.util.Observer; /* this is Event Handler */

public class ResponseHandler implements Observer
{
private String resp;
public void update (Observable obj, Object arg)
{
if (arg instanceof String)
{
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}
</source>
<source lang="java">
/* Filename : myapp.java */
/* This is main program */

package OBS;

public class myapp
{
public static void main(String args[])
{
System.out.println("Enter Text >");

// create an event source - reads from stdin
final EventSource evSrc = new EventSource();

// create an observer
final ResponseHandler respHandler = new ResponseHandler();

// subscribe the observer to the event source
evSrc.addObserver( respHandler );

// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}
</source>

Also refer to an article in JavaWorld
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

= theoretical =

= practical =

and produce a guide to what there is to know about low coupling. Be sure to

= highlights =
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T01:59:40Z

Cadedam: /* Low coupling. */

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T01:29:41Z

Cadedam:

= Low coupling. =

We introduced the idea of low coupling in Lecture 20,

= The Observer pattern =
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

= theoretical =

= practical =

and produce a guide to what there is to know about low coupling. Be sure to

= highlights =
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T01:28:48Z

Cadedam:

= Low coupling.=

We introduced the idea of low coupling in Lecture 20,

The Observer pattern
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

theoretical

practical,

and produce a guide to what there is to know about low coupling. Be sure to

highlights
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 Assignment

2008-07-27T01:13:47Z

Cadedam:

#[[CSC/ECE_517_Summer_2008/wiki3_1_th | RDB/OO Patterns]]
#[[CSC/ECE_517_Summer_2008/wiki3_1_PF | Pure Fabrication]]
#[[CSC/ECE_517_Summer_2008/wiki3_3_cd | Low Coupling]]
#[[CSC/ECE_517_Summer_2008/wiki3_5_rp | Pure Fabrication]]
#[[CSC/ECE_517_Summer_2008/wiki3_7_SHOP_PAT | Shopper Pattern]]
#[[CSC/ECE_517_Summer_2008/wiki3_6_esb | Protected Variation]]
----
[[CSC/ECE 517 Summer 2008]]

CSC/ECE 517 Summer 2008/wiki3 Assignment

2008-07-27T01:13:24Z

Cadedam:

#[[CSC/ECE_517_Summer_2008/wiki3_1_th | RDB/OO Patterns]]
#[[CSC/ECE_517_Summer_2008/wiki3_1_PF | Pure Fabrication]]
#[[ECE_517_Summer_2008/wiki3_3_cd | Low Coupling]]
#[[CSC/ECE_517_Summer_2008/wiki3_5_rp | Pure Fabrication]]
#[[CSC/ECE_517_Summer_2008/wiki3_7_SHOP_PAT | Shopper Pattern]]
#[[CSC/ECE_517_Summer_2008/wiki3_6_esb | Protected Variation]]
----
[[CSC/ECE 517 Summer 2008]]

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T01:12:16Z

Cadedam:

Low coupling.

We introduced the idea of low coupling in Lecture 20,

The Observer pattern
as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling.

Browse the Web and the ACM DL for other information, both

theoretical

practical,

and produce a guide to what there is to know about low coupling. Be sure to

highlights
those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki3 3 cd

2008-07-27T01:06:25Z

Cadedam:

Low coupling. We introduced the idea of low coupling in Lecture 20, and used the Observer pattern as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling. Browse the Web and the ACM DL for other information, both theoretical and practical, and produce a guide to what there is to know about low coupling. Be sure to highlight those aspects that would be appropriate for inclusion in CSC/ECE 517.

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T12:49:48Z

Cadedam: /* DRY Principle - Always Good? */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code
generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc]
uses the existing Java code to generate documentation for its code. If the documentation
was written independently of the code then changes to the code would very likely require
changes in the documentation. With JavaDoc, since the documentation is generated from the
source code, the documentation will still be relevant after maintenance is performed on the
code. Using code generators like JavaDoc helps to allow a single authority on a piece of
knowledge within in the code to be maintained. The programmer changes the code and the
change is properly documented as a result.

Database Example

Let's say we are storing purchase information in a database and have a
field for quantity and item and total. So, we create a database table as follows:

PK Purchase_ID
ItemPrice
ItemQuantity
TotalPrice

Since TotalPrice is actually calculated by multiplying ItemPrice by the ItemQuantity
we should instead have a table that looks like the following:

PK Purchase_ID
ItemPrice
ItemQuantity

The total price can be calculated once the data is retrieved. This allows us not
to duplicate values in the database table.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T02:15:10Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code
generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc]
uses the existing Java code to generate documentation for its code. If the documentation
was written independently of the code then changes to the code would very likely require
changes in the documentation. With JavaDoc, since the documentation is generated from the
source code, the documentation will still be relevant after maintenance is performed on the
code. Using code generators like JavaDoc helps to allow a single authority on a piece of
knowledge within in the code to be maintained. The programmer changes the code and the
change is properly documented as a result.

Database Example

Let's say we are storing purchase information in a database and have a
field for quatity and item and total. So, we create a database table as follows:

PK Purchase_ID
ItemPrice
ItemQuantity
TotalPrice

Since TotalPrice is actually calculated by multiplying ItemPrice by the ItemQuantity
we should instead have a table that looks like the following:

PK Purchase_ID
ItemPrice
ItemQuantity

The total price can be calculated once the data is retrieved. This allows us not
to duplicate values in the database table.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T02:14:50Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code
generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc]
uses the existing Java code to generate documentation for its code. If the documentation
was written independently of the code then changes to the code would very likely require
changes in the documentation. With JavaDoc, since the documentation is generated from the
source code, the documentation will still be relevant after maintenance is performed on the
code. Using code generators like JavaDoc helps to allow a single authority on a piece of
knowledge within in the code to be maintained. The programmer changes the code and the
change is properly documented as a result.

Database Example

Let's say we are storing purchase information in a database and have a
field for quatity and item and total. So, we create a database table as follows:

PK Purchase_ID
ItemPrice
ItemQuantity
TotalPrice

Since TotalPrice is actually calculated by multiplying ItemPrice by the ItemQuantity
we should instead have a table that looks like the following:

PK Purchase_ID
ItemPrice
ItemQuantity
TotalPrice

The total price can be calculated once the data is retrieved. This allows us not
to duplicate values in the database table.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T02:13:49Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing Java code to generate documentation for its code. If the documentation was written independently of the code then changes to the code would very likely require changes in the documentation. With JavaDoc, since the documentation is generated from the source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

Database Example

Let's say we are storing purchase information in a database and have a
field for quatity and item and total. So, we create a database table as follows:

PK Purchase_ID
ItemPrice
ItemQuantity
TotalPrice

Since TotalPrice is actually calculated by multiplying ItemPrice by the ItemQuantity
we should instead have a table that looks like the following:

PK Purchase_ID
ItemPrice
ItemQuantity
TotalPrice

The total price can be calculated once the data is retrieved. This allows us not
to duplicate values in the database table.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T02:13:33Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing Java code to generate documentation for its code. If the documentation was written independently of the code then changes to the code would very likely require changes in the documentation. With JavaDoc, since the documentation is generated from the source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

Database Example

Let's say we are storing purchase information in a database and have a
field for quatity and item and total. So, we create a database table as follows:

PK Purchase_ID
ItemPrice
ItemQuantity
TotalPrice

Since TotalPrice is actually calculated by multiplying ItemPrice by the ItemQuantity
we should instead have a table that looks like the following:

PK Purchase_ID
ItemPrice
ItemQuantity
TotalPrice

The total price can be calculated once the data is retrieved. This allows us not
to duplicate values in the database table.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T02:10:51Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing Java code to generate documentation for its code. If the documentation was written independently of the code then changes to the code would very likely require changes in the documentation. With JavaDoc, since the documentation is generated from the source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

Database Example

Let's say we are storing purchase information in a database and have a
field for quatity and item and total. So, we create a database table as follows:

PK Purchase_ID
Item_ID

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T02:10:35Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing Java code to generate documentation for its code. If the documentation was written independently of the code then changes to the code would very likely require changes in the documentation. With JavaDoc, since the documentation is generated from the source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

Database Example

Let's say we are storing purchase information in a database and have a
field for quatity and item and total. So, we create a database table as follows:

PK Purchase_ID
Item_ID

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T02:10:16Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing Java code to generate documentation for its code. If the documentation was written independently of the code then changes to the code would very likely require changes in the documentation. With JavaDoc, since the documentation is generated from the source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

Database Example

Let's say we are storing purchase information in a database and have a
field for quatity and item and total. So, we create a database table as follows:

PK Purchase_ID
Item_ID

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T02:09:03Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing Java code to generate documentation for its code. If the documentation was written independently of the code then changes to the code would very likely require changes in the documentation. With JavaDoc, since the documentation is generated from the source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

Database Example

Let's say we are storing purchase information in a database and have a 
field for quatity and item and total.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T01:25:44Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing Java code to generate documentation for its code. If the documentation was written independently of the code then changes to the code would very likely require changes in the documentation. With JavaDoc, since the documentation is generated from the source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T01:25:35Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing Java code to generate documentation for its code. If the documentation was written independently of the code then changes to the code would very likely require changes in the documentation. With JavaDoc, since the documentation is generated from the source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T01:23:32Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code 
generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing 
Java code to generate documentation for its code. If the documentation was written 
independently of the code then changes to the code would very likely require changes 
in the documentation. With JavaDoc, since the documentation is generated from the 
source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T01:22:40Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing Java code to generate documentation for its code. If the documentation was written independently of the code then changes to the code would very likely require changes in the documentation. With JavaDoc, since the documentation is generated from the source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T01:21:57Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing Java code to generate documentation for its code. If the documentation was written independently of the code then changes to the code would very likely require changes in the documentation. With JavaDoc, since the documentation is generated from the source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-26T01:03:48Z

Cadedam: /* Examples of the DRY Principle */

= DRY Principle =
The [http://en.wikipedia.org/wiki/DRY_code Don't Repeat Yourself (DRY)] principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

= What is the DRY Principle? =
The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

= The Importance of the DRY Principle? =
DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

= Examples of the DRY Principle =

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows:

class line {
public:
Point start;
Point end;
double length;
};

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points.

class line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.

Another example

One of the most common ways to implement the DRY principal is with the use of code generators. Although it is technically not generating usable code, [http://www.codegeneration.net/tiki-index.php?page=JavaDoc JavaDoc] uses the existing Java code to generate documentation for its code. If the documentation was written independently of the code then changes to the code would very likely require changes in the documentation. With JavaDoc, since the documentation is generated from the source code, the documentation will still be relevant after maintenance is performed on the code. Using code generators like JavaDoc helps to allow a single authority on a piece of knowledge within in the code to be maintained. The programmer changes the code and the change is properly documented as a result.

= Programmer Checklist for the DRY Principle =
•If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source? 
•If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation? 
•If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and
interface declarations from the code? 
•If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 
•If you have reused a section of code, a change will require finding all the sections
that involved reuse. Missing some of the changes will often cause very subtle errors.

= DRY Principle - Always Good? =
Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where [http://www.artima.com/intv/dry3.html "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."]

= Conclusion =
As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

= External Links/References =

* http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
* http://www.catb.org/esr/writings/taoup/html/ch04s02.html
* http://www.artima.com/intv/dry3.html
* http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
* http://en.wikipedia.org/wiki/Don't_repeat_yourself
* http://en.wikipedia.org/wiki/DRY_code

[1]Hunt, Andy and Thomas, Dave
Keep It DRY, SHY, and Tell the Other Guy,
IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004
PMID: 9917440; UI: 99117608.

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-25T04:23:02Z

Cadedam: /* What is the DRY Principle? */

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-25T04:14:48Z

Cadedam: /* Programmer Checklist for the DRY Principle? */

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-25T04:14:33Z

Cadedam: /* External Links */

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-25T04:04:10Z

Cadedam: /* External Links */

CSC/ECE 517 Summer 2008/wiki2 5 31

2008-06-25T03:48:21Z

Cadedam: /* Examples of the DRY Principle? */