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

On 12/09/2024 09:51 AM, Tim Rentsch wrote:

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).
>

One might call this "idempotent" or "monadic",
vis-a-vis "pure", in the functional programming.
The idea of "no side effects" then also has for
usually that "idempotent" includes "repeatable,
with no side effects", i.e. usually "repeatable
to attempt until success, transactional", or
"repeatable to attempt, idempotent", then with
regards to the monadic that the entire body of
co-routines is all collected and a thing, while
"pure" functions usually mean idempotent, side-effect
free and also returning the same result for the
same inputs.
Not to be confused with "pure virtual" or abstract
methods, say.
Often goals these days include "idempotent routine"
since thusly when "Murphy's law arbitrarily fails
any routine", then thusly what's often "retry-logic"
or "error mode", or "failure mode", makes for what's
usually in "distributed systems" the "eventually
consistent" and "self-healing".
I don't see these so much in classic pattern lit-rature
though it's very widely held knowledge.
Because Murphy's law in distributed systems, ....
Functional programming doesn't exclude "side-effects",
per se.