I first got the hang of oo programming using VBA, and later VBS; consequently I 
don't think much about inheritance.  But when I finally broke down and got 
myself a copy of ooRexx, I see the manuals have a lot to say about it.  Mostly 
I read those parts skimpily and have never yet had occasion to use those 
features.

I wonder, though, whether your objections apply as thoroughly to ooRexx as they 
do to some other languages?  I seem to recall that ooREXX has a way of 
specifying which methods a class inherits from other classes.  Might not that 
obviate some of the problems?

---
Bob Bridges, [email protected], cell 336 382-7313

/* Question:  Would you rather raise a child who grows up to be (a) an honest, 
ethical, family-centered person who works on an assembly line or (b) a 
habitually dishonest, amoral narcissist who is the CEO of a big corporation?  
If your answer is (a), then answer this:  Which child would you brag about 
more?  -John K Resemond, "Who's in Charge Around Here?"; United Airlines' 
magazine "Hemispheres", Sep 1999 */

-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of 
David Crayford
Sent: Thursday, June 1, 2023 07:25

I totally agree that Object-Oriented (OO) programming hasn't lived up to all 
the hype it once had. But I have to disagree with the idea that code reuse is 
the only purpose of OO. It's actually more nuanced than that. 
However, if we're talking about code reuse and Java, just take a look at the 
Maven central repository. It's got a whopping 400,000 unique artifacts and 
handles a mind-blowing 70 million downloads every year. 
Now that's some serious code reuse, and it's all thanks to the open-source 
community. Pretty amazing, huh?

I think a lot of the misunderstanding about OO is related to inheritance which 
was popular in the 90's but not so much now now. Inheritance is not inherently 
bad in OOP, but it can have drawbacks when misused or overused. Here are a few 
reasons why it can be problematic:

 1. Tight Coupling: Inheritance creates a strong connection between
    classes, making changes in the base class impact all its subclasses,
    which can make the code fragile and less flexible.

 2. Inappropriate Subclassing: Using inheritance when it's not suitable
    can lead to confusing and convoluted code that is hard to understand.

 3. Complexity: Large inheritance hierarchies can become complex and
    difficult to manage, leading to maintenance issues.

 4. Code Duplication and Rigidity: Inheritance can result in code
    duplication and make it challenging to modify the base class or
    rearrange the hierarchy.

 5. Limited Reusability: Inheritance can restrict code reusability by
    tightly binding subclasses to their base class, limiting their use
    in different contexts.

It's crucial to use inheritance judiciously and consider alternative approaches 
when appropriate to avoid these potential drawbacks. Modern languages such as 
Go and Rust do not support inheritance. They support interfaces (traits) which 
are fundamental for polymorphism.

Polymorphism reduces the need for extensive if-else logic by allowing different 
objects to respond to the same method call in different ways. 
Instead of using if-else statements to check the type of an object and perform 
specific actions, polymorphism enables us to define common methods in a 
superclass or interface and rely on the specific implementations in subclasses.

No need to define encapsulation (data hiding) as we all know what that is. The 
WORKING-STORAGE section in COBOL really highlights the stark differences 
between COBOL and modern languages. In COBOL, all data, including loop indexes 
used within a routine, are global. Nowadays, this global scope for data makes 
me quite uncomfortable, especially when I'm accustomed to being able to declare 
variables within specific blocks like for loops or if statements. 
Unfortunately, COBOL doesn't excel in terms of lexical scoping, which is a 
strong point in modern programming languages.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to