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. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor