<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE document PUBLIC "-//CNX//DTD CNXML 0.5 plus MathML//EN" "http://cnx.rice.edu/cnxml/0.5/DTD/cnxml_mathml.dtd">
<document xmlns="http://cnx.rice.edu/cnxml" xmlns:md="http://cnx.rice.edu/mdml/0.4" xmlns:m="http://www.w3.org/1998/Math/MathML" xmlns:bib="http://bibtexml.sf.net/" id="id16823932">
  <name>List Structure and the Composite Design Pattern</name>
  <metadata>
  <md:version>1.1</md:version>
  <md:created>2007/07/09 14:27:23.086 GMT-5</md:created>
  <md:revised>2007/09/18 10:49:21.206 GMT-5</md:revised>
  <md:authorlist>
      <md:author id="swong">
      <md:firstname>Stephen</md:firstname>
      
      <md:surname>Wong</md:surname>
      <md:email>swong@rice.edu</md:email>
    </md:author>
      <md:author id="dxnguyen">
      <md:firstname>Dung</md:firstname>
      <md:othername>X.</md:othername>
      <md:surname>Nguyen</md:surname>
      <md:email>dxnguyen@rice.edu</md:email>
    </md:author>
  </md:authorlist>

  <md:maintainerlist>
    <md:maintainer id="swong">
      <md:firstname>Stephen</md:firstname>
      
      <md:surname>Wong</md:surname>
      <md:email>swong@rice.edu</md:email>
    </md:maintainer>
    <md:maintainer id="dxnguyen">
      <md:firstname>Dung</md:firstname>
      <md:othername>X.</md:othername>
      <md:surname>Nguyen</md:surname>
      <md:email>dxnguyen@rice.edu</md:email>
    </md:maintainer>
  </md:maintainerlist>
  
  <md:keywordlist>
    <md:keyword>composite</md:keyword>
    <md:keyword>design</md:keyword>
    <md:keyword>list</md:keyword>
    <md:keyword>OOP</md:keyword>
    <md:keyword>pattern</md:keyword>
  </md:keywordlist>

  <md:abstract>In programming, it is often necessary to have objects with which one can store data, retrieve data when needed, and remove data when no longer needed.  Such objects are instances of what we call container classes.  There are basically two schemes for organizing the objects for storage: a linear scheme and a non-linear scheme.  This leads to the notion of container structures.  The linear container structure is called a list.  The non-linear structure can be sub-classified into many sub-types such as the various tree structures and hash tables, which we will study in subsequent modules.

This module focuses on the defining the list structure and designing its implementation.</md:abstract>
</metadata>
  <content>
    <section id="id-170845158601">
      <name>Going Shopping</name>
      <para id="id16682838">Before I go to the groceries store, I make a list of what I want to buy.  Note how I build my shopping list: I start with a blank sheet of paper then I add one item at a time.</para>
      <para id="id18345524">When I get to the store, I start buying things by going down my list.  For each item I buy, I mark it off the list.</para>
      <para id="id14423454">After I am done shopping, I go to the cashier and check out my items.</para>
      <para id="id16164515">The cashier scans my items one item at a time.  Each time, the cash register prints one line showing the item just scanned together with its price.  Again, note how the cash register builds the list: it start with a blank sheet of paper and then add one item at a time.  After all items have been scanned, the cashier press a key and "poof", the cash register prints a subtotal, then a tax amount for all the taxable items, then a total amount, and finally a total number of items bought.</para>
      <para id="id18198677">At different store, the cash register not only prints out all of the above, but also a total amount of "savings" due to the fact that I have a "member-plus" card.  Some other stores don't care to print the total number of items bought at all.  Whatever the store, wherever I go, I see "lists" and "list processing" all over.</para>
      <para id="id18198680">The check out cash register uses a program to enter the items and print the receipt.  At the heart of the program is a container structure to hold data (data structure) and a few algorithms to manipulate the structure and the data it holds.  The simplest way to organize data is to structure them in a linear fashion; that is, intuitively, if we can get hold of one data element, then there is exactly one way to get to the next element, if any.  We call this linear organization of data the list structure.  In order to write program to process lists, it is necessary to define what lists are and express their definitions in terms of code. </para>
    </section>
    <section id="id-17266725457">
      <name>What is a list?</name>
      <para id="id12028967">Analogous to the notion of a shape, a list is an abstract notion.  Recall how I built my list of groceries items?  I started with a blank list: an empty list!  The empty set!  </para>
      <para id="id16270484">
        <quote type="block">
          <emphasis>An empty list is a list that has no element.</emphasis>
        </quote>
      </para>
      <para id="id17485076">It is obvious that there are non-empty lists.  But what do we mean by a non-empty list?  How can we articulate such an obvious notion?  Consider for example the following list consisting of three elements.</para>
      <list type="bulleted" id="id6218347">
        <item>milk </item>
        <item>bread </item>
        <item>butter </item>
      </list>
      <para id="id16970805">In the above, we organize the items in a linear fashion with milk being the first element, bread being the next element following milk and butter being the next element following bread.  Is there any item that follows butter?</para>
      <para id="id16970809">Is</para>
      <list type="bulleted" id="id17074031">
        <item>bread </item>
        <item>butter </item>
      </list>
      <para id="id17137416">a list?</para>
      <para id="id16579013">Is</para>
      <list type="bulleted" id="id16579017">
        <item>butter </item>
      </list>
      <para id="id16753382">a list?</para>
      <para id="id14519058">Is there a list that follows butter in the above?</para>
      <para id="id10600704">
        <quote type="block">
          <emphasis>A non-empty list is a list that has an element called first and a list called rest.</emphasis>
        </quote>
      </para>
      <para id="id12363522">
        Note that in the above formulation, the rest of a list is itself a list!  The definition of a list is an example of what we call a <term>recursive</term> definition: the list contains a substructure that is <term>isomorphic</term> to itself.
      </para>
    </section>
    <section id="id-0701430545559">
      <name>List Design and the Composite Design Pattern</name>
      <para id="id16320004">The UML diagram below captures the recursive data definition of the list data structure.</para>
      <figure id="id15710190"><name>UML diagram of a list</name>
	<media type="image/png" src="graphics1.png">
	</media>
<caption>A list can be represented using the composite design pattern</caption></figure>
      <para id="id16073744">This definition translates into Java code as follows.</para>
      <table id="id14569520"><tgroup cols="2" colsep="1">
		<colspec colnum="1" colname="c1"/>
		<colspec colnum="2" colname="c2"/>
		<tbody>
			<row>
				<entry namest="c1" nameend="c2">
					<code type="block">
/**
* Represents the abstract list structure.
*/
public interface IList {
}
                </code>
				</entry>
			</row>
			<row>
				<entry>
					<code type="block">
/**
* Represents empty lists.
*/
public class MTList implements IList {
}
                </code>
				</entry>
				<entry>
					<code type="block">
/**
* Represents non-empty lists.
*/
public class NEList implements IList {
    private Object _first;
    private IList _rest;
}
                </code>
				</entry>
			</row>
		</tbody>
	</tgroup>
</table>
      <para id="id13936757">
        The above is an example of what is called the <term>composite design pattern</term>.  The composite pattern is a <emphasis>structural</emphasis> pattern that prescribes how to build a container object that is composed of other objects whose structures are <term>isomorphic</term> to that of the container itself.  In this pattern, the container is called a composite. In the above, IList is called the abstract component, MTList is called the basic component and NEList is called the composite.  The composite design pattern embodies the concept of <term>recursion</term>, one of the most powerful thinking tool in computing.  (There is a subject in theoretical computer science and mathematics called "recursive function theory," which studies the meaning of what computing means and in effect defines in the most abstract form what a computer is and what it can and cannot do.)
      </para>
    </section>
    <section id="id-903965977094">
      <name>List Creation</name>
      <para id="id17217097">
        Now that we have defined what a list is, we ask ourselves how we can process it?  What can we do with a list?  The above code makes it clear that there is not a whole lot we can do with a list besides instantiating a bunch of MTList objects via the call new MTList() (why?).  Now that we are using the full Java language, we need to write a constructor for NEList in order to instantiate non-empty list objects with appropriate first and rest.  The Java code for NEList now looks as follows (note how the comments are written).
      </para>
      <code type="block">
  /**
  * Represents non-empty lists.
  */
  public class NEList implements IList {
     private Object _first;
     private IList _rest;

     /**
     * Initializes this NEList to a given first and a given rest.
     * @param f the first element of this NEList.
     * @param r the rest of this NEList.
     */
     public NEList(Object f, IList r) {
        _first = f;
        _rest = r;
     }
  }
      </code>
      <para id="id16841414">
        The list structure as coded in the above is completely <term>encapsulated</term>, that is, all internal components (if any) of a list are private and cannot be accessed by any external code.  Using the appropriate constructors, we can make a bunch of lists to store data but we cannot retrieve data nor do anything with these lists.  In Object-Oriented Programming (OOP) parlance, the list is said to have no behavior at all.  As such they are of no use to us.
      </para>
    </section>
    <section id="id-224064491897">
      <name>List Processing</name>
      <para id="id14983211">In order to perform any meaningful list processing at all, we need to program more "intelligence" into the list structure by adding appropriate methods to the list to provide the desired behaviors.  So instead of asking what we can do with a list, the right question to ask in OOP is "what can a list do for us?"  Let us start by presenting a few simple tasks that we want a list to perform and try to figure out how an "intelligent" list would carry out such tasks via some role acting.</para>
      <section id="id-808479611647">
        <name>In class role-acting exercises:</name>
        <list type="bulleted" id="id3214613">
          <item>Compute the length of a list. </item>
          <item>Compute the sum of a list that holds integers. </item>
        </list>
      </section>
    </section>
  </content>
</document>
