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 object for in the context of the system under design, not what its internal data is. (A related guideline is that classes should not be called "xxxManager" - objects should manage themselves.) The purpose of these guides is to focus people's minds on objects(active entities) rather than data because focusing on data rather than behaviours is one of the most common errors by OOP newbies. It tends to result in programs that are procedural code disguised inside classes. And that usually results in the worst of both worlds. -- 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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
