My impression is that you can hardly call this OOO:
Object Oriented Orthodoxy. For instance, from the GOF I learned:
Aaah, the dear GOF book. You do realize that the GOF book is, to a
lange extent, a book about the shortcomings of C++, don't you?
For example, think about how you would implement the Decorator and the
State patterns in Python.
I would advise against basing your understanding of what object
oriented programming is about, on the GOF book.
- the object's internal state can not be accessed directly
This is blatantly false, as your code snippet below clearly
demonstrates. (You probably meant "should not" rather that "can not".
The "should not" is a dogma. Understand its motivation, and decide for
yourself to what extent you want to buy it.)
- operations are the only way to change an object's internal state
Ditto. (... "are the only way" -> "should be the only way" ...)
- requests (or messages) are the only way to get an object
to execute an operation
Read up about properties in Python.
Strictly speaking, it's not an object which executes an operation;
rather methods carry out operations on objects. And it's certainly not
true that messages are the only way to get a method to carry out an
operation on objects ... put differently: generic functions exist.
It is not easy to find definitions of 'interface' in python books,
How about "Anything that does not start with an underscore" ?
(One can argue about the details of this proto-definition, but in terms
of value per word, it's pretty good, I'd say.)
And now you suggest that everything that is accessible is part
of the interface.
No. I suggest that everything that is part of the interface is part of
the interface. Put in other terms, everything that is not marked as
private, is part of the interface (or in some languages, everything
that is marked as public, is part of the interface --- though "private"
and "public" might not be the words which are used to describe a
similar concept in those languages). Some languages (notably C++ and
Java) consider that marking things as private is not good enough (I
guess that the assumption is that people who program in those languages
are too stupid to understand the importance of interfaces and to
respect them), and such languages attempt to make the private parts
inaccessible.
Encapsulation and access restriction are orthogonal concepts, which
have been conflated in Java and C++. That doesn't make them any less
orthogonal, as concepts ... so don't make the (all too common mistake)
of believing that they are actually one and the same.
I think I prefer the orthodoxy.
Into bondage, are you ?
I suppose that is what you mean when you say:
but I need more explanations, arguments, references.
Well, in terms of explanations and arguments, I was steering you
towards a discussion of the generic-function OO paradigm ... but you
seem not to have followed that up.
In terms of references ... try looking into some languages which
support OO, which predate Java and C++ (or which are otherwise not
influenced by them, or, at least, look very different from them.) You
could try Smalltalk, or Common Lisp, for example.
You seem to encourage the following practice:
Absolutely.
the internal state of c is not private,
This is not generally true, but it is true in this case.
For example, I would discourage the following:
class C:
def __init__(self):
self._x = 3
c = C()
c._x = 9
Note that I would not forbid it. In fact, I would encourage it, in some
situations. For example
a) You are debugging your application, or investigating its behaviour
b) The author of C hadn't anticipated some perfectly valid use you wish
to make of C, and didn't provide you with an adequate interface