Continuing previous discussion years ago about Buttons and convenience of using OO for GUI programs, I think a Object Orientation is mostly a syntax mask for something relational going on underneath the hood that people never acknowledged.
Take for example a button in SQL:
Code: Select all
INSERT INTO button (color) VALUES (red);
Above, we see a SQL version of a button color being set. This above is verbose and atrocious for programmers to look at. Hence the shortform:
... in languages like delphi.
In languages like C, one would write:
So one must look at this OO code carefully and ask, why is OO convenient? What makes it useful? why do people use it? Obviously the answer is in the clarity of the code, the lack of verbosity, and the simplicity. Compared to the INSERT INTO code, the OO code is much more to the point. The answer as to why people use OO isn't in mathematical theory (sadly), rather it's in the syntax which OO offers. OO has no sound theory behind it, it's purely a syntax game played by OO salesmen. The mathematical theory behind OO
actually includes relations without people knowing it.
What does this mean, practically and positively? Well on a positive note, we can keep the syntax shortcuts, but we must teach programmers in theory what actually is happening by using relational theory, not OO snake oil. We can teach people simply that Button1.color set to red, is actually a shortform for so and so relation. The button is simply a table that is being updated or inserted.
We might have a separate table for each button.
Code: Select all
UPDATE Button2 SET Color=red;
UPDATE Button3 SET Color=blue;
UPDATE Button4 SET Color=red;
However we may also have a table that describes many buttons, rather than one button in a table.
Code: Select all
UPDATE Buttons SET Color=red WHERE id=2;
UPDATE Buttons SET Color=blue WHERE id=3;
In a delphi program one might have an Array of Buttons so that he can perform operations on them using procedural (dangerous) code which could go out of array bounds in a loop, etc. However in typical program we don't often use arrays of buttons, we often have buttons as individual unique items, along with edit boxes, menus, etc., and that's why some see programming GUI widgets as if they were oranges, cars, stereo volume controls, etc. So object orientation is simply an analogy to real life items, but they missed putting some sound theory into it.
I'm still thinking about inheritance and what this would mean relationally, for someone that wanted to take an existing button and improve it, without modifying the old code that the original button was created from.