From: georgesawyer Date: 2005-01-09T07:56:28+09:00 Subject: Re: approach to solving a problem darren 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.