Re: OT : Coding Standards (was New WebObjects 15 Minute Tutorial in Quicktime)
Re: OT : Coding Standards (was New WebObjects 15 Minute Tutorial in Quicktime)
- Subject: Re: OT : Coding Standards (was New WebObjects 15 Minute Tutorial in Quicktime)
- From: Arturo Pérez <email@hidden>
- Date: Mon, 29 Mar 2004 20:28:36 -0500
On Mar 28, 2004, at 11:08 PM, Owen McKerrow wrote:
Hi Arturo,
Let me see if I understand, Im one of those naive WO programers :)
Speaking of which, how does one become un-naive ? Besides asking
questions. Not trying to be smart aleck here, just wondering how you
figure this out ?
Well, a lot of it I attribute to Malcolm Crawford. He trained me and
my team. He does a good job of smackin' you upside when you're being
dumb :-) All kidding aside, he accelerated the course and taught us
very well indeed.
Secondarily, I was working with a team of almost 15 developers. They
all came to me with issues so I felt compelled to come up with answers.
Study, study, study. The books, omnigroup, everything.
Finally, I'm a "natural" developer anyway. So I have an intuitive feel
for what the WO creators are trying to achieve.
All the Apple examples and most of the books I have read have you
making the Java Classes. Is it just a matter of experience ? Some
secret documentation or walkthrough found in some far corner of the
net ? Or is this the benefit of looking over a "pro's shoulder" as
Jonathan put tit.
We used to all do it, too. I forget exactly what made us stop. I
think the endless FileMerges got to be annoying.
The next level (mine I'm no expert) is to only create those classes
that have truly undeniable business logic. In this situation, I use
a lot of the EOUtilities routines for dealing with entities with no
specific class and I use takeValueForKey for everything. In fact, I
even rip out the casting that WOBuilding puts in for WOComponents and
I just use takeValueForKey for those, too. It makes the code more
uniform at the added (slight) risk of runtime errors. The trick of
takeValueForkey works because it will call setKey if you have one.
So you don't use setObject(Object new Object) but
takeValueForKey(object, "object"). Is there an advantage to doing it
this way besides making it all more uniform ? And by uniform do you
mean uniform in how the code looks ?
Uniform in behavior, style and structure. Uniformity in behavior makes
things all act more or less the same. Then when something doesn't act
like everything else it must be broken in some way. Uniformity in
style makes "incorrect" code stand out. If it doesn't look like
everything else something must be wrong. Finally, uniformity in
structure means that the same design patterns are used over and over.
Mostly because they work. If it ain't broke...
But the reason I leave the entities as EOGenericRecords is because it
is easier to refactor. Once I have a good feel the the business
logic associated with a class then I generate the class and add the
logic. I think some people use the Gap design pattern (and
EOGenerator) to address this need but I haven't gotten there myself
yet.
Sorry could you pleas explain this further. Do you mean that you don't
create the Java until you feel you understand its class logic ? What
is the Gap design pattern ?
Sorry, meant the Generation Gap design pattern. I think you got a good
reference for that.
Since creating software tends to be an exercise in exploration I try to
keep my options open for as long as possible. In this case, committing
to a particular implementation for poorly understood classes/business
logic would lock me into a solution before I'm ready. For things that
are understood, I just go ahead and make the Java classes.
Here's an example. Telephone numbers. Is there any custom business
logic associated with those? Not particularly. So, I just went ahead
and made the Java class so I could have sufficiently robust validation
logic.
Now, take James Cicenia's Project class. What do I know about that?
Well, next to nothing. So, I leave that alone until the appropriate
business logic "manifests" itself during implementation. As it does, I
stash it somewhere convenient until I have enough logic that is also
stable enough to be worth the trouble of generation the class file. On
the other hand, the GenerationGap pattern addresses this need to be
flexible in a more comprehensive fashion but I haven't had the
need/inclination to move to it yet.
I guess in a sense I use the Java classes to lock down the business
logic. Once the code is there then I'm very reluctant to change it.
----
WO in philadelphia - wanna cheesesteak with that?
Please visit webobjects.meetup.com.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.