<< Chapter < Page Chapter >> Page >
We apply the Abstract Factory Design Pattern to abstract the manufacturing of the list structure and hide its implementation. Such abstract construction together with the abstract specification of the intrinisc structural behavior of the list and the abstract specification of extrinsic operations on the list constitute a minimal and complete abstract specification of what is called a list software component. It provides a framework for writing an open ended number of algorithms on list that are independent from any particular list implementation.

1. information hiding

Information hiding is a tried-and-true design principle that advocates hiding all implementation details of software components from the user in order to facilitate code maintenance.  It was first formulated by David L. Parnas (in 1971-1972) as follows.

  • One must provide the intended user with all the information needed to use the module correctly and nothing more .
    • translation to OOP: the user should not know anything about how an interface or abstract class is implemented.  For example, the user need not and should not know how IList is implemented in order to use it.  The user should only program to the abstract specification.
  • One must provide the implementor with all the information needed to complete the module and nothing more.
    • translation to OOP: the implementor of a class or an interface should not know anything about how it will be used.  For example, the implementor need not and should not know how, when, or where IList will be used.  The implementor should write the implementation code based solely on the abstract specification.

By adhering to the above, code written by both users and implementors will have a high degree of flexibility, extensibility, interoperability and interchangeability.

The list framework that we have developed so far has failed to hide MTList and NEList , which are concrete implementations of IList , the abstract specification of the list structure.  In many of the list algorithms that we have developed so far, we need to call on MTList.Singleton or the constructor of NEList to instantiate concrete IList objects.  The following is another such examples.

InsertInOrder.java
import listFW.*; /*** Inserts an Integer into an ordered host list, assuming the host list contains * only Integer objects.*/ public class InsertInOrder implements IListAlgo {public static final InsertInOrder Singleton = new InsertInOrder(); private InsertInOrder() {} /*** This is easy, don't you think? * @param inp inp[0]is an Integer to be inserted in order into host. */public Object emptyCase(MTList host, Object... inp) { return new NEList(inp[0], host); }/** * Delegate (to recur)!* @param inp inp[0] is an Integer to be inserted in order into host.*/ public Object nonEmptyCase(NEList host, Object... inp) {int n = (Integer)inp[0];int f = (Integer)host.getFirst(); return n<f ? new NEList(inp[0], host): new NEList(host.getFirst(), (IList)host.getRest().execute(this, inp[0])); }}

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Principles of object-oriented programming. OpenStax CNX. May 10, 2013 Download for free at http://legacy.cnx.org/content/col10213/1.37
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Principles of object-oriented programming' conversation and receive update notifications?

Ask