Summary
The concept of modeling the real world has been so badly abused in the OO community, that I want to find the person who first coined the notion and flay him alive. (not really.)
Advertisement
I don't know who came up with "Objects should model the real world." but we need to find the guy and trash him soundly. I think it must have been some poor schmuck who was trying to sell his boss on buying an early C++ compiler. (In the mid '80s you could spend as much as $30,000 for a good compiler.) I imagine the dialog going something like this:
Schmuck: Sir, we need to buy a C++ compiler.
Boss: How much will it cost?
Schmuck: It's $30,000.
Boss: NO. That's too much money.
Schmuck: But sir, the benefits!
Boss: What benefits?
Schmuck: We'll be able to better manage dependencies!
Boss: Manage them without it.
Schmuck: But our code could be more flexible and robust.
Boss: Make it flexible and robust without it.
Schmuck: But... er.... uh....
Boss: Time is money schmuck, get to the point.
Schmuck: ...Our software will be more like a ... uh ...
model of the ... uh ... real world!
Boss: Hmmmm. Software that looks like a model of the
real world eh?
Schmuck: Yes sir.
Boss: Would it be easier to understand then?
Schmuck: Yes sir.
Boss: Will it allow junior developers to program like
experienced developers?
(Aside to audience) If this is true, I'll be able to
fire all these expensive software geeks and hire
kids right out of school!
Schmuck: Well, sir, that's possible, yes. Our software
would be much easier to understand since it would
have a much better structure and have it's...
Boss: (Eyes glaze over, foot taps.)
Schmuck: (continuing)...dependencies so well managed. Yes sir.
Boss: OK, Schmuck, you've sold me. Go buy that compiler.
But I want to see models of the real world in our
software within three months or your ass will be
grass.
It's true that we want the vocabulary and relationships of the problem domain represented in our objects and methods. But that's not the same as "modeling the real world".
OO was "discovered" when two guys who were using a block structured language to write a simulation engine played around with moving the stack frame for a block to the heap, thus making the blocks long-lived. Voila: objects! From this very geeky beginning, OO has grown to be a
<fanfare>
Major Methodology
</fanfare>
requiring
<fanfare>
Management Support and Approval
</fanfare>
and
<twenty-one-gun-salute>
Object Modelers and Architects
</twenty-one-gun-salute>
------>Aside. You'll probably enjoy reading Eric Evan's book "Domain Driven Design". He takes a very pragmatic view of the "real world modeling" issue, and provides lots of very good advice about it.
<------
(Sigh) the hype associated with OO, and the religious zeal with which it can be (badly) practiced is sometimes disheartening. OO is a very nice tool for structuring source code and managing dependencies. And, yes, it is a good idea (as it has always been) to incorporate the vocabulary and relationships of the problem domain into the design of the source code. However, when people make software related decisions based solely upon whether or not the object properly models the real world, they need to find some other career -- because they sure aren't software developers.
In the simulation world, its called "Real Time Programming" and the code is referred to as modeling of "First Principles".
If its physics which is basically "real world" math, I think it fits. Much of physics is modeling of physical processes. Maybe I should change that to abstract world math.
Hey, its spelled "modeling" according to Microsoft Word? I honestly can't tell which one is right. I keep trying to spell it with two lls.
It's true that we want the vocabulary and relationships of the problem domain represented in our objects and methods. But that's not the same as "modeling the real world".
What in your view is the difference between encoding those relationships and modelling the problem domain?
OO was "discovered" when two guys who were using a block structured language to write a simulation engine played around with moving the stack frame for a block to the heap, thus making the blocks long-lived.
Those two guys being Ole-Johan Dahl & Kristen Nygaard.
Kristen Nygaard, in his ECOOP 2002 Banquet Speech, seems to be saying that OOP is about understanding, describing and representing a system (domain) on a computer. Isn't that modelling?
"In object-oriented programming the programs are not organised in a single sequence. Instead, an object is created for each individual component of the traffic system, the production system, the organisation system: Cars, aircraft, machines, operators, metal parts to be processed, offices, documents all are represented in the computer as objects.
Each object is described by 1) the set of data associated with it: Speeds of aircraft, weight of metal parts, addresses of documents, etc.,2) then the descriptions of actions the object is carrying out: traffic lights changing colour in a well-defined sequence, machines working on metal parts selected from a queue, and 3 finally also the interactions with other objects: a controller's office inspecting invoices and sending messages about payment authorising to the appropriate other offices, and so on.
In this way a system, including information systems, may be understood, described and represented by a collection of objects in a computer, each object acting and/or is acted upon through the carrying out of the parallel object-related computing sequences."
> What in your view is the difference between encoding those > relationships and modelling the problem domain?
The point of the article, in case you missed it, was the last sentence.
I don't think there's any difference between the two concepts. However, I think much harm has been done in the name of building models. Building models is not a bad thing. Building models instead of software is. Ignoring good software structure for the sake of building a model is.
The point of the article, in case you missed it, was the last sentence Sometimes I do have difficult finding the point of an article amid the rhetoric :-(
I don't think there's any difference between the two concepts So "we want the vocabulary and relationships of the problem domain represented in our objects and methods" and that is the same as "modeling the real world". Well OK.
Building models is not a bad thing. Building models instead of software is. Ignoring good software structure for the sake of building a model is Ignoring model validity would be worse - the beautifully structured software wouldn't do the right thing. Or to rephrase the point - when people make software related decisions based solely upon whether or not the software has good structure...
I have a different take on how we got here. I fell the real world thing "hook, line and sinker" in the early days and it seemed to me that the idea was really popularized by the people with database and AI backgrounds. I suspect that many of them thought "hey, these OO languages look like they allow programmers to do what we do with ER diagrams and domain ontologies." I know some pressure came from that direction. No doubt it was a confluence of many things.
It is hard to get this concept across to new programmers, that we aren't modeling the real world but we use vocabulary from the world. One good example is a payroll application. In one factoring, it makes sense that an Employee class calculates the employee's pay. In software, it can be a good place for that responsibility even though it might be hard to find a real world company where all employees calculate their own pay. ;-)
My problem with the "modelling the real world" phrase has always been that, more often than not, creating software feels like _creating_ a world that wasn't there before. In contrast, simulation is all about making a machine do what some existing system already does or would do under certain conditions.
In most analysis sessions I had with clients or colleagues, we were thinking more about how things should be than how they actually were. Of course, there are always existing facts and concepts you have to deal with, but it'd be wrong to look at software development as a process of discovering the nature of "real" things.
I would be much more comfortable with "modelling _a_ real world".
Modeling the world is for wimps. In the late 80's, in addition to my day job, I took a night job at a company that made a grandiose Computer Aided Engineering application ("the largest Smalltalk application in existence"). Needing a significant engineering problem to put this application through its paces, a couple of us decided to model the entire universe. Of course, we didn't get too far, when talks broke down on whether the basemost object should be object or string.
> My problem with the "modelling the real world" phrase has > always been that, more often than not, creating software > feels like _creating_ a world that wasn't there before. In > contrast, simulation is all about making a machine do what > some existing system already does or would do under > certain conditions.
A lot of software written today uses the real world as metaphor for fundamentally computer-centric processes (word-processing, message routing, etc.). The "models", if any, are simple caricatures of the real world. Among younger programmers, OO is a thing unto itself; "modeling the real world" has given way to hacking out "an object" to wrap this or that functionality. PHB take the modelling metaphor too literally, but in a strange way, it's as much a shame that so programmers ignore the "modelling" metaphor completely.
I suspect too many people forget that a model is an *abstraction* of the real world. A styrofoam model plane can't fly or carry passengers, but it tells an engineer about the flight characteristics of the eventual real plane. A model of the solar system substitutes fixed rods and gears for gravity in a 3D space, but it can still predict -- within certain limits -- the motion of real planets.
Instead of "model(l)ing" the world" (old style) or hacking out objects (new style), successful analysts and designers first understand the problem, and concentrate on shaping the software into a toy that provides insight into a far more complex process. Objects and classes *sometimes* make toy-building easier, but not always.
> > My problem with the "modelling the real world" phrase > has > > always been that, more often than not, creating > software > > feels like _creating_ a world that wasn't there before. > In > > contrast, simulation is all about making a machine do > what > > some existing system already does or would do under > > certain conditions. > > I suspect too many people forget that a model is an > *abstraction* of the real world. A styrofoam model plane > can't fly or carry passengers, but it tells an engineer > about the flight characteristics of the eventual real > plane. A model of the solar system substitutes fixed rods > and gears for gravity in a 3D space, but it can still > predict -- within certain limits -- the motion of real > planets.
Your examples show precisely the problem I mean. You come up with examples from the physical world and for a good reason because for all other things, this whole notion of modelling or abstracting from the real world simply fails. What is the real world object that amazon's patented one-click order is modelled upon? What do we abstract from when we create a BankLoan class? The notion of abstraction as a process of selecting features of an object that are important in a particular context and leaving away other features that are not important, makes an implicit assumption that there _is_ an object with features in the first place and that these features can be discovered. But there are no natural BankLoan objects that we could look at and whose behaviour we could observe. Yes banks already have products called loans and we could look at them as an example for our class. But they are not modelled upon some original natural object, they are creations that reflect the bank's idea of what they can sell to their customers.
So when we create a new BankLoan class for a different bank, we do not search for a better abstraction of _the_ real natural BankLoan object. What we (or rather the bank managers) do is think about what a more attractive loan _should_ look like. We invent features, we don't discover or selct them. And that's what I think is not well represented in the phrase "modelling the real world".
> Modeling the world is for wimps. In the late 80's, in > addition to my day job, I took a night job at a company > that made a grandiose Computer Aided Engineering > application ("the largest Smalltalk application in > existence"). Needing a significant engineering problem to > put this application through its paces, a couple of us > decided to model the entire universe. Of course, > we didn't get too far, when talks broke down on whether > the basemost object should be object or > string.
Well, Aristotel failed at this task a rather longish time before the 80's and everyone should have known by then that single rooted, single inheritance taxonomies just don't work ;-)
> ...So when we create a new BankLoan class for a different > bank, we do not search for a better abstraction of _the_ > real natural BankLoan object. What we (or rather the bank > managers) do is think about what a more attractive loan > _should_ look like. We invent features, we don't discover > or selct them. And that's what I think is not well > represented in the phrase "modelling the real world".
Well put. Reminds me of feelings I had when I first began to learn OOP and C++. There are many cases where concepts get wrapped into objects for which there is no real world counterpart. Collections are a common example of this phenomenon. I've never seen a HashTable in real life (but then, I'm not a drug dealer!). In general, it seems that things exist in the real world, but are not in collections.
If you go to far in the OOP direction, you find yourself wrapping objects around things that are really not objects, but processes. Processes are just as common, if not more common, than things (objects) are in the real world.
Some languages, like Java and C#, require you to define a class (of objects) as the first act of creating a program. Depending upon your point of view, this can be good because it encourages OO-thinking from the outset (which is, of course, immediately circumvented by students who crank out one huge static main() function; see the Java Answers Forum at http://www.artima.com/forums/forum.jsp?forum=1 for examples), or bad, because it often forces you to create some artificial "application" class.
> If you go to far in the OOP direction, you find yourself > wrapping objects around things that are really not > objects, but processes. Processes are just > as common, if not more common, than things (objects) are > in the real world.
Which may not be bad. The Command pattern uses objects for processes, and that's fine.
Flat View: This topic has 31 replies
on 3 pages
[
123
|
»
]
Previous Topic
