Re: What is OOP? --- The most important aspect of OOP

Richard Damon <richard@damon-family.org> writes:

On 12/6/24 9:40 PM, olcott wrote:
>

On 12/1/2024 10:34 PM, Tim Rentsch wrote:
>

wij <wyniijj5@gmail.com> writes:
>
In response to the question of the subject line...
>
Just because a program is being written in a language that has
functions doesn't mean that what is being done is functional
programming.
>
Just because a program is being written in a language that has
classes and objects doesn't mean that what is being done is
object-oriented programming.
>
More than anything else object-oriented programming is a mindset
or a programming methodology.  It helps if the language being
used supports classes, etc, but the methodology can be used even
in languages that don't have them.
>
A quote:
>
 My guess is that object-oriented programming will be in the
 1980s what structured programming was in the 1970s.
 Everyone will be in favor of it.  Every manufacturer will
 promote his products as supporting it.  Every manager will
 pay lip service to it.  Every programmer will practice it
 (differently).  And no one will know just what it is.
>
That paragraph is taken from a paper written more than 40 years
ago.  The prediction came true with a vengeance, even more than
the author expected.  Most of what has been written about object
oriented programming was done by people who didn't understand it.
>
Two more quotes, these from Alan Kay:
>
 I invented the term "Object Oriented Programming," and C++
 is not what I had in mind.
>
 Though Smalltalk's structure allows the technique now known
 as data abstraction to be easily (and more generally)
 employed, the entire thrust of its design has been to
 supersede the concept of data and procedures entirely;  to
 replace these with the more generally useful notions of
 activity, communication, and inheritance.

>
The most important aspect of OOP is the ability to decompose
a problem into independent component parts.  This can eliminate
the side effects in the structured programming model that
result from global data.

>
Excpet that normally OOP is fully based on the operation resulting in
"side effects" as they mutate the state of the object the methods are
part of.
>
What this does is not ELIMINATE the side effects, but limits their
scope.  A given object type will tend to keep its own state "private"
and interact only with other object via "public" interfaces, allowing
us to limit the scope we need to think of when looking at
interactions.
>
This makes it very different from the "functional" model, where we do
not allow for side-effects.

I agree with the first paragraph, because of the word "normally".  I
think it's important to add that there is no inherent incompatibility
between object-oriented programming and functional programming.  There
are ways to work with classes and objects in a fully functional mode,
in much the same way that one can write code for data structures such
as AVL trees or B-trees that is fully functional (so there are no side
effects to existing trees when adding or deleting elements, for
example).