|
Leif, I'm going to have to disagree with you here. Classes and subroutines are completely different programming entities. Subroutine take parameters passed to them and do things to those parameters. Classes, on the other hand, have an internal state that they act on in response to messages, and that they will communicate to the outside world. The two concepts - classes and subroutines - can often be used to solve the same programming problems, but they are very, very different beasts. Now, when your subroutine is part of a service program that has an internal state (like many operating system calls), then yes, it's closer to a class. Or even in RPG III, if you just don't set on LR, and call the program repeatedly getting different results based on the programs current internal state, then it's closer to the class concept. But the other things that make classes so powerful, such as multiple entry points (polymorphism) and more importantly being able to change the behavior of an object through subclassing, are too powerful to be ignored and thought of as just the "1%" difference between OO and procedural code. We just had a fairly long and enjoyable conversation on JAVA400-L between Brad Stone and I on how true OO design makes a simple program incredibly powerful. In this case, we showed how, by changing his design in some ways that are counter-intuitive to most procedural programmers, he would be able to add the capability for his program to return either XML or HTML by changing just one line of code. More importantly, he'd be able to add a whole new style, say WML or VML, without having to change his program at all - just add a new class. This CAN be done procedurally, using subroutines, but it's almost impossible, and it requires reinventing wheels (for example, a dispatcher) that are already present in Java. Alien, perhaps, but if you can come to terms with BIFs and APIs and activation groups, you can manage classes and objects. I did, and I'm a 20+ year RPG dinosaur. > Joe, part of what scares people is simply the alien words. > "Classes", "instantiation", etc. The "class" is 99% the same > as the good ol'e external subroutine. The 1% being the fancy > stuff most application programmers don't need to know and > (sadly) don't want to know. Everyone is familiar with the concept > of a good in-house subroutine library. And don't call them "business > objects", either. +--- | 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.