georgesawyer
1/8/2005 10:52:00 PM
darren <rubylang@usmstudent.com> Jan 7, 2005 at 11:44 AM wrote:
>I can't decide how much detail to provide for this question
>... how to approach translating a procedurally structured
>program written in C by my class last semester into a
>properly structured Ruby program...as an exercise to learn
>Ruby and better understand [this particular "program"].
>I'm getting confused on how to think this procedural
>solution in object oriented terms.
>I don't even think I'm going to get bogged down in the Ruby
>code (although I'm sure I'll have plenty of unexpected
>qestions). I'm suspecting the Ruby code is going to be less
>trouble than just getting the overall idea of how to
>visualize laying it all out.
Let me strongly urge you to use Divide and Conquer. Also,
Refactor, Refactor, Refactor.
D&C: Look for the natural divisions in any problem. This one
at least divides into:
1. Translate into completely procedural Ruby code similar
to C. Strongly resist the urge to make Ruby-like changes;
keep that as minimal as possible and have it still work.
2. Change the working Ruby program's structure to proper Ruby
structure.
Doing otherwise, anybody would be confused.
After doing step 1 and first testing the input file so
that it is completely done and working successfully,
you can relax about step 1. Take a break to empty your
mind, and wait until you feel ready to work on it again.
RRR: Now comes step 2, above. Continuously alternate between
running the full test, and changing the easiest and smallest
thing you can find in the Ruby code that still removes
some of its non-Ruby nature. Apply at this time your knowledge
of object orientation. Come back to it until the returns
diminish or you feel like stopping.
>So far, in Ruby, I am opening the [input] and echoing it back
>out to screen. Now, I want to parse [it], checking that [it]
>matches the ... rules .... Even though I don't have all of the
>regular expressions written, generally, I think I can handle
>the regex part.
>The first procedure that executes in main[: i]t's kinda easy
>to see what's going on.... We're just checking for valid ...
>if we get one, we move on, if not, we call .... The process
>is pretty much that way all the way through. And, I don't
>think it is all that important for this question.
Since you ask: As I remember, these thoughts are natural
and inevitable, relatively early while learning programming:
how does the computer do this, or how can it do that. There
are many useful ways to think about software.
You can find in a book how to think about it in an
object-orientated way. Hm, which book. Well, don't do it
yet! First do step 1.