[Tutor] Subclassing vs. stand alone functions

[chrispython at mac.com]

I am new to Python and trying to get my head around 
the OO stuff. I guess my question is - when do you go 
with subclassing vs. making a standalone function? 

OK, I'll take a slightly different approach than the other 
answers so far.

First: procedural and OO styles of programming are diffrent 
ways of thinking about a problem. Any programming problem 
can be solved using either approach and both approaches 
are equally good, neither is intrinsically "better" than the other.

Second: Some problems are more amenable to an OO
aproach than a procedural and vice versa. And the majority 
can be done either way with very little to choose between 
them.

I will now assume that you understand the procedural way 
and already know how to apply good procedural design, 
including modularity featuring loose coupling and tight 
cohesion. In addition data structure design and its relationship 
to your procedural design should be a concept familiar to you.
( In a perfect world you'll also be familiar with the princuiples of 
functional programming and the lambda calculus, but that's 
possibly asking too much.)

>Not sure about the lambda calculus, but I have been doing procedural programming 
>for about 10 years. (I try my best for  modularity and all that good stuff :)
>That leaves the question of why and wjen should we use OOP?

OOP suits programs that feature a high level of correspondence 
between the "real world" and the software modfel we are building.
For example simulation software (including many games) usually 
involves the representation and control of a number of objects. 
It is a natural link to model these objects as classes and create 
corresponding objects in our solution. Similarly GUIs are made 
up of windows, widgets, etc. Again these have a fairtly clear 
translation into objects.

When we get into problems primarily of algorithms, or of 
transforms to fixed data then an OOP style is not always such 
an obvious fit. Similarly when modelling complex state 
machines the applicability of OOP can be less obvious and 
a traditional table driven procedural style may seem better suited.

In those cases the decision to use OOP is likely to be driven 
by the desire to create a reusable component. Something that 
can be utilised across multiple projects. or it may be driven by 
the desire to abstract away a complex process or data structure.
Hiding it behind a simplere API.  This can be done using 
traditional approaches but usually only at the cost od writing 
an awful lot of code or by exposing the data structure at least 
for initialisation purposes.

>Thanks, this is just what I needed! A way to think about which to use.

Now to your examples:

Let's say you want to load a dictionary. 

Why would anyone ever want to load a dictionary?

>I just want to create dictionary with some data in it. The data
>comes from a file, let's say. I would then go on to do something with
>the dictionary - like use it as input to another function. (Sorry, I am thinking
>procedurally, or are dictionaries typically populated for you by 
>the functions you call... maybe it's just a bad example.

What is the higher level goal you are trying to achieve?
Is the dictionary part of the solution or the problem?
If it is part of the problem a dictionary object may be appropriate. 
If its part of the solution, and you are already using a non 
OOP approach why would you want an object? Unless its 
for the reasons above - reuse or abstraction that is hard using 
procedures. But you should very rarely be making decisions
at this level unless you have alrwady decided on amn overall 
approach and you are considering an exception to the overall 
style. ie Should I create a function in an OOP design or should 
I create a class in a procedural design. (Mixing styles is OK 
but will normally involve some compromises)

Do I create a function that accepts some argument 
or do I subclass dict and override 
It seems the end result is the same.

Quite so and the andswer will depend on what you are 
trying to achieve. There is no definitive right answer.

I created a class called WebPage which is a stand-alone 
class (I get that). 

Sorry, I don't get it! :-).
Do you mean you only have a class and never create any instances?
>No.
Or do you mean you don;t subclass anything in defining it?
>Yes.
Or do you mean you only create a single instance?
>You could have multiple instances. 

It loads a web page template, and has a function to update 
the replacement vars with your data (updHtmlVar), and another 
to spit out the html to a file (wrtHtml). 

The data that this page holds is an html template.
Does it also hold the data displayed by the html? 
in 
which case its not updating with 'your' data but with 
*its own* data. But it may allow you to pass some data 
to it. Or is it that it renders the html only when given 
some data? Which it doesn't store?
>It stores the data and the template. When it is instantiated, 
>you just have the template and the variables. You would then
>go through the variables and assign values to them. When you call the
>wrtHTML method, it marries the data with the template and writes out the
>HTML to a file. (Not too practical, but it's just for my own learning...)


The issue of what data a class is responsible for is key 
to its design. If the WebPage ownds the data then all access 
to that data should be via the webPage. If the WebPage accesses 
the data then it needs an interface to the supplying object. 

Do you subclass WebPage for each particular page 
you want 

Almost certainly not. You should have different instances.
But you might have different *kinds* of page (Frame, CSS, 
Table, Dynamic, Static etc) and those could be subclasses.

>That's what I was thinking - you could have different kinds of pages.
(because you can customize it with load functions for 
each piece of data) or do you just use it as is, and create 
separate functions outside the class that load the data 
and you just use updHtmlVar to load it into your 
WebPage object? 

Hopefully you have a set of objects that manage your data 
and each web page has a set of supplier objects that it can 
query as needed when asked to render its html. Thus you 
register a supplier with the page and each time the page is 
asked for its html it will query the supplier objecs for the 
data it needs. (This may imply that you have a DataSupplier 
class and a set of subclasses per type with a comon interface.)
>That's where I am trying to get to. You would instantiate a WebPage
>with a template and each data element would have some kind of handler
>that fills itself with the right data. 

Or it may mean that the web page stores the type of the 
supplier and knows how to interface with each...  There is 
also a likely need for a correspoindence between the html 
template and the dta to be displayed, either that ort the 
template needs tom provide a set of defaults for the case when 
the suppliers data is insufficient for the templates needs.
But as ever it is the designers choice...

Again, the end result is the same.

Agreed, the choice of OOP or procedural is not about the 
end result it's about which approach suits the problem to 
be solved (and possibly the future reuse criteria).

>I don't want to use OOP just for the sake of using it, but I also don't want
>to dismiss it outright just because I am not familiar with it.

>Just so you know, my day gig is maintaining a 30 year old COBOL app and 
>writing custom RPGLE  - http://en.wikipedia.org/wiki/RPGLE - on an IBM i5. 
>So that's where I am coming from. 

>I'm having a lot of fun learning something new with Python.


HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld

>Thanks for the quick response and help.