Hi John,
I do think of object-builders as the same as object-users, since the
object-builders often use other people's objects. If they don't, they
probably should. Granted, the deeper you get into the objects, the more
details the developer is likely to have to deal with, and the less other
developer's objects are available to use.
Honestly, most OOP programmers don't know much at all about RPG or RPG
service programs, and most RPG programmers don't know much at all about
OOP. Hence, in most cases their opinions are uninformed ones.
I do consider service programs object oriented, but just not as flexible as
the capabilities of a language like Java or C#. Languages like Java and C#
allow the code to determine the executed code path much more at run-time,
versus the more compile time approach of RPG service programs. Shifting
more of the decision making that determines the code path executed to
run-time, enhances re-use, and allows one to create a smaller volume of
code.
Granted, I've seen some OOP code that I think is horrible. OOP is not a
magic bullet that prevents one from creating crappy code. I think the
opposite is true. OOP provides more flexibility, which allows one to screw
up even worse. On the other hand, I've seen some OOP code that is simple,
elegant, easily maintainable, and permits code re-use and flexibility well
above what is possible in RPG.
We could all go back to coding in Assembler, but our productivity would be
horrible. The evolution of software development is such that we should be
continuing to strive to accomplish more with less lines of code, thereby
evolving to code at a higher and higher level of abstraction. Both RPG
service programs and OOP exist for that same purpose.
SQL also allows us to accomplish more with less lines of code. I've taken
batch RPG programs that process data, measured in many thousands of lines
of code, and reduced them to a few hundred, dramatically reducing run-time,
and at least for me, dramatically improved read-ability, and the cost of
their maintenance. I provide high level SET based SQL statement(s), and the
SQL engine figures out the details. In practice, this is re-using IBM's
SQL engine objects, but not in the traditional sense of OOP or service
programs. The goals are the same though: code reuse, code reduction, and
providing solutions using a higher level of abstraction.
Small code volume and high levels of abstraction = higher productivity,
assuming the solutions are also read-able and maintainable.
Mike
On Fri, Mar 9, 2018 at 8:57 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:
On Fri, Mar 9, 2018 at 9:49 PM, Mike Jones <mike.jones.sysdev@xxxxxxxxx>
wrote:
Embracing SQL is all about "delegating".
IMO, this is similar in concept to OO programming, where you rely more on
others' objects, and have to let go of some of the details.
That's... an interesting opinion to have.
And you're certainly entitled to your opinions. But... the folks who
build the objects... do you not think of them as object-oriented
programmers?
Do you think of the object-builders as a different kind of programmer
than the object-users?
How about the folks who write ILE modules, programs, or service
programs which are then used by RPG programmers? There's delegation
going on there too, but RPG is certainly not very object-oriented, and
if you ask folks who use languages which are more widely recognized as
object-oriented, they would call neither the service-program writers
nor the service-program consumers "object-oriented programmers".
And by the way, I don't think likening SQL to OOP is a great way to
entice Jon. He's been known to have his differences with OOP as well.
;)
John Y.
midrange.com
