[MO-java-dev] CVS: no-stone-unturned/doc/xdocs glossary.xml,1.3,1.4 introduction.xml,1.3,1.4 how_mocks_happened.xml,1.10,1.11 notes.xml,1.2,1.3 htmlbook.css,1.10,1.11

[Steve F. <sm...@us...>]

Update of /cvsroot/mockobjects/no-stone-unturned/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv6760/doc/xdocs

Modified Files:
	glossary.xml introduction.xml how_mocks_happened.xml notes.xml 
	htmlbook.css 
Log Message:
mroe on how_mocks_happened

Index: glossary.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/glossary.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- glossary.xml	18 Aug 2002 23:15:29 -0000	1.3
+++ glossary.xml	20 Aug 2002 16:56:57 -0000	1.4
@@ -23,7 +23,25 @@
     <glossentry id="refactoring">
       <glossterm>Refactoring</glossterm>
     </glossentry>
+
+    <glossentry id="rup">
+      <glossterm>RUP</glossterm>
+    </glossentry>
+
   </glossdiv> <!-- R -->
+
+  <glossdiv>
+    <title>S</title>
+
+    <glossentry id="sdd">
+      <glossterm>Spaghetti-Driven Development</glossterm>
+      <glossdef><para>
+        An Stream Of Consciousness approach to programming influenced by the novels of Woolf, Proust and,
+        occasionally, Burroughs. The style fell out of favour during the 1980's but has since enjoyed something
+        of a renaissance in the field of Web Scripting.
+      </para></glossdef>
+    </glossentry>
+  </glossdiv> <!-- S -->
 
   <glossdiv>
     <title>T</title>

Index: introduction.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/introduction.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- introduction.xml	12 Aug 2002 23:10:20 -0000	1.3
+++ introduction.xml	20 Aug 2002 16:56:58 -0000	1.4
@@ -68,9 +68,10 @@
       </para>
 
       <para>
-        Model-Driven Development is about deferred gratification: I won't write code until I think I have a good
-        model of the structure of the problem (or the deadline is too close). &TDD; is a different kind of
-        deferral: I won't spend too much time thinking about the large-scale structure of the problem until I think
+        Model-Driven Development, such as <glossterm linkend="rup">RUP</glossterm>, is about deferred gratification:
+        I won't start writing code until I think I have a good enough model of the structure of the problem
+        (or the deadline is too close). &TDD; is a different kind of deferral: I won't spend too much time
+        thinking about the large-scale structure of the problem until I think
         I've learned enough from writing and refactoring the code. When the time comes, the code will tell me how
         it should be structured and I'll trust myself to see it. Some developers are uncomfortable with this
         trade-off because it violates everything we've been taught about Good Practice since our first algorithms

Index: how_mocks_happened.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/how_mocks_happened.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- how_mocks_happened.xml	18 Aug 2002 23:15:29 -0000	1.10
+++ how_mocks_happened.xml	20 Aug 2002 16:56:58 -0000	1.11
@@ -94,12 +94,12 @@
   assertEquals("Should be same move", new MoveRequest(1, MoveRequest.SOUTH), moves.get(1));
 }</programlisting>
 
-    <sidebar>
+    <note>
       <para>
         You may have noticed that we haven't said anything about the layout of the warehouse. We'll
         assume for now that the Robot knows about it by some other mechanism.
       </para>
-    </sidebar>
+    </note>
 
     <para>
       This test specifies a simple routing scheme, for moves to adjacent squares, and that we're
@@ -247,14 +247,14 @@
   assertEquals("Should be same", POSITION, robot.getCurrentPosition());
 }</programlisting>
 
-    <sidebar>
+    <note>
       <para>
         I'm being inconsistent again by keeping <function>getCurrentPosition()</function>. In my defence,
         it seems more reasonable to me that a robot should know its current position than that it should
         keep a list of its recent movements. One day I'll replace this with a
         <classname>CurrentPositionListener</classname>, or some such technique. Really I will.
       </para>
-    </sidebar>
+    </note>
 
     <para>
       This version of the test still describes the same core specification as before (the
@@ -705,14 +705,59 @@
     <title>What about design?</title>
 
     <para>
-      &TDD; is about really about design, it's a way of specifying behaviour and the relationships between objects
-      in a system. What influence does Mock Objects as a technique have on the development of a system? Some of you
-      may recognise it as a reincarnation of that ancient discipline
-      <glossterm linkend="topdowndecomposition"><quote>Top-Down Decomposition</quote></glossterm>, also known as
-      <quote>Structured Programming</quote>. The idea is to start from the top-most level of the program, stub out
-      the bits that have not yet been implemented, and work your way down.
+      &TDD; is about design, it's a way of specifying behaviour and the relationships between objects
+      in a system. What influence does using Mock Objects have on the eventual structure of a system?
+      Let's start by asking where the significant <quote>design moments</quote> are when
+      developing this way.
+    </para>
+    <para>
+      As we begin a new test, the first question we ask is, <quote>Who would know?</quote>
+      &mdash; if we were to implement this functionality, which objects would it affect? The answer
+      will tell us which objects need to interact with the code under test, and the
+      the relationships between them. For example, we decided that we needed a <quote>route following
+      object</quote>, called a <quote>Motor</quote>, so that we could tell whether the route
+      had been properly constructed; we invented a construct in the software to represent something
+      in the physical world. This is what Object-Oriented Design is about, and we have a way to
+      drive that decision from an immediate requirement in a test. A motor is a straightforward
+      concept, in later examples I'll show how we can be more sophisticated and invent objects to
+      represent computatational concepts such as callbacks and listeners.
+    </para>
+    <para>
+      The next decision was how to make the motor object available to the robot object so that it
+      can move. We could have passed the <classname>Motor</classname> through to the
+      <function>goTo()</function> method, but instead we decided to make the <classname>Motor</classname>
+      part of the <classname>Robot</classname> and pass it through in the constructor. That's another
+      design decision and, again, we drove it from the process of writing a test.
+    </para>
+    <para>
+      We want to unit test but don't want to expose more of the internals of the object than is necessary,
+      because that makes the class, and the code that uses it, that little bit harder to change. Across a
+      whole code base, the increased <quote>refactoring drag</quote> can be significant. Our solution
+      (<quote>Tell, don't ask</quote>) forces us into passing around computation rather than data: we
+      pass a <quote>route listening object</quote> (a <classname>Motor</classname>) to
+      the <classname>Robot</classname>, rather than returning a collection of <classname>MoveRequest</classname>.
     </para>
-  </section>
+
+    <sidebar>
+      <para>
+        Some of you may recognise the similarities between &TDD; and the ancient discipline of
+        <glossterm linkend="topdowndecomposition"><quote>Top-Down Decomposition</quote></glossterm>, also known as
+        <quote>Structured Programming</quote>. The idea is to start from the top-most level of the program, stub out
+        the bits that have not yet been implemented, and work your way down; repeat until you have a complete
+        application. In the days when many programmers found procedures and nested scope exotic,
+        Top-Down Decomposition was a useful technique for avoiding
+        <glossterm linkend="sdd">Spaghetti-Driven Development</glossterm>.
+      </para>
+      <para>
+        Top-Down Decomposition had two powerful insights: to keep each level focussed and consistent,
+        and to drive the design of interfaces from their use rather than their implementation. It also had
+        a couple of critical failings, because it turned out to be hard to change early design
+        decisions which, of course, are embedded in the top-level structure, and it's not good at
+        encouraging reuse between lower-level components. It looks like &TDD; avoids those failures because
+        of its emphasis on refactoring and because objects give us better modularity than procedures.
+      </para>
+    </sidebar>
+  </section> <!-- What about design? -->
 
   <!-- TODO --> <comment>Under development</comment>
 
@@ -785,7 +830,6 @@
     <title>Notes</title>
     <!-- TODO -->
     <para>Top-down decomposition</para>
-    <para>Design is the choice of object to test</para>
   </section>
 
   <section>

Index: notes.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/notes.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- notes.xml	18 Aug 2002 22:44:39 -0000	1.2
+++ notes.xml	20 Aug 2002 16:56:58 -0000	1.3
@@ -4,5 +4,6 @@
     <listitem><para>Tests in Ant</para></listitem>
     <listitem><para><emphasis>DocBook</emphasis>Fix keysym, guibutton, co</para></listitem>
     <listitem><para>Needs pictures, UML</para></listitem>
+    <listitem><para><quote>The problem with Oakland, California is that there's no there there</quote> G. Stein</para></listitem>
   </itemizedlist>
 </part>

Index: htmlbook.css
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/htmlbook.css,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- htmlbook.css	18 Aug 2002 22:44:39 -0000	1.10
+++ htmlbook.css	20 Aug 2002 16:56:58 -0000	1.11
@@ -7,13 +7,16 @@
 DIV.section H2 { font-style: italic; font-weight: normal; }
 DIV.section H3 { font-style: normal; font-size: small; }
 DIV.tip     H3 { font-style: italic; font-weight: normal; font-size: small; }
+DIV.tip     P  { font-size: 80%; }
+DIV.note    TH { font-size: 80%; }
+DIV.note    P  { font-size: 80%; }
 PRE         SPAN.emphasis { font-weight: bold; }
 
 .programlisting { margin-left: 5%;  }
 .screen { margin-left: 5%;  }
-.sidebar { border: double black 1px; font-size: 80%; padding: 4px; text-align: center; margin-left: 70%; }
-.tip { border: double black 1px; font-size: 80%; }
-.note { border: double black 1px; font-size: 80%; }
+.sidebar { border: double grey 5px; font-size: 80%; padding: 2%; margin-left: 10%; margin-right: 10%; }
+.tip { border: double black 1px; }
+.note { border: double black 1px;}
 .screenshot { margin-left: 20%; }
 .caption { font-size: 80%; font-style: italic; }
 .guibutton { font-weight: bold; }