an oop question

[Alan Gauld]

On 01/11/2022 17:58, Julieta Shem wrote:

> nowhere in trying to detect in high-precision what is OOP and what is
> not. 

Stefan has given a good answer but essentially OOP is a program
that is structured around objects communicating by sending
messages to one another.

Objects are, in most (but not all) languages implemented using classes.
A class is just a record or structure that can contain data and
functions. In most (but not all) implementations of OOP messages
are implemented as calls to the functions within an objects class.


>  The same for classes.  I always liked to think of C structures as
> some class. 

Provided that we allow pointers to functions within the struct then yes.
Indeed the difference between structs and classes in C++ is very thin.

And with the recent introduction of data classes in Python the
boundaries are blurred here too. In pure OOP a class with only
data would be pointless(since the data should ideally be hidden
or "private"!)

> structure Whatever si the class itself.  Is this use of C outside of
> OOP?  I say it is not because my notion of OOP is that --- a way to make
> objects and have methods operate on them, changing them or not.

It's how many early attempts at OOP in C worked, including C++.
Others, such as Objective C and cFlavours took a different approach.

But conceptually methods do not "operate on objects"
methods are how objects respond to messages. Eah object has its own
method of handling a particular message. (This is polymorphism)
In most (but not all) practical implementations methods are
usually implemented as functions and so it seems like a message
is just a synonym for acalling a method, but is more than that, it
implies some kind of dynamic lookup. (for example when the method is
implemented in a paremt class rather than the directly referenced one.

But the functions that represent methods do indeed operate on their
own object - ie self.

> To me what distinguishes functional from imperative is, 

Not that imperative programming is not the same as OOP. Or at
least it encompasses much more than OOP. Most OOP programs are
written in imperative languages but it is possible to have
functional OOP programs too. (If we consider the state data
to be a single compound value that can only be changed by
the object internally, or a new object with different
state values returned.)

>> IS-A relationship, so Stack inheriting Pair would mean that a Stack
>> was a Pair. That is not really true.
> 
> That's another interesting observation.  I do not have much
> understanding of how to really think of these things

Read up on the Liskoff substitution principle as one approach to
determining what an IS-A relationship means. Its not the only
approach but it is less vague than some others!

>> to complications. If in doubt use delegation instead.
> 
> What is delegation?

A fancy OOP term to mean containment.
Specifically a method delegates the work top some internal
object. eg. You can build a stack by containg a list within
it. The stack delegates much of the work to the list object.
In fact, in Python a stack can be a very thin wrapper over
a list!

> Any book recomendations on getting this thing mathematics-clear?

The best book is IMHO Bertrand Meyer's book "Object Oriented
Software Construction". It uses his own language,. Eiffel, but
gives an excellent description of applied OOP and all of its
features (Eiffel is perhaps the most feature complete OOPL of
all - but, being proprietary (and somewhat buggy!) it has
never quite caught on)

But for a mathematical basis you need to look outside programming
at systems engineering and the work done on cellular automata.
In a pure OOP program each object should act as an independant
cell communicating by asynchronous messages. Exactly as in
cellular automata theory. ..

Unfortunately, there is a huge gap between pure OOP theory and
practical OOP languages! And just as big a gap between OOP language
potential and real-world OOP usage.  Very few purely OOP programs
exist (maybe excepting in Smalltalk - see Stefan's posts again). :-(

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos