mvhub-dev team mailing list archive

[Dan MacNeil <dan@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



- -------- Original Message --------
Subject: Re: refactoring anti-fowler link
Date: Wed, 7 Apr 2010 11:34:56 -0400
From: Robert Lechner <bob@xxxxxxxxxxxxxxxxxx>
To: Dan MacNeil <dan@xxxxxxxxxx>
CC: mvhub-dev@xxxxxxxxxxxxxxxxxxx, bob <bob@xxxxxxxxxxxxxxxxxx>
References: <4BBC7020.4060301@xxxxxxxxxx>

Thanks for the link, Dan.  Very interesting;
so I contributed my own  comment below.
Bob Lechner
- ----------------------------------------
I found these comments most  interesting. From them  I infer that the
writers span a broad spectrum. As a software engineering academic,
with an earlier computer sysems and CAD background, I  like to build
code generators to implement my code whereever possible. My major
sources of inspiration were Bachman's daa models
and  Shlaer and Mellor's Object Life Cycle (state) models. By modeling
the problem more abstractly, the models provide a key to understanding
how to partition, view and test the code itself.

Subclasses split a function into subclass variants. Ideally, each
sub-method  is more cohesive than their aggregate and a fraction of
its size..This eliminates one case switch per level of subclassing,
which is amply  justified ONLY if you understand and follow  the class
model's partitioning of  the code base. Each unit test is simpler than
their aggregate over all subclasses.   To me, aggregation of different
classes into compositions of data is at least as (if not more)
significant than inheritance hierarchies as a key to understanding
code behavior.

With  subclassing (C++) or without it (C),  control flow internal to a
method or function is easier  to deal with and extend if state variables are
recognized. Branch-controlling variables whose values are
not set locally  influence behavior from places that may be far away
and separated in  time.. Iff you encounter them, it is far better IMHO
to create a state model of the control flow or dynamic behavior
within the function, and encode such control variables as part of the single
state variable n this model.

ANother advantage of class and state modeling is that the remaining code
fragments diminish to sctions within a single state, with little or no
control branching or looping within each action. Such simple 'methods'
do not require a complex programming language.
OMG's UML/MDA standard supports both data/class and state/behavior models.
Unfortunately it does not emphasize separation of control flow from
action method coding, which would reduce its dependence on the
'action' implementation
language.

This state model, like the class or data model, also becomes part of
the documentation. Without it you  cannot understand the program.
With it, the program becomes testable at a new level -
that of the state transitions. All or most control variable updates
are modeled as state changes. These are visible (and traceable)
at the transition diagram  level.  State transitions are easily recognized
as the cause of all or most control flow diversions even with intervening
time delays.  Although more complex, message passing among threads
can also be modeled at the state diagram level. This permits a smoother
transition to concurrent programming for newer computer architecture.

Caveat: to keep models small, a hierarchy of nestable state diagrams
must be supported by the tool you are using. Tools are particularly
important to keep
state models in synch with test code.  Ideally, both data and state
models will be maintained by a common version-control system.

Bob Lechner (www.cs.uml.edu/~lechner)

On Wed, Apr 7, 2010 at 7:44 AM, Dan MacNeil <dan@xxxxxxxxxx> wrote:
> 
> This guy doesn't like the Fowler refctoring book (which Renuka and I
> were looking at)
> 
> http://reprog.wordpress.com/2010/03/28/what-is-simplicity-in-programming/
> 
> The comments are interesting as well, particularly some thoughts on how
> problems requiring re-factoring in java go away when using  dynamic
> language like perl or python.
> 
> I'm inclined to get the book anyway as it is well regarded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAku8uNsACgkQLzI3mETyffz8ZACggO0IMN5KD26oTufJY3m/Dzbe
0bYAoJUBo67VaZ8azgwew5DY5YQtI8bx
=3e8b
-----END PGP SIGNATURE-----