On 26/11/05, Alan Gauld <[EMAIL PROTECTED]> wrote: > >> point. Classes express behaviour, the data is only there to support > >> the behaviour. Thats why methods are polymorphic but not attributes. > > > >If classes express behaviour, then what expresses the structure of the > > data? > > Why do you care? If the program behaves as you expect it what does > it matter what data it uses or how. That should be hidden from you > inside the classes. Worrying about data is a feature of traditional > Information Modelling/Structured Analysis style programming, > OOP is all about inter-communicating objects sending messages to > each other, each requesting and providing services to the others.
I get this now. It goes back to what I said earlier about the "I don't care how it works" philosophy. Each object doesn't care how any other works. You could completely re-engineer the internals of an object and that would be fine as long as the interface is the same. As long as the methods and attributes keep returning sensible values then everything is fine. However, I'm still slightly uncomfortable with it. It smells to me a bit like the "as long as it works, its fine" school of thought. For my own sanity and peace of mind I like to have my data structures well defined, as at the end of the day it's the data that matters (I can rebuild functionality but data is given to me by other people and can rarely be gotten back). > > (ie what attributes there are going to be and what values they > > are likely to accept). > > You need to think about the objects that you pass around as part > of the messages, but those obnjects are in turn accessed via messages > so their structure is not important. What does matter is the > relationships between the objects, and they are related by message > paths not fixed data relationships. This switch in thinking is the > fundamental difference between traditional and OOP design. > > > You need (the option of) a data definition in order to generalise. > > No, you need the ability to modify behaviour. > Most traditional programmers think in terms of modifying > behaviour in terms of big if/elif trees > > if obj.type == sometype > doSomeTypeThing() > elif obj.type == another > doAnotherTypeTHing > etc... > > Whereas in OOP you simply say > > obj.doThing() > > And the right kind of doThing will happen because obj > knows how to respond to that message in the appropriate way. But writing a different doThing() for each object can be a huge waste of time. You want to be able to write one doThing() that is going to work on each object (of a particular type). This requires either knowing that all your objects are going to be similar in some respect, or writing a huge if..elseif as you mentioned. Even just saying every object has a doThing() is starting to create a data structure. > > Using my web server example from earlier, you need to be able to say > > that for any type of page, whatever it's attributes, you can create a > > web form to search for that type of page by iterating through it's > > attributes and creating a relevant form field for each type. > > So you want, for a given page to create a Form and search. > > But that's behaviour of the Page, just let it create its own form > and do its own searches, not your problem. Create the right > kind of Page and it will do the work for you... But then I've got to create lots of different behaviours instead of one simple generalised behaviour. > > I definitely had the opposite in mind. The behaviours of all the > > classes would be the same (and would be fairly simple, a method for > > rendering the page with a template, a method to update the data based > > on a form submission). > > Thats fair enough and the parent Page class would do just that, > but the template class would have methods that the Page called, > and you can subclass or data drive the templates to return the > appropriate strings to the page. (Since web pages after all are > just collections of strings - or evenone big string...) > > > Users would basically be able to change the > > data structure (add and remove attributes). > > So maybe attributes are objects too? Maybe you page needs > to know how to handle attributes and you can create pages by > adding attributes from a pick list, each attribute knowing how > to render itself and how to respond to searches? This combined with what Kent said, is what really solved the problem for me. > There are lots of ways to address this is we think of the world > in terms of intercommunicating objects not static data structures > with a few overeaching functions controlling it all. I've really gained a huge amount just from this one topic. Not least of which is that classes aren't necessarily a good answer to OOP problems. > > I'm sure Python is quite possibly the least worst at this, but that > > doesn't make it good at it. > > Which brings me back to my original question, what environment > do you think is good at it? Are you aware of such an environment > or merely wishing that such a thing could be invented? I know that such a thing could be invented. It's very straightforward, it's just a lot of work. If enough other people think that it would be useful then it will probably get done at some point (and I think the rise of web applications will bring it about as an inevitability). Ed _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor