Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c++
Subject: Re: What is OOP? --- The most important aspect of OOP
Date: Mon, 09 Dec 2024 09:51:06 -0800
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <86ldwoiw39.fsf@linuxsc.com>
References: <d8a5a0d563f0b9b78b34711d12d4975a7941f53a.camel@gmail.com> <86frn6og85.fsf@linuxsc.com> <vj0cj5$2n835$1@dont-email.me> <90e75c71c42fcf43b89644a46a60e4fff63ecc10@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 09 Dec 2024 18:51:09 +0100 (CET)
Injection-Info: dont-email.me; posting-host="892b8ce7ac5e3c5327272332675a4c02";
	logging-data="544175"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18ekihXzZ93s/c5A5tP9VpFoFQATl1W/wo="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:0/yTR4/IyhrSiSM7dbZ4Xc2sZ8s=
	sha1:IExZyGkEnNlmakdZ0Nb/RJTnafk=
Bytes: 4415

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