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.
On 29/5/2023 6:40 am, Tom Ross wrote:
Hi, While working on the earlier problems I had, I ran into the concepts=20
of COBOL Methods and Classes, and understand they can be used for Java=20
in addition to regular COBOL programs. The documentation does not=20
explain the "why" behind these or the "how" and "what", so I wonder if=20
anyone has any business case explanations of what these are or samples=20
of some COBOL-only implementations so I can see why I might want to use=20
them and how to do it?
I like to keep my COBOL current and if there is a way to use COBOL more=20
effectively, I hope you can help me understand this!
OO COBOL was added to COBOL to provide a way to communicate with Java, which
does not have programs that can be called. Java has to run in the JVM, and
you INVOKE methods in CLASSes with Java, you do not CALL programs. So, in
order to support this we created OO COBOL (the 2nd generation, 1st gen OO COBOL
was based on SOM if anyone remenber that in the late 1990s). OO COBOL is only
for communicatiing for Java, unless you REALLY prefer OO programming. The real
worl is not object oriented...we do no instantiate a customer object and then
invoke a 'send_a_bill' method on that object. We procedurally decide that it
is time to send a cusotmer a bill and do it!
Haivng said that, we now have an easier way to allow COBOL to use Java code,
actually using the COBOL CALL statement, this new feature is available in
COBOL 6.4. If you do not need to communicate with Java, I would not
recommend OO COBOL. The promise of Object Oriented Programing in the 1990s
has not materialized. Re-usable tested mehods that could be re-used to build
applications it just not really happening! One of my fellow IBMers left
IBM for a start up and was slinging Java all day, and found it much easier to
code new methods than to search through class libraries for pre-tested parts.
Having said all that, it was pointed out earlier that we have seample in the
COBOL Programing Guide for comunicating woith Java using OO COBOL. OO COBOL
was not designed to be used in a pure COBOL application, so no examples of
that.
Cheers,
TomR >> COBOL is the Language of the Future! <<
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
