Design Principles:Don't Repeat Yourself (DRY) - A guide to its implementation

"DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.

Given all this knowledge, why should you find one way to represent each feature? The obvious answer is, if you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. DRY is important if you want flexible and maintainable software." From: Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II (emphasis mine).

How does this apply to code? Read the article here.

Design Principles: Program to interfaces, not implementations - A guide to its implementation

One of the recommended principle of OO design/programming is to ‘program to interfaces, not implementations’.

Consider a password policy defined like this in XML: 

<policy>
 <password>
  <min-length>
   <administrator>18</administrator>
   <end-user>8</end-user>
  </min-length>
  <expires duration="days">
   <administrator>60</administrator>
   <end-user>30</end-user>
  </expires>
 </password>
</policy>

In design, this will look like:

The abstract Policy class exposes 2 abstract methods, which are implemented in its sub-classes. The AdministratorPolicy class implement these methods to return values appropriate to the administrator from the XML file; the EndUserPolicy class implement these methods to return values appropriate to the end user.

And in code we can write:
Policy policy = new AdministratorPolicy();
int pwdMinLength = policy.GetPasswordMinLength();  //returns 18
int pwdExpiresInDays = policy.GetPasswordExpiresInDays();  //returns 60

Or:
Administrator policy = new AdministratorPolicy();
int pwdMinLength = policy.GetPasswordMinLength();  //returns 18
int pwdExpiresInDays = policy.GetPasswordExpiresInDays();  //returns 60

We are programming to an interface when we code Policy policy = new AdministratorPolicy(), because the Policy is an abstract class. We are programming to an implementation when we code Administrator policy = new AdministratorPolicy(), because AdministratorPolicy is an implemented or concrete class.

Notice that no matter how we instantiate it, the policy object is the same, exposing the same methods. This is because the super class and its sub-classes exhibit behavioral equivalence. To implement the design principle ‘program to interfaces, not implementations’ we need to ensure that the super class and its sub-classes are equivalent.

However, this is not always easy because:
1. Behavior in the derived/implemented class may vary.
2. Data in the derived/implemented class may vary.

How do we achieve behavioral equivalence under these circumstances? Read the full article here.