DRY

11: DRY—Don’t Repeat Yourself Every piece of knowledge should have a single, unambiguous, authoritative representation within a system Duplication is evil! Why? –Things change –If you have the same thing in several places, when you change one, you have to change all the others –And you can’t always find them all!

What not to duplicate Data –If you represent the same data in two places (or in two ways), you have just taken on the job of keeping the two representations in agreement Code –If you code the same task in two places (or in two ways), you have just taken on the job of keeping the two code segments in agreement

How duplication arises Same information must be represented in many ways, or in several places Required by documentation standards Required by the language As a result of bad design Taking shortcuts Poor communication among team members

Multiple copies of data Sometimes the same information must be stored in two places (say, a client and a server) Sometimes you need the same information in two different programming languages Best solution: Have one authoritative repository, and generate all the needed copies from it –Remember, programs can create code

Example Suppose you must have a table of numbers in your program, and also in a document –Solution #1: Add code to your program to write out the table in a form you can use in the document –Solution #2: Same as #1, but hot link to the table from your document (if possible) –Solution #3: Write a program that takes the table from the document and produces code you can insert into your program –Solution #4: Keep the master table in a separate place, and generate both the program and the document

Documentation standards Comments should not repeat code –They should add higher-level information—what the code is doing, and why, but not how it does it If code requires explanation, it’s bad code—fix it! Your documentation should agree with your code –Untrustworthy comments are worse than none –This is much easier if your comments are high level –This is why javadoc is so wonderful—it’s always correct!

Language requirements Some languages, such as Ada, require you to duplicate information –Ada has: An interface part, where you provide all the function headers An implementation part, where you provide all the functions (with the same headers) –The advantage is that it forces you to hide the implementation from the users –The disadvantage is that you need the identical information in two places There’s not much you can do about this

Bad design A Truck has a capacity, a license number, and a driver A DeliveryRoute has a route, a Truck, and a driver One of our drivers calls in sick and we need to change drivers –Where do we change this information? –Solution: Refactor (redesign) the program!

Copy-paste programming Suppose, as you are coding, you find you need to do the same thing as you did somewhere else –So you take this shortcut: you copy and paste code Later you find you need to do almost the same thing again –So you copy the code, paste it in, and adjust it Later still, you find you need to change that code –Which copies are the same, and which almost the same? Never take a shortcut when you’re in a hurry!

How to avoid copy-paste Often the best solution is to write a method –Call the method whenever you want to perform the computation –There is nothing wrong with short methods If you want to do almost the same thing, parameterize (add parameters to) the method

Duplication for efficiency Suppose you have this class: class Point { double x, y;... } And you discover that some of your users want to have polar coordinates (ρ and θ) You can’t discard x and y, because the class is already in use So you end up with double x, y, rho, theta; Now what if a user changes, say, x ?

Meyer’s Uniform Access Principle Bertrand Meyer: “All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.” Translation into Java: 1.Make your variables private 2.Use getters and setters

Redoing the Point example, I Suppose you had started with: class Point { private double x, y; void setX(double x) { this.x = x; } void setY(double y) { this.y = y; } double getX() { return x; } double getY() { return y; } } Does this help solve the problem?

Redoing the Point example, II To add ρ and θ: –Do not add fields rho and theta ; instead, do double getRho() { return Math.sqrt(x*x + y*y); } double getTheta() { return Math.acos(x / rho); } void setRho(double rho) { x = rho * Math.cos(theta); y = rho * Math.sin(theta); } void setTheta(double theta) { x = rho * Math.cos(theta); y = rho * Math.sin(theta); } –Is there anything else that needs to be done? –Can you think of another way to do this?

Poor communication Different team members might implement the same functionality How do we avoid this? –Good communication! Exchange ideas with co-workers Read your co-workers code Let others read your code Have code walkthroughs –Have a clear design –Have a strong technical project leader –Have a clearly understood division of responsibilities

12: Make it easy to reuse Your co-workers won’t use your code unless: –They know about it –It’s easy to access –It’s easier to use your code than to write their own version of the same thing You won’t even reuse it yourself unless: –It’s easy to use –It’s general enough to support reuse

Summary DRY—Don’t repeat yourself! –This principle is so important that I’ve given almost an entire set of slides to it Make it easy to reuse

The End