From: John Joyce <dangerwillrobinsondanger@...>
Date: 2007-10-13T05:01:34+09:00
Subject: Re: I don't like my code -- what can I do?


On Oct 12, 2007, at 2:41 PM, Daniel Waite wrote:

> John Joyce wrote:
>> design problem.
>
> That's what I thought. The specs are being written by someone who is
> fluent in Java (I believe) and he puts a heavy emphasis on SQL.  
> Granted,
> he's forgiven to a great extent as the program we are porting isn't of
> his own design. He's said before he feels it's a poor design, too. But
> still... SQL everywhere (not in the views though... thankfully)!
>
>> You're trying to do too much with one model. (that's more like C
>> structs) You need more models that can interact with each other.
>> (more like Ruby objects) You may need to break it down further...
>
> I definitely agree with the too much responsibility for one model.  
> It's
> perverted and I feel dirty.
>
>> But just make your little sketches on paper.
>> There are a few perspectives you could take here, but start with the
>> most basic items You may need to alter the naming. Sometimes it can
>> be confusing. is a bid the price offered by a vendor? or is a bid
>> the whole response from the vendor?
>>
>> One thing to be wary of are words that are verbs and nouns.
>> objects tend to be nouns and methods tend to be verbs or predicates.
>
> Yes, yes, yes! You read my mind! (I'm almost welling up!) I've said  
> this
> for a long time! Words are sometimes the most difficult part of
> programming! Words MEAN something. And programming isn't politics, so
> meaning should be preserved as much as possible -- what do I call the
> adapter part of a polymorphic association to an appointment?
> "Schedulable" isn't a word, so it doesn't make sense to say that (one
> example I recently came across -- I settled on available).
>
> Thanks John, you've made my day. Whew... time to get back to work!
> -- 
> Posted via http://www.ruby-forum.com/.
>
No problem, I struggle with this stuff myself, and I just do it for a  
hobby.
I don't think it's java getting in his way.
Nor is it SQL
It's just a matter of getting the the right data relationships.
SQL isn't inherently bad just how it's used can be bad.
You just need to create objects and let SQL do the storage and  
retrieval and use it to get some of the freebies you get from it,  
like cheap fast indexing and datamining, but those things should come  
after the fundamental design.
Your situation is simple and should be pretty easy to develop if the  
models are right.