Re: [Tutor] Subclassing vs. stand alone functions
Thanks again, this is exactly the kind of info I need to make the jump from procedural to OO design. I bookmarked your site for reference. On Saturday, June 16, 2007, at 09:30AM, "Kent Johnson" <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] wrote: >> Hi there, >> >> 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? > >> Let's say you want to load a dictionary. Do I create a function that >> accepts some argument (say a file name) and returns a dictionary, or >> do I subclass dict and override the __init__ and __setitem__ >> functions to make 'self-loading' dictionary? It seems the end result >> is the same. > >I tend to reserve OOP for the cases where it provides a clear benefit >and use a procedural style otherwise. So in this case I would make a >separate factory function to load the dictionary because it is simpler. >Also you are not changing the behaviour of your new dict so overriding >seems unnecessary. (BTW Why would you override __setitem__?) > >There are many cases where OOP has a clear benefit in simper code, >encapsulation or reusability. There are times when you have to use OOP, >for example when using a library that is specialized by subclassing, >such as a GUI library or the cmd package. > >There are also many cases where OOP just adds unneeded complication to >your code; in these cases Python lets you write in the simpler >procedural style. > >I have written more on this topic here: >http://personalpages.tds.net/~kent37/stories/00014.html > >Kent > > ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Subclassing vs. stand alone functions
[EMAIL PROTECTED] wrote: > Hi there, > > 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? > Let's say you want to load a dictionary. Do I create a function that > accepts some argument (say a file name) and returns a dictionary, or > do I subclass dict and override the __init__ and __setitem__ > functions to make 'self-loading' dictionary? It seems the end result > is the same. I tend to reserve OOP for the cases where it provides a clear benefit and use a procedural style otherwise. So in this case I would make a separate factory function to load the dictionary because it is simpler. Also you are not changing the behaviour of your new dict so overriding seems unnecessary. (BTW Why would you override __setitem__?) There are many cases where OOP has a clear benefit in simper code, encapsulation or reusability. There are times when you have to use OOP, for example when using a library that is specialized by subclassing, such as a GUI library or the cmd package. There are also many cases where OOP just adds unneeded complication to your code; in these cases Python lets you write in the simpler procedural style. I have written more on this topic here: http://personalpages.tds.net/~kent37/stories/00014.html Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Subclassing vs. stand alone functions
<[EMAIL PROTECTED]> wrote >>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. Thats probably one of the hardest places to learn OOP from. COBOL, more than any other language I've used forces programmers to separate data and function explicitly. It then compounds matters by encouraging the use of global variables (within modules at least). Of course COBOL is peerless in tackling exactly those problems where OOP is weakest - large volume data translation. But its a big jump from thinking in COBOL to thinking in OOP. I had to make the transition in the opposite direction and it was "challenging" Of course there is COBOL WITH OBJECTS now but I've no idea how that works. And with rigid discipline you can build with very small modules comprising precisely one data structure and the functions that operate on that but its not conventional COBOL practice. So I sympathise, but urge you to hang in there the penny will start to drop, especially if you try to create some projects that suit OOP - like building a few GUIs or simulations. Regards, Alan G. (2 years with MicroFocus COBOL on OS/360 for Y2K ;-) ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Subclassing vs. stand alone functions
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
Re: [Tutor] Subclassing vs. stand alone functions
<[EMAIL PROTECTED]> wrote > 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.) 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. Now to your examples: > Let's say you want to load a dictionary. Why would anyone ever want to load a dictionary? 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? Or do you mean you don;t subclass anything in defining it? Or do you mean you only create a single instance? > 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? 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. > (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 ju
Re: [Tutor] Subclassing vs. stand alone functions
[EMAIL PROTECTED] wrote:
>
> Let's say you want to load a dictionary. Do I create a function that
> accepts some argument (say a file name) and returns a dictionary, or
> do I subclass dict and override the __init__ and __setitem__
> functions to make 'self-loading' dictionary? It seems the end result
> is the same.
I am not understanding, what you mean by "loading" a dictionary or a
value in python.
You mean creating a custom dictionary? Then,
a) obj = Dict(list_of_tuples)
b) obj = mydict{}
c) def fun():
# process it and store in dict.
return mydict
These are are various ways.
Now, the question is when do you subclass?
Only when you want to extend the behaviour of particular class.
For e.g, you want to extend the Exception class to define your own
Exception, then you will subclass it.
Class MyException(Exception):
def __init__(self):
pass
def __str__(self):
return "My Exception, Hurray!"
The same, can applied to dictionary, say you want extend the behaviour
of dictionary with a get a random key-value pair.
Next is, what if you want different instances of a class.
Well, those are the Objects.
In the class you define a property which can be variable and set those
property values when you create the objects from that Class.
> Do you subclass WebPage for each
> particular page you want (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
Objects.
> (I can send code samples if it will help).
Sure, please do. I might not check the email on sat/sun. But others here
are ofcourse very helpful.
I hope my explaination help u a bit.
Thanks,
--
Senthil
Your own mileage may vary.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Subclassing vs. stand alone functions
Hi, Basically you write a (sub)class when you want to preserve state information of your instance. If the functionality in question lives longer then the scope of the function, and will be called from different methods to obtain the same information and state of the functionality at that time, it is a candidate for a class. Whenever the class lives very short, and there is no chance that seperate threads might screw up the state of the functionality, it is usually sufficient to keep it inside a module. My 2ct, - Jorgen On 6/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi there, > > 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? > > Let's say you want to load a dictionary. Do I create a function that accepts > some argument (say a file name) and returns a dictionary, or do I subclass > dict and override the __init__ and __setitem__ functions to make > 'self-loading' dictionary? It seems the end result is the same. > > Here is a follow-up if you will indulge me... > > I created a class called WebPage which is a stand-alone class (I get that). > 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). Do you subclass WebPage for each particular page you want (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? > Again, the end result is the same. > > (I can send code samples if it will help). > > Thanks, > > Chris > ___ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
