MoveShape - A new and simple demo example
48 views
Skip to first unread message
Trygve Reenskaug
Sep 10, 2012, 12:55:17 PM9/10/12
to DCI-object-evolution
Hi group,
Some time ago, there was a felt need for a new and simple demo example that could replace the old Bank Transfer. Here is a candidate. The example use case is taken from the PowerPoint slide editor. You can draw various shapes and join them with connectors. The use case is to move a shape, and observe that the connector ends stay anchored to the shape.The use case is without user interface, it only requires an implementation of the system operation.
I have written a demo program in Squeak for this use case. The context class is called BB8MoveShape, its roles are MovingShape, Connector, and Delta. I have posted the program code on FullOO.info. It also includes a PowerPoint presentation sketch. See http://fulloo.info/Examples/SqueakExamples.
I wrote the code and reviewed it carefully before running it. This was not a proper peer review, because I do not have a Squeak colleague available. After several rounds of reading and correcting, I felt the program was simple and eminently readable. I expected it to pass its test at the first execution. An interesting exercise in code reading, it hasn't been possible since 1969 when we did systematic peer review with with Fortran programs. (Very successful, we got it right the first time for 3 out of 4 subroutines). It is now possible again because we have clear a separation of concerns into Data classes and use case Contexts, each being readable and testable in isolation. I believe that code reading may be faster than the incremental coding favored by smalltalkers, and with a much more robust result. It's the lean way of working, no waste. ("The code is so simple that it is obviously correct.")
After the reading, I ran the test. Surprise! There were any number of blunders (aka bugs). Only one in the body of the program itself; it was a class library method that didn't do what I expected. I should have known, but had forgotten this part of the library and failed to check. There were many blunders in the test method; it consisted of far too many numbers floating around in the code . Even test methods should be readable! A reviewer worth his salt should have rejected the test code and demanded a rewrite. (I have done a rewrite and it worked first time, of course.)
Enjoy
--Trygve
Some time ago, there was a felt need for a new and simple demo example that could replace the old Bank Transfer. Here is a candidate. The example use case is taken from the PowerPoint slide editor. You can draw various shapes and join them with connectors. The use case is to move a shape, and observe that the connector ends stay anchored to the shape.The use case is without user interface, it only requires an implementation of the system operation.
I have written a demo program in Squeak for this use case. The context class is called BB8MoveShape, its roles are MovingShape, Connector, and Delta. I have posted the program code on FullOO.info. It also includes a PowerPoint presentation sketch. See http://fulloo.info/Examples/SqueakExamples.
I wrote the code and reviewed it carefully before running it. This was not a proper peer review, because I do not have a Squeak colleague available. After several rounds of reading and correcting, I felt the program was simple and eminently readable. I expected it to pass its test at the first execution. An interesting exercise in code reading, it hasn't been possible since 1969 when we did systematic peer review with with Fortran programs. (Very successful, we got it right the first time for 3 out of 4 subroutines). It is now possible again because we have clear a separation of concerns into Data classes and use case Contexts, each being readable and testable in isolation. I believe that code reading may be faster than the incremental coding favored by smalltalkers, and with a much more robust result. It's the lean way of working, no waste. ("The code is so simple that it is obviously correct.")
After the reading, I ran the test. Surprise! There were any number of blunders (aka bugs). Only one in the body of the program itself; it was a class library method that didn't do what I expected. I should have known, but had forgotten this part of the library and failed to check. There were many blunders in the test method; it consisted of far too many numbers floating around in the code . Even test methods should be readable! A reviewer worth his salt should have rejected the test code and demanded a rewrite. (I have done a rewrite and it worked first time, of course.)
Enjoy
--Trygve
Reply all
Reply to author
Forward
0 new messages