What is wrong with OOP?

Thu Nov 3 02:55:00 UTC 2022

Ok, I'm going to jump in on this one as well.... :)

As someone who has been using Object Oriented languages (specifically 
C++) for 25+ years, I am a big fan of Object Orientation however it is 
neither a silver bullet nor a guarantee to improve your code. OO in the 
hands of a master craftsman can do wonders but it can equally provide a 
complex solution to a simple problem. Some have turned that last one 
into an art form (looking at you JAVA and MFC developers)...

I'd also like to make the side note that relational databases, and 
processes performed on relational database, aren't object oriented and 
writing OOP code on top of them more often than not, creates a complex 
solution for a simple problem. That isn't to say that OOP has no place 
in what we do, but if you aren't realistic about both it's strengths and 
it's weaknesses, this is the part where overly complex solutions are born.

For me there are two key principles to Object Oriented Programming that 
I think matter in this discussion and I'm going to start with the one I 
find most important in relation to Martins question.

Encapsulation

The principle of encapsulation is probably the biggest safeguard against 
spaghetti code when applied properly. When you treat data as something 
internal, not directly accessible from the outside world, and you 
dictate that methods belong to data and are only allowed to modify the 
data held within, you create a natural way to break big problems into 
small independent chunks that isolate clearly defined actions. It is the 
antithesis to long-winded spaghetti code that touches a hundred things.

However, when used wrong, when you draw the wrong lines, organize your 
objects wrong, encapsulation can just become a frustrating barrier as 
you jump through hoops to tie a process together that requires the use, 
and modification, of data held by countless objects.

Still I find myself keeping the principle of encapsulation in mind even 
when using programming languages that are not Object Oriented and find 
myself writing better, clearer and most importantly, safer code in every 
scenario.

Inheritance

Probably the key principle of Object Oriented design, it is both its 
biggest strength, and its greatest weakness. When used well, its pure 
magic, when used wrongly, it's the root cause of all the bloated 
incomprehensible solutions out there.

The biggest issue I think here is that coming up with a good structure, 
or where classes should share a common parent, where inheritance makes 
your design better, and where it doesn't, is something that only comes 
with experience, and only for developers who have a suitable mindset for 
OO design. Add to that, as I just wrote above, we live in a database 
world and trying to translate relational databases to objects often 
leads to bad designs, I've seen many here struggle to make this work in 
their favor.

This has often been my gripe with Omnis Studio. Omnis Studio in trying 
to be more like other OO languages, lost something key that Omnis 
Classic had. Classic allowed people who had no understanding of OO, who 
were procedural in mind, create programs with almost the right amount of 
Object Orientation.

Because whether you've realized or not, Omnis Class at heart is an 
Object Oriented programming environment, it just cleverly hides it from 
those making applications with it, because it has almost the right 
amount of OO for the job.

Windows, Menus, Reports are all "subclasses" of the format "class", they 
share the same properties, they share the same internals, they are just 
different implementations of the same core. Anyone who's ever dived into 
the internals of an Omnis Library knows this and a few of us have even 
abused that knowledge to do some really funky things.
Every Window you create in Omnis Classic, is a "subclass" of the Window 
class (just like in Studio), every Menu you create is a "subclass" of 
the Menu class, etc.

The same goes for all the controls, menu lines, labels, editing fields, 
list, etc. they are all subclasses of a base control class and it 
resulted in Omnis Classic doing something better then many of its peers, 
it created a consistency among controls that is unparalleled.
If you understand how one component works, you can work with the others.

What Omnis Classic lacked most was encapsulation, you could access the 
internals off one window with another, all data was (practically) 
global. That is where it faltered most and invited developers to create 
the worst spaghetti imaginable.

The other thing it missed was instancing, you can only have one instance 
of a Window open, and when you really thought about it, all windows were 
instantiated from the start, "opening" a window was really more akin to 
unhiding that window, all the windows state exists from the start and is 
retained when you closed ("hid") the window and was still there when you 
opened ("unhid") the window.
On one hand, it made it 100x easier to work with as the idioms of 
classes and instances is one that many have trouble with, especially 
when the IDE misleads you. On the other hand, not being able to open 
multiple copies of the same window, menu or other entity, was a huge 
shortcoming.

I believe that Omnis Studio added a level of complexity that hurt more 
people then it helped by exposing far too much.
I believe it would have been a far stronger product, with a much lower 
bar of entry, if it had found some middle ground between Classic and Studio.

Treating formats as classes that you needed to instance, and by doing so 
allowing multiple instances and almost by extension adding encapsulation 
into the mix, but leaving most everything else intact, sticking with the 
4GL language instead of notation, maybe even leaving out further 
subclassing (I would have missed it, but I think it would have made 
Omnis much more accessible), it would have been a strong product imho.

But that's just me and my rant on the subject :)

Cheers,

Bas

On 2/11/2022 9:08 pm, Martin Obongita via omnisdev-en wrote:
> Hi Friends,
>
> Today, I woke up to a bad start.
> In my Youtube linefeed, I found 2 fairlyold videos of why OOP is bad:
> 1.     Object-OrientedProgramming is Bad By Brial Will
> 2.     What’s wrong with OOP by Roberto Sasso
> Being a curious cat, I watched them in full.
> I know that this topic of, which is abetter programming paradigm, has been discussed over and over again.
> But, could an old-timer, experienced in thefield, give me hope that Omnis still is a better OOP tool?
> Of much interest to me is how OOP resolves “spaghetticode” that’s common in procedural code.
> I am also still a curious "cat" to know if there is any incentive to move over to procedural.
>
> Martin Obongita.
> _____________________________________________________________
> Manage your list subscriptions at https://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com

-- 
Kindest Regards,

Bastiaan Olij
Unit 58 / 35-39 Fontenoy Road
Macquarie Park NSW 2113
Australia
bastiaan at muxworks.com.au
+61-432144833