I think in a lot of ways we're agreeing , but with a few semantic
differences. I'll point out a couple, and maybe one or two places where
we can just agree to disagree.
I would say the prime selling point of any paradigm is how well it
models the problems you are trying to solve. Some problems happen to
conceptually fit very nicely into an object-based model. For me, GUIs
seem to be quite naturally object-oriented. Back-end business logic
is often not a good fit for OO (though it conceivably could be, for
some businesses and for some programmers).
Agreed. GUI is a natural fit for OO, business logic not so much,
although there are lots of places where OO components may certainly make
sense (e.g., encapsulation).
I disagree. I think whether something is hard or easy to change is
mostly in the design. A *truly major* change is going to be hard in
any system.
Here we have to agree to disagree. In my experience, the real world
throws changes that can't possibly be foreseen. You write a system that
does exactly what you want. And then the company merges with another
company and one of your fundamental design assumptions goes out the
window (maybe you are thrust into multi-currency, or you have to deal
with coproducts when you didn't before - the possibilities are
endless). Sometimes new government regulations kill you - my favorite
was when the payroll tax was split; that kicked the crap out of lots of
payroll systems.
Highly OO systems - especially systems with lots of data hiding - are
often harder to modify in this situation. That's because most business
objects are inter-related, and almost without fail you end up with a
calculation that needs more data than it did originally. You either
have to include that data in some object that didn't need it before, or
you have to add it to a global session object, or you have to change the
signature of a function. And after a few changes like this, you realize
that your hierarchy is out of whack, and it's time to refactor it. And
that's when major changes are very hard.
With procedural code it's very easy. Adding a field to a data structure
is easy, adding a CHAIN to another file is simple, even adding a
parameter to a call is not particularly difficult; all of it is usually
very easy because you're not as locked into the rigidity of what is
passed between layers. Now, this is my own personal experience, and as
you note, composition rather than subclassing mitigates this problem to
some degree, but it's still easier to modify a procedural program than a
highly segmented object hierarchy.
And a relatively minor change is going to be hard in a
system that isn't designed to accommodate it. (I would like to say
"any change is hard in a poorly designed system" but it depends on the
ways in which the system was poorly designed. A poorly designed
system might nonetheless be easy to add duct tape to, for example.)
Future proofing is part science, part art and frankly part luck. But
systemic changes of the nature I've mentioned have in my experience
always been much easier to do in procedural environments rather than OO.
I think well-designed OO systems are just as easy to make major
changes to as well-designed procedural systems, perhaps easier. Not
all OO systems are based on a "class hierarchy".
Well, this is technically not true. All OO systems require classes.
The objects must be parts of a hierarchy. Certainly your runtime has
lots of classes, and lots of those classes subclass others. Now, you
may be able to design applications where every class is a root class and
has no superclass (in Java, all would subclass Object) and your entire
design is composition. I've never tried it and I have seen very few
non-trivial systems that didn't have some degree of subclassing; it's
the fundamental technique to implement code reuse.
At least for me,
that is not what OO is about. And as I mentioned earlier, I find GUIs
a natural fit for OO, and this is a highly dynamic problem, both in
terms of the event-driven nature of user input, and in the fact that
the specs and requirements for a GUI can change approximately as often
as the business rules behind it.
Here's where we just have a semantic difference. You say that GUI is a
dynamic problem, and I consider GUIs to be one of the most static
problem sets we program. For example, there is only one way to program
an HTML tag: it has a bracket, a keyword, and an optional set of
attributes. It can have data that is then closed by a closing tag of
the same kind, or it can be a self-closing tag. This is a perfect
problem set for OO - you can easily define a class called HTML tag, and
that class can be used for any type of tag. You can also build on that
class either through composition or inheritance to create more complex
and more specific tags. But the reason I consider the problem set
static is that once written those classes don't change. Which tags you
actually place on the screen to address a specific business problem
certainly changes, but populating the data is something I would write
in a procedural language, because how you get the data may change
depending on the business situation.
And I'm not the only one who thinks procedural languages have
their uses, Java may be the number one language, but C is
number 2, and there ain't no objects in C.
Ah, but who would use C for their business logic either? C is not
meant for things that RPG is meant for. That is not why C is still so
popular. C's popularity is not an argument for "procedural language"
popularity (or relevance or importance or what have you). C provides
no coattails for RPG to hang onto in a discussion comparing languages.
Why certainly it does. If OO was the perfect solution for everything,
then you would program everything in C++ not C. C++ would have long
overtaken C much the same way that C# has eclipsed VB, but it has not.
There is an entire significant problem realm in which OO is not the tool
of choice. My point is that in business programming, the same is true.
There are problem sets which OO is good for, and others where it is not
and for most of the latter RPG is the best fit.
If your only point is that OO is no silver bullet, fine. But I don't
think anyone is arguing (seriously) that *everything* should be done
with OO languages, or even in an object-oriented way (regardless of
language).
Hmm. Then you don't read the "Java will replace RPG" comments that are
everywhere. A related argument is the "SQL must replace native I/O"
discussion. I just have a problem with any argument that says one
technique or language is intrinsically better than another. In context,
each tool has its strengths and weaknesses. And in my opinion, the
ability to respond to major external stimuli is a strength for
procedural languages.
Further, so-called OO languages are really just languages that happen
to provide explicit support for some set of OO mechanisms; these
languages do not define what OO is, and using such languages is not
the same thing as (nor is it even required for) OO programming.
At the same time, if you use an OO language and don't use its OO
constructs, then you aren't really using the language. For example,
using Java purely for procedural programming isn't really using Java.
But that's a different topic entirely.
Joe
midrange.com
