On 24/01/16 03:07, boB Stepp wrote: >> In pure OO objects should only expose methods and the data >> attributes should only be there to support the methods. > > Apparently what OOP knowledge I started out with agrees strongly with > what you say here. But this level of *purity* appears to be > non-Pythonic in actual practice.
Python allows you to be as pure as you want to be. The choice is mainly in the hands of the consumer of the class. They get to decide whether they want/need to poke about with the internals. If a class is well designed it should be possible to use its operations without directly modifying its data. Reading data directly in Python is usually considered ok. But laziness or the need for speed (of development) often corrupts purity. > So, in your opinion, how far should > I go towards emulating pure OO objects? As above, I try to ensure that the class operations do not require the user to poke values in (possibly by providing parameters). I "allow/encourage" direct access to read. As an example class Point: def __init__(self,x,y): self.x = x self.y = y def distance(self): return (self.x**2+self.y**2)**0.5 def moveTo(self,new_x,new_y): self.x = x self.y = y By providing the moveTo() method there should be no reason for users to set x or y individually. But I encourage direct reading by not providing get() methods. In pure OOP I should provide a Coords() method too. >> monolithic algorithms/functions often get split into small >> chunks distributed over several classes. > > With functions, the ideal is that each function executes a single, > specific purpose. Still true in OOP > With large classes, what should I use as a guide as > to when to split them into smaller ones? Is it a single thing? Or is it really trying to be multiple things? Of course a large object may be composed of many smaller objects. A model of a car may have wheels, engines, brakes etc. And the code for the accelerate() method may delegate to engine and wheel methods rather than directly reading the engine data. > class, perhaps one that looks to be useful on its own in other > programming scenarios. Am I close to hitting the nail on the head > here? Yes, re-use is also a good reason to ask should this be a separate object? But reuse alone is not strong enough to break up what is a single entity, although if its a function you want you might find that you can extract it into a mixin class (ie one that reflects a behaviour rather than a noun and is usually inherited as part of a multi-inheritance lattice) - such as loggable, or colored. 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