[MO-java-dev] CVS: no-stone-unturned/doc/xdocs how_mocks_happened.xml,1.15,1.16

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

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

Modified Files:
	how_mocks_happened.xml 
Log Message:
more

Index: how_mocks_happened.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/how_mocks_happened.xml,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- how_mocks_happened.xml	1 Sep 2002 00:30:11 -0000	1.15
+++ how_mocks_happened.xml	2 Sep 2002 20:13:29 -0000	1.16
@@ -744,6 +744,37 @@
       trying to place bets on the what we think we're going to need.
     </para>
     <para>
+      Speculating wildly, the next requirements might push us to extract a <classname>Navigator</classname>
+      object that works out the route, so that the <classname>Robot</classname> becomes just a frame that
+      holds together the objects that do the real work. This is how the process often works: we start with a
+      top-level object, fill in some implementation, and hollow it out as we understand more about what's
+      inside. We then do the same to the new objects we've created, and so on. We end up with a collection of
+      classes, each focussed on a particular task, that have well-defined interfaces to their collaborating
+      objects.
+    </para>
+    <sidebar>
+      <title>Top-Down Decomposition</title>
+      <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: it turned out to be hard to change early design
+        decisions because, of course, they're embedded in the top-level structure, and it's not good at
+        encouraging reuse between lower-level components. It looks like &TDD; avoids these problems because
+        object-orientation makes it easier to share components throughout the application and
+        the emphasis on refactoring means we can remove duplication as the codebase grows.
+      </para>
+    </sidebar>
+
+    <para>
       One more design issue is our unusually heavy use of the <quote>Tell, don't ask</quote> pattern.
       We prefer to pass behaviour into an object, rather than pulling values out, which is why we wrote
       a <quote>route following object</quote> rather than returning a collection of
@@ -774,34 +805,7 @@
       </para>
     </note>
 
-    <para>
-      Speculating wildly, the next requirements might push us to extract a <classname>Navigator</classname>
-      object that works out the route, and the <classname>Robot</classname> becomes just a frame that
-      holds together the objects that do the real work. This is how the process often works: we start with a
-      top level object, fill in some implementation, and hollow it out as we understand more about what's
-      inside. We then do the same to the new objects we've created, and so on.
-    </para>
-    <sidebar>
-      <title>Top-Down Decomposition</title>
-      <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: it turned out to be hard to change early design
-        decisions because, of course, they're embedded in the top-level structure, and it's not good at
-        encouraging reuse between lower-level components. It looks like &TDD; avoids these problems because
-        object-orientation makes it easier to share components throughout the application and
-        the emphasis on refactoring means we can remove duplication as the codebase grows.
-      </para>
-    </sidebar>
+
   </section> <!-- What about design? -->
 
   <!-- TODO --> <comment>Under development</comment>