1 Jun 2004 01:42
Re: refactoring nested ifs
Thomas Eyde <teyde <at> online.no>
2004-05-31 23:42:06 GMT
2004-05-31 23:42:06 GMT
If I understand this correctly, then you have two things: Navigation + Data
Transfer.
I think all controls should know where to save and retrieve the data they
need. Think of it as a database. An ArrayList or Hashtable with the proper
facade would do. Use a real database for permanent persistence.
Then you are left with the navigation. You could use the control names as
the navigation key. Then Default.aspx can use this key to load the next
control. Or you could, as already suggested use a kind of lookup.
It can be as simple as this:
Hashtable viewMappings = new Hashtable();
viewMappings.Add("FirstView.Next", "SecondView");
viewMappings.Add("SecondView.Commit", "ThirdView");
viewMappings.Add("SecondView.Cancel", "FirstView");
Thomas
----- Original Message -----
From: "tourne_dr" <tourne_dr <at> yahoo.co.uk>
> The code behind the default page identifies what control was last
> displayed and what the next control is going to be, and it handles
> the transfer or information between them, in a method called
> DoPageTransfer().
>
> DoPageTransfer() is a very "smelly" method that consists of a long
> sequence of nested if statements.
(Continue reading)
-----Original Message-----
From: Jay Bazuzi [mailto:jaybaz <at> microsoft.com]
Sent: Tuesday, 1 June 2004 2:59 AM
To: refactoring <at> yahoogroups.com
Subject: RE: [refactoring] refactoring nested ifs
Check out
Just a few small comments to clarify:
> > 1. Non-JUnit unit tests (I'd say: Write these immediately!)
[...]
>
> There are many kinds of tests in the world, and they are all perfectly
> legal as programmer tools. The above are certainly good ideas, yet not
> what
> I was looking for in Oliver's "another path" comment.
Just to make it clear:
* There are JUnit unit tests which are a proper subset of ...
* ... unit tests (with other tools) which are a proper subset of ...
* ... tests
My impression is that when discussing tests or unit tests in the context of
Java refactoring, many people in these days automatically limit these words
to the first item.
Refactoring, as commonly(??) understood or at least defined, requires *unit*
tests - they need, of course, not be JUnit unit tests (and cannot unless
Java is used); and they should not (must not?) be
system/integration/load/functional/what-have-you tests.
My list tried to give ideas for non-JUnit unit tests, just in case someone
thought that only JUnit tests make sense; or - on the other hand - that "any
test is a test for refactoring".
[Side note: One can discuss why and whether refactoring really requires
*unit tests*; or just "tests" in general. And also, what the "unit" in "unit
test" may legally be ... I have my ideas here, but this has certainly
discussed on TDD and unit tests groups endlessly ...].
>
> > 2. Adding (many, and non-trivial) assertions inside running code to
> ensure
> > behavior constancy over refactorings.
>
> Yes ... though I would think that anything that can be done with
> assertions
> can be done with tests,
First, the question is whether it really can be done with *unit* tests. This
is not clear. Extreme example: A huge monolithic main method that reads data
from a real-world share price web-service feed and computes, in some tricky
way, a small result which it writes into a database.
This (horrible) design *cannot* be unit-tested (before refactoring - but
unit tests would be necessary to be allowed to start refactoring! - a
chicken-egg problem), as it will read different data on each run.
However, sprinkling the main with assertions which are proven to be
side-effect-free (by construction) would allow refactoring to start.
[I accept that I might be nit-picking or even "lawyer-izing" here, in that
I'm talking about definitions of terms like "unit test" (at least something
which is not a functional test, load test, or some other sort of test),
"refactoring" (by definition something which requires a means to prove
behavior-consistency over its steps) - but I think this is useful to
understand what one is talking about.
Another, also acceptable way is to use all these terms loosely - any test
tests some unit (whatever it is), so every test is a unit test; every
modification which improves something can be called refactoring. But then
the original question about "another path [to ensure safe refactoring]" is
useless, as any path in "some sense" is a test ...].
Second, the question is whether anything that can be done with assertions
can be done *efficiently* with (any sort of) tests. In the extreme example
above, a much later (test) step might indeed discover errors in the stored
result; but it would certainly be better that errors are found earlier.
>
> [Nice list of safe assertion techniques elided for brevity and shortness.]
Thx.
>
> > 3. Fagan reviews
[...]
>
> > 4. Use formal proofs.
[...]
>
> I've never been in a situation where formal proofs were of more than
> academic interest, other than perhaps in a very small percentage of the
> code. Is that experience atypical?
I'd say it is typical. I just mentioned it because it *is* a possible way.
The only place where I was near a "formal proof" environment was the
development of railway signalling software in a neighboring team; and even
there, only a small portion of basic systems was handled like that -
detailled and very formalistic Fagan reviews where the standard QA method.
The "maintenance phase" (which was - then, in the times of hard waterfall
processes - the only part in the process which would change code; and hence
had some resemblance to today's refactoring) had to use these methods - and
I think they used reviews exclusively (i.e. even software which underwent
some proof in its first version was later QAed only by reviews).
Regards
H.M.Müller
--
+++ Jetzt WLAN-Router für alle DSL-Einsteiger und Wechsler +++
GMX DSL-Powertarife zudem 3 Monate gratis* 
RSS Feed