> So I have been trying to figure out how to get around doing getters > and setters and still have an oo way to inherit and apply business > rules.
I think you are missing the point a wee bit. The object should not allow you to access its internal data. You should not *need* to access its internal data. The object has responsibilities in the form of behaviours. The internal data is only there to support those behaviours, it should be of no interest to external objects, therefore you do not need setters and getters. Its not the setXXX getXXX thing thats wromg its the very idea that users of the object would want to access the internal data that is wrong. In the words of Peter Coad, "Objects do it to themselves" Now in some applications you do need the internal values, but usually its as a group. For example an Address class might have a method to return the full address content, but rather than provide individuual set/get methods per field it would return the whole address as a string or a tuple.(Note that both of these are immutable types!) In some cases you may actually choose to expose one particular attribute, in which case a get/set pair for that one attribute is OK - they represent a genuine responsibility of the class. (Making it a property might be better still...) Its providing get/set pairs for *every attribute* that breaks good OOP practice. PS. For a more formal description of the above principle look up "The Law of Demeter" on Google. HTH, Alan G Author of the Learn to Program web tutor http://www.freenetpages.co.uk/hp/alan.gauld _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor