DRY11: DRY—Don’t Repeat YourselfWhat not to duplicateHow duplication arisesMultiple copies of dataExampleDocumentation standardsLanguage requirementsBad designCopy-paste programmingHow to avoid copy-pasteDuplication for efficiencyMeyer’s Uniform Access PrincipleRedoing the Point example, IRedoing the Point example, IIPoor communication12: Make it easy to reuseSummaryThe EndDRY11: 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 agreementHow 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 membersMultiple 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 codeExample•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 documentDocumentation 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 thisBad 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 methodDuplication 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 private2. Use getters and settersRedoing 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 responsibilities12: 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 reuseSummary•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 reuseThe
View Full Document
Unlocking...