× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: OO and Procedural Work Units (was switch string)
  • From: "Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Wed, 7 Mar 2001 13:56:38 -0600

I agree 100%.  Whenever someone asks me how they should do an ILE procedure
for a project, a lot of the time they walk away with 5 instead of 1 because
I too like to break them down to the smallest common denominator.

I guess my main struggle is getting existing relational databases and
systems and "converting" them over the OO.  They don't seem to fight just
right all the time.  So, either you end up redoing your DB structure or
sacrificing some of the strengths of OO to "force" it to work.  I admint I'm
still wet behind the ears but for me it seems if you were to follow all of
the OO rules the initial developement time seems like it would be much
greater.  This isn't bad at all.  But, do we have 2 years to do it?  That's
my point.

Brad

> -----Original Message-----
> From: Buck Calabro [mailto:buck.calabro@aptissoftware.com]
> Sent: Wednesday, March 07, 2001 1:44 PM
> To: JAVA400-L@midrange.com
> Subject: RE: OO and Procedural Work Units (was switch string)
> 
> 
> I have done real ILE work, and I think that you have the basic facts
> straight, but don't miss out on the fact that one's 
> procedures (functions,
> classes, whatever your favourite term) can and should be 
> cross-application.
> 
> I fight every day to get programmers to stop thinking about 
> "this program"
> or "this problem" but to expect that somebody else could use 
> the routine.
> Broaden one's outlook, so to speak.  It takes only a little 
> more time to
> make the function more generic and the payback can be huge.
> 
> Also, there's a giant benefit in the maintenance department 
> to write code as
> many small functions.  Debugging time is greatly reduced 
> because you can
> comprehend the function easily.  Because the I/O is handled 
> as parameters,
> you can be 100% certain that code changes won't break other 
> code.  That's a
> huge plus.
> 
> Having more objects in an application means that one needs a 
> good library so
> one can readily look them up, but this problem exists in monolithic
> procedural code as well.  "I know there's credit checking 
> code in AR005, so
> I'll just use SEU to copy it into this program I'm working 
> on..."  You know
> the drill.  Once one builds one's "library" of debugged 
> functions, all one
> need know is the function name and parameter list and Bob's 
> your uncle!
> 
> In ILE, to build a new application one includes all the 
> functions required,
> glues them together with some IF/ELSE logic and Wham!  The OO 
> philosophy
> appears to be different because one can extend an existing "function"
> without messing with the existing function's code.  That's 
> the leap I'm
> struggling with right now.
> 
> Buck 
> 
> > -----Original Message-----
> > From:       Stone, Brad V (TC) 
> > 
> > I can see how one could take OO too far though, as you 
> mentioned.  These
> > examples, while doing a great job of explaining OO, also 
> show that if you
> > were to take something more complex, such as a work order, you could
> > really
> > overdo it.  In other words, these examples are great, but 
> lets now apply
> > it
> > to a real world business programming situation for the 
> benifit of those
> > that
> > want to take it a step further.  These would be much more 
> intense and I
> > could see how it would go so far as to be more confusing 
> that it's worth.
> > 
> > I'd love to hear other's opinions on this, especially 
> anyone who's done
> > production Java and RPG/ILE (real ILE) programming on 
> similar systems.
> +---
> | This is the JAVA/400 Mailing List!
> | To submit a new message, send your mail to JAVA400-L@midrange.com.
> | To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> JAVA400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: joe@zappie.net
> +---
> 
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.