"Michael Langford" <[EMAIL PROTECTED]> wrote > I'm firmly with Kent here: OO programming is not about simulation.
Wooah! I'm partly on board here and do agree the noun/verb thing is a gross simplification. But it does work and is how probably the majority of OOP programmers started out - in the 80's and 90's at least. Certainly when I started on OOP around 1984 it was the de-facto introduction. And it is a still an effective way to identify objects if you aren't sure where to start. But it is not a good way to model software, with that I agree. But OOP is still about suimulation. A lot of OOP code - especially on very large scale projects is as close a simulation as possible to the real world problem as you can get. If you are going to work on 5-10 million lines of code you had better organise it according to some tangible model you can understand or you will have problems. Performance and efficiency come a long way behind comprehensibility at that scale. But on more "normal" projects, say 100K-1 million lines then other factors come to the fore, and flexibility of design is one big area where OOP techniques can help. <RANT> Unfortunately there seeems to be a lobby at work in OO these days (indeed in software engineering generally) that has forgotten about large scale stuff and treats the entire subject as if it were exclusively about small scale projects. This is unfortunate because software engineering was "invented" to tackle the large scale problems not the small, and this view also fails to recognise the very different approaches needed to cover both bases. Here in the Python community we rarely need to think big, I don't know of any really large projects being done in Python. But it is important to remember that topics like OOP cover all areas. </RANT> > are not modeling real world items. You are making code easier to > maintain and making parts of code that have to do with one another > be > near one another. That's true of any design technique regardless of whether it is OOP or procedural or even of it's not software at all. However it's not somerthing that will help a beginner see objects in their code, especially since the resultant objects are often of the highly abstract or large grained variety. > If you spend all your time trying to make your objects into real > world > things you're actually doing simulation, not programming. As a > person > who's actually done simulation, I'll state that 's not really a > great > way to structure code. You spend a lot of time arguing about highly > abstract responsibilities of each object in your system, as well as > how much it will actually model the real world. Neither one is > especially helpful, This bit I do agree with. Model the real world to get a feel for the problem at hand, model the real world as an aid to identifying potential objects, model the real world while it helps solve the problem. But don't be a slave to it, you are writing a program to solve a problem not to model the world. Never forget which is the tool and which the result. But OTOH most of the programs I build or design are simulations, whether of a call centre, a manufacturing plant, a banking system or a local council, an airport traffic control system or a telephone switch - and the software invariably reflects that structure. It does not however model every feature of a PBX, lathe, teller etc It reflects the attributes of those objects that relate to the problem. > programing. The Why of OO programming today is: To make code more > maintainable/usable and to group and to use data in such a way the > human mind can easily grasp all the abstract data types that a > program > operates on. And the latter point is one area where modelling based on real world entities can be a big plus. But based on them, not slavishly reproducing them. > OO programing came from simulation people. They used a language > (Simula) to do simulation. It allowed each object to have behavior > linked to its type. And it is still used today within the simulation community. We have a fairly active Simula group at work doingnetwork analyses. > Other people saw this (Smalltalk), then copied the system (which > they > were incidentally using to build Smalltalk at first), but not to > simulate real world objects, Quite a lot of the early Smalltalk stuff did indeed copy real world objects but they also saw the potential in modelling virtual objects like the UI elements. They were using Smalltalk to teach/experiment with young children by that time and the correspondence between real objects - like pens - and computing devices was a beneficial side effect. > When Bjarne Stroustrup made C++, he copied some of the ideas in > order > to make a better type system, where the functions that operated on a Yes, although he was actually using the tool to build a simulation. That's why he started with Simula... > "Object-oriented programming is programming using inheritance. <Nit Pick> I never agreed with Bjarne on that. There are a number of OOP environmemnts that implement polymorphism without inheritance (Actor is one example). So I think he should have said that "OOP is about programming polymorphically" </nit pick> > OO is not a glorified simulation system, and you will feel pain if > you > overemphasize the generalization "Model objects on real world > objects". Objects do have to have an idea (Cohesion). It is just, > that > idea doesn't have to be congruous with something you can walk over > to > and pick up in the real world. And this is the key. Objects have responsibilities. The responsibilities should be related to some kind of conceptual thing, but it may not be a real world thing. But when you start out with objects it's nearly impossible to imagine non tangible things. And that takes us back to nouns/verbs. For all its imperfections it works as a way of gettig people to break down problems into things rather than functions. The resultant software may well be sub-optimal but that can be fixed, but if you can build something that works and is based on objects that is the starting point. Once you build a few you very quickly run into the analysis-paralysis issues of trying to follow the real world too far, and start to deviate., That's when you start to find the abstractions coming out and seeing objects more generally. But that's a huge jump for most procedural programmers. > Often it feels like the "Model objects on real world objects" is how > people are taught so they get the idea of an object. Actually > designing all code that way is a needless proscription that really > really hurts many projects. I agree with this too. It has to be emphasised that it's only a starting point to identify object candidates, the final solution may look very different. But in my experience the bigger the project the closer the abstractions get to reality at least at the object identity level - the operations and data are likely to be very different, and underneath that layer will be a wealth of lower level abstractions unguessed at by nouns/verbs. But heh, if you get presented with a requirements spec of 400 pages and over 1000 user storiers (as I just have!) it's as good a place to start as any! (IMHO of course! :-) And hopefully no newbies on the tutor list is in any danger of that happening to them! -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld Which is currently dead awaiting a server repair, sorry! :-( _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor