[Python-talk] [Fwd: OOP, when and when not to use it...]

[Hewitt_Tech]

Lloyd Kvam wrote:
> For list, but miss-addressed:  sent to python-talk-bounces.
> 
> (I see that my email client (Evolution) picked up the
> python-talk-bounces address and auto-magically placed it in my address
> book, so I might have polluted this thread with the bad address.)
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> OOP, when and when not to use it...
> From:
> Paul Lussier <p.lussier at comcast.net>
> Date:
> Mon, 10 Aug 2009 08:11:39 -0400
> To:
> python-talk-bounces at dlslug.org
> 
> To:
> python-talk-bounces at dlslug.org
> 
> 
> Hi folks,
> 
> I've been lurking on this list for quite a while and just finished
> reading through the thread where Bruce feels a bit lost in when/how to
> use OOP methodologies vs. a more traditional style.  I'd like to offer
> my thoughts from the perspective of a novice programmer with a decent,
> though basic understanding of the OOP way.  My own introduction to OOP
> came from perl, which I've been writing in for over 15 years.  I've only
> been playing with python for a little over 6-8 months now, but I've
> found that there's little difference between the two languages when it
> comes to how you organize and use the code you write (obviously the
> syntax and the code it self differs greatly, as "the perl way" and "the
> python way" are very, very different mindsets).
> 
> First, OOP is really nothing more than a different way to organize your
> code.  There's nothing magical about it.  An "object" is just a "thingy"
> that does "stuff" and has "things".  Which is a more technical way of
> saying that "Objects have methods and attributes".  The methods are the
> means of an object "doing stuff" and the attributes are the means of an
> object "having stuff" or characteristics.  A car can move forwards,
> backwards, turn in circles; it has 2 or 4 doors, 4 or more wheels, etc.
> 
> Objects come in different "types" which simply means that certain
> methods and attributes are slightly different than the defaults.  For
> example, a truck is a type of car that might only have 2 doors, but 6
> wheels and a cargo area.  Seeing this type of thing usually implies that
> very vague and confusing topic of "inheritance", which simply means
> you've "extended a class".  I.e. you had one type of object that does
> and has certain properties, and you've created a new type of object that
> still has the basic properties of the original (i.e. it's inherited from
> the "parent class") but it extends that basic idea to do and have more
> stuff.
> 
> When do you use OOP vs. a more traditional style?  Well, whenever it's
> more useful to think of what you're doing in the terms of objects.  And
> there isn't any reason you have to write entirely in an OOP fashion.
> You can use some libraries which provide classes and others which don't.
> 
> I find that when I need to maintain state, it's usually a good idea to
> start using objects.  When are you "maintaining state", whenever you
> start needing to pass a lot of variables into functions, or trying to
> figure out the current values of variables as the pertain to a specific
> "thingy", you're maintaining state.  And passing lots of variables gets
> to be both tedious and error-prone.
> 
> Another way to look at OOP is that you want to keep all the data
> pertaining to specific things together.  I always find that once my API
> for a function hits 3 or more parameters, maybe I'd better start
> thinking about objects instead.  If I mutter to myself something like,
> "I should push all this stuff onto an array, and simply pass the array
> into this function to simplify things.", that's usually my clue I need
> objects.
> 
> I think that does it for what are objects, and when to use them.  So,
> what about methods and attributes?  Methods are nothing more than
> functions.  Plain and simple.  The only difference between a "method"
> and a "function" is that a "method" has direct access to any given
> object's state without that state being explicitly passed into the
> method.  For example, say I wanted to add to numbers, I can do this in
> the traditional way:
> 
>     def add(a, b):
>         return a + b
> 
>>From outside the library, you would access this function like so:
> 
>   import foo
> 
>   answer = foo.add(4,3)
> 
> Or, maybe I have an object where one attribute is a base value with a
> new number being added to it:
> 
>     def add(self, b):
>         if not self.baseValue:
>            return b
>         return self.baseValue + b
> 
>>From outside the library, you would access this method like so:
> 
>      import foo
> 
>      bar = foo.foo()
>      answer = bar.add(4)
> 
> In the first example, I need to pass in both values.  In the second,
> I'mm assuming there's an existing value to which I'm adding and I have
> access to it through "introspection", i.e. I can access anything within
> a class using 'self'.
> 
> Also, with respect to the second example, I could write it so that
> rather than simply returning the value, I stored it in the object as an
> attribute of that object somewhere:
> 
>     def add(self, b):
>         if not self.baseValue:
>            self.baseValue = b
>         else: 
>            self.baseValue += b
>         return self.baseValue
> 
> And I could use this like so:
> 
>      import foo
> 
>      bar = foo.foo()
>      bar.add(4)
>      print bar.baseValue
> 
> Does this make sense ?  If this needs more explanation or I need to
> expand upon anything here, feel free to ask.  Also, asking these types
> of questions on the main GNHLUG list might be useful as well, since
> there are several very experienced programmers there who can provide
> lots of insight into different methodologies and practices.
> 
> I don't know of any decent books which provide a basic understanding of
> OOP. One decent document, though perl-oriented is the perltoot man page
> ( perldoc perltoot, or man perltoot) which is a pretty decent
> intro-level explanation of OOP.
> 
> --
> Paul
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Python-talk mailing list
> Python-talk at dlslug.org
> http://dlslug.org/mailman/listinfo/python-talk

Here's one book that might be useful for understanding Object Oriented 
Programming:

http://www.amazon.com/Object-Oriented-Thought-Process-Developers-Library/dp/0672330164/ref=sr_1_1?ie=UTF8&s=books&qid=1249921818&sr=8-1

The book uses Java for most of it's examples but it should easily 
translate to other programming languages.

My own impression of the usefulness of OO tools is that they are mostly 
used in user/application space. In OS programming OO tools are not 
usually used at the kernel level. The reasons I have heard for this is 
that since an OS kernel is usually memory resident the programmer can't 
use a garbage collection mechanism (all memory allocation/deallocation 
is explicit) and the loading/unloading of objects is not an option.

-Alex

P.S. I did hear a talk on message passing kernels where the presenter 
said that a micro-kernel was built using C++ but then went on to say 
that most of the object support had been removed for performance or 
other reasons.