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:
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:
Or:
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.
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.
