[Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

Alan Gauld alan.gauld at btinternet.com
Sun Jan 24 04:11:28 EST 2016


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




More information about the Tutor mailing list