|
Leif, we have substantive differences which simply won't be hashed out here, or perhaps anywhere. If you think a stateful subroutine is the same as a class, then we have no common ground for discussion. If you think a COBOL file I/O module is equivalent to a class, you might have a point, except that the file is persistent and can be acted upon by programs outside the I/O module. Unless you fully enforce through some sort of corporate standard that the file is only accessible through the module, then you do not have a class. The idea of a class is that it represents a set of data that can only be acted upon through the methods of the class. Now, anything that can be done in Java can be done in other languages, but OO techniques are easier - and ENFORCEABLE - in Java. > where the new class "do_it" does it (whatever it is). > And, holy macaroni, guess what: I can change do_it to do > something completely different WITHOUT changing my program. This is where we're going to have to differ. You either don't understand OO, or you're purposely trivializing it. The point of my argument is that if one class does a bunch of stuff and uses a second class, referring to it by interface, and then you substitute a different class that still adheres to the interface, you can change the output of the first class without changing the code. That is a beautiful simplicity and elegance that is difficult to achieve any other way. If you don't see it, then this discussion has no further merit for either of us, or I'm sure for anyone else on this list. > The way to promote Java is not to claim that it is the holy grail, but > to point out that can be a powerful tool to take its place alongside > with all the other ones to use when the situation and circumstances > warrant it. And I've said all along: Java is wonderful for UI, RPG is best for business logic. Of course, you won't "touch" RPG either, so we've got less and less in common. I'll continue on writing business applications my way, and you design your code your way, and we'll just have to leave it at that. I'm saddened and disappointed by your attitude. You have to be purposely missing the points here. Multiple entry points in a polymorphic class are not "non-structured". I/O modules are not classes. Writing a new "do_it" is not polymorphism. If you insist on seeing things that way, great, but we have nothing to say that will benefit one another. And that, I think, is a shame. Joe +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
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.