On 04/08/2019 04:44, David L Neil wrote:
>> Classes should never be named for their data but for their function.
>> What does this class do? What operations does it support.
>
>
> This statement caused me to double-take. Do I misunderstand?
I suspect so, thats why I wrote my follow up.
I was not suggesting that a class name should be a verb,
not at all. Objects are things so class names should be
nouns. Method names should usually be verbs although
that's not always the case.
> They are almost exclusively nouns, eg Customer, Person, Organisation;
> rather than verbs/functions, eg Selling, Addressing, Billing.
Correct and as it should be. But what those nouns do is tell
you about the high level abstraction that the class implements.
They do not tell you explicitly about the data inside the class.
A Person is not a "NameManager" for example.
> [I'm not an OOP-native, and embraced OOP concepts as extensions to
> practices learned whilst programming with languages such as COBOL!]
Relatively few people are OOP natives, nearly everyone comes
at it with a previous experiece of procedural programming.
That's down to how we teach programming.
> Part of my introduction to OOP included the word "entity". A class was
> to represent an entity. An entity would be described (have attributes),
> just like a data-record; and it would have associated actions (methods
> or procedures) which acted on the entity's attributes. An entity was
> described as a 'thing' - no mention of an entity being an action, even
> though 'things' do 'stuff'.
It is not an action, but it has actions. And the only way to
interact with that entity is through its actions. Therefore
the entity is defined to the outside world by its actions.
One highly unfortunate side effect of using the term entity when
talking to traditional programmers is that they associate it with
entity relationship diagrams where entities are effectively data
tables. It sub-consciously causes people to start thinking of objects
as collections of data rather than as collections of operations.
> For this discussion then, a Wikipedia definition* 'will do'. What is
> included in OOP? [sometimes have 'translated' into Python terminology]
>
> - objects
> - data attributes
> - methods
> - inheritance
> - instances and dynamic dispatch
> - encapsulation [dotted notation]
> - composition [will come back to this...]
> - inheritance/delegation [ditto]
> - polymorphism [sub-classing]
Very little in that list has to do with OOP. Most of it is
implementation details of how OOP languages work.
I would narrow that list down to:
objects
abstraction
polymorphism
All the rest are implementation features.
> Simple comprehensions of inheritance and composition boil down to the
> phrases "is a" and "has a". The subjects and objects of such sentences
> will surely be a noun, rather than a verb?
Absolutely, I was not suggesting verbs as class names.
My bad for not making that clearer first time around.
> Employee is a Person
Yes
> Circle/Oval/Square/Triangle/Shape has a CentralPoint
Not necessarily. Or at least, yes they do but that may or may not be
significant in terms of their definition in an OOP system. What
is significant is that Shape is an abstraction of all the others.
So the definition of the methods of all shapes sits in the shape
class and the others specialise those methods to reflect their
individual behaviours.
> class Person(): ...
>
> class Employee( Person ): ...
>
> Python says "everything is an object" and makes little/no distinction
> between "type" and "class":
True, everything is an object but not everything has a class.
At least not explicitly. But everything has a type.
But the distinction between types and classes is a subtlety
that most programmers need not worry about.
> So, what are Python's base types/objects/classes? eg int, str, list. Are
> these "data or function"?
Neither and both.
But they are named for what we do to them.
integers have an expected set of operations
that we can perform. add, subtract, multiply etc.
> "pathlib — Object-oriented filesystem paths". Function or data?
>
> Let's argue that it is a library not a class/object per-se. Fine.
> However, the six (major) classes that library contains, eg Path,
> PosixPath, are all nouns!
Yes but they are objects that expose methods. They are things
that you can actively use, not just storage boxes.
> At first I thought Inspect might be different, but (it is billed as a
> module of functions cf classes!) the classNMs are nouns (one is even
> called "Attribute"). The functions though, are indeed verbs, eg getargs().
Ad that is how it should be.
> Whither "Classes should never be named for their data but for their
> function."?
It's a very old OOP meme going back to the days of Smalltalk, Lisp,
Object Pascal and Objective C (ie the late 80's). It does not mean
the class names are verbs rather that the names reflect what you
will use the