On 03/08/2019 17:56, Malcolm Greene wrote: >... interesting thoughts including Alan's "classes should never be named > for their data but for their function" feedback. I'm going to have to > noodle on that one. Let me expand slightly.
Go back to the fundamentals of OOP. OOP is about programs composed of objects that communicate by sending each other messages. Those messages result in the objects executing a method. Objects, therefore are defined by the set of messages that can be sent to them. By their behaviour in other words. The data they contain should only be there to support the behaviour. So an object should expose a set of methods that determine what it can do. It therefore stands to reason that the class (the template for the objects) should have a name that reflects the nature of the messages that can be sent. What kind of thing offers those kinds of capabilities? Once you can describe the operations that the object can perform you can usually find a name that describes the kind of object. One of the anti-patterns of OOP is having classes that expose methods that are unrelated to each other. Then we just have a bunch of data and some functions collected together but no coherent concept. It could be two(or more) genuine classes accidentally merged into one. Or it could be a plain module masquerading as a class. Another clue is where you only ever need a single instance of this "class". That's often a sign that it should just be a module. (There are a very few genuine singleton use cases though, so it's not a cast iron rule.) HTH. -- 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
