Re: why is "self" used in OO-Python?
- From: castironpi <castironpi@xxxxxxxxx>
- Date: Sat, 12 Jul 2008 11:44:40 -0700 (PDT)
On Jul 12, 1:01 pm, Duncan Booth <duncan.bo...@xxxxxxxxxxxxxxx> wrote:
ssecorp <circularf...@xxxxxxxxx> wrote:
1. Why do I have to pass self into every method in a class? Since I am
always doing why cant this be automated or abstracted away?
Are the instances where I won't pass self?
I imagine there is some tradeoff involved otherwise it would have been
done away with.
When you define a method in Java there is an implicit 'this' passed to the
method. Python cannot tell when you define a function whether the function
is going to be used as a function, an instance method, a class method, a
static method or something else (or all of the above). Consider this:
The dynamic nature of Python means you can lift a method out of a class and
re-use it in a different context or inject a function into a class as a
method. There are two ways to handle this sort of code: javascript has an
implied 'this' for everything whether a function or what passes for a
method, Python makes it explicit.
2. self.item instead of getters and setters. I thought one of the main
purposes of OO was encapsulation. Doesn't messing with internal object-
representations break this?
That is correct. Some languages (e.g. Java) don't allow you to encapsulate
attributes so you have to write getter and setter methods. If you expose an
attribute in Java then you cannot later insert some code into the lookup or
override the set without getting all users of your code to change the way
they access the value. This is bad.
Other languages (e.g. Python, C#) allow you to intercept the attribute
lookup so you can change a plain attribute into a property without
requiring the users of your class alter their source code. With C# I
think they would still need to recompile their code so it may be more
appropriate to avoid using public attributes if you are producing a class
library for widespread reuse, but with Python there is no difference to the
user of your class whether they are accessing an attribute or a property.
Sadly a lot of Java programmers mistake the limitations of their language
for rules of OO programming, and worse this has spread from Java into other
languages where these restrictions no longer need apply.
Your Stack class is a bad example: the stack attribute is purely internal
so you wouldn't want to expose it as part of the public interface. Consider
instead something like:
class AddressBookEntry(object):
def __init__(self, name, phone):
self.name = name
self.phone = phone
@property
def phone(self):
return self._phone
@property.setter
def phone(self, number)
validatephonenumber(number) # may throw an exception
self._phone = number
If later you want to add some processing to the name attribute it is easy,
but putting in dummy property getter/setter methods before you need them
would be pointless.
Part of the value of accessor methods appears when you're changing
class definitions, or changing classes, after you've already started
to use them-- the same interface with a different implementation.
In the AddressBookEntry example, if you changed a pickled dictionary
to a shelf, you could reimplement the class and reprocess stored data
files, all without changing the code that uses the class-- especially
if there's a lot of it, or you don't know where it all is.
Nothing stops you from using accessor methods to offer encapsulation,
and permit back-end changes later. But, nothing in Java stops you
from declaring class members public.
Depending on your development process, data hiding may enforce
distribution of labor a little better, resulting in errors in Java
where Python relies only on discipline. If you're checking for value
validation, you can write a custom setter, regardless of language.
Python doesn't break encapsulation; you do.
In the Stack example, you have more options than you've mentioned.
Can you inherit from list directly? Can you delegate using
reflection? Are you studying this example specifically, or the class
model generally? If you're choosing a language, be careful that
stricter enforcement doesn't cause harder-to-find bugs.
Useful link: Section 9.4 in the docs: http://docs.python.org/tut/node11.html
.
- Follow-Ups:
- Re: why is "self" used in OO-Python?
- From: ssecorp
- Re: why is "self" used in OO-Python?
- References:
- why is "self" used in OO-Python?
- From: ssecorp
- Re: why is "self" used in OO-Python?
- From: Duncan Booth
- why is "self" used in OO-Python?
- Prev by Date: Re: Does omniORBpy 3.2 supports DII?
- Next by Date: Beginner Question : Iterators and zip
- Previous by thread: Re: why is "self" used in OO-Python?
- Next by thread: Re: why is "self" used in OO-Python?
- Index(es):
Relevant Pages
|
