real worldSeems like "the real world" just means The World.When we mean something different from The World maybe we could say so rather than adding "real" to the ordinary usage.

We could even "use the word situation... rather than world to emphasise that we are considering purposeful systems situated in a context rather than trying to describe all of some supposedly objective reality." p10Designing Object Systems, Steve Cook & John Daniels

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 "loan" is a concept - what's the problem?Are concepts somehow not part of the world?

In general, it seems that things exist in the real world, but are not in collections

Flock of sheep,stack of paper,array of programmers?

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

That is to say - you find yourself using a programming language object to represent a domain process. (In a concurrency-oriented-language like Erlang, you might find yourself using a programming language process to represent a domain object.)

> 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 starting point for One-Click is the pre-existing notion of the Web Page, and the ergonomics of on-line ordering. A BankLoan class, as you point out, starts from the existing business processes, legal rules, and artifacts created when a customer asks a bank for a loan. In both cases, the term "abstraction" still applies in that the programmer starts with a whole group of facts, desires, and constraints, and distills them into software. If software were pure invention, without reference to anything outside the programmer's mind or software text, it would be useless.

Yes, the BankLoan class bears little resemblance to the existing documents and paper-shuffling procedures, and a programmer must use a great deal of creativity to write it. Nevertheless, that programmer must also abstract from a plethora of existing or envisioned legal and business requirements in order to create that chunk of software.

One-Click is a trickier situation, since on the surface it's, well, one click to buy an item. Still, Amazon had to make sure that one click could technically and legally execute all the business processes required to execute an order. In that case, some programmer had to analyze the processes required and abstract the data and workflow required from an order

Perhaps my choice of initial analogies was confusing. In my mind -- if no one else's -- abstraction is the process of disentangling the useful and relevant parts of a physical object, man-made set of constraints, or underlying metaphor from the inessential or accidental parts.

Perhaps the real problem isn't the term "modelling", but the definition of the "real world" as exclusively tangible, physical, external things. Or perhaps its the assumption that there's a one-to-one mapping from the model to the real thing, between some assumed set of things to software objects. Just as a model airplane excludes some features of a real airplane, it also includes some things a real airplane wouldn't (like a giant rubber band).

I didn't say they there are not groupings of things, but there are no collection objects in the real world.

Flock is a good example. What sort of collection is a flock? This would be a somewhat amorphous collection that has no particular order and may or may not contain things it did just a moments ago. Of course, this can all be modeled and probably things like this are in a lot of different game software.

By the way, on the "real world" nomenclature, I think the adjective "real" helps to differentiate from the "software" world. Of course, everything you create in software also exists in the "real world" -- this is another thing that makes modeling the universe: to be complete, the model has to contain a model of itself, and onward in.

> I didn't say they there are not groupings of things, but> there are no collection objects in the real world.

Egg-carton.

Regardless, I think the "real world" is a rich source of ideas, but when I borrow it isn't because I'm modeling the real world. A good example is JINI. Someone (I don't know who) thought "okay, we have services and other services are going to need them. It would be nice if they could just assume they are there, but for how long? What if a service needs to go down?" They ended up with the idea of a "lease" for services.. not because it is "part of the domain" but rather because -that- problem, the problem they were confronting, was already solved someplace else. People use leases for property, why not use them in software?

When you look around, there aren't many new problems. The behavior we need in software often exists someplace else: in human relationships, in hardware, etc. We just have to adapt it, and I guess patent it for software if recent history is any guide.

> 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 "loan" is a concept - what's the problem?> Are concepts somehow not part of the world?

Of course they are, but they are also very different from physical objects. If you have read some of the OO literature you will have noticed that the authors tend to use physical objects in their examples and sometimes even natural physical objects. And that's exactly because the prototypical process of abstraction, selecting from the indisputable set of features that you can observe, works very well for physical objects. It doesn't work as well with other things like laws for example.

> The starting point for One-Click is the pre-existing> notion of the Web Page, and the ergonomics of on-line> ordering. A BankLoan class, as you point out, starts from> the existing business processes, legal rules, and> artifacts created when a customer asks a bank for a loan.> In both cases, the term "abstraction" still applies in> n that the programmer starts with a whole group of facts,> desires, and constraints, and distills them into software.> If software were pure invention, without reference to> o anything outside the programmer's mind or software text,> it would be useless.> > Yes, the BankLoan class bears little resemblance to the> existing documents and paper-shuffling procedures, and a> programmer must use a great deal of creativity to write> it. Nevertheless, that programmer must also abstract from> a plethora of existing or envisioned legal and business> requirements in order to create that chunk of software.> > One-Click is a trickier situation, since on the surface> it's, well, one click to buy an item. Still, Amazon had> to make sure that one click could technically and legally> execute all the business processes required to execute an> order. In that case, some programmer had to analyze the> processes required and abstract the data and workflow> required from an order > > Perhaps my choice of initial analogies was confusing. In> my mind -- if no one else's -- abstraction is the process> of disentangling the useful and relevant parts of a> physical object, man-made set of constraints, or> underlying metaphor from the inessential or accidental> parts.> > Perhaps the real problem isn't the term "modelling", but> the definition of the "real world" as exclusively> tangible, physical, external things. Or perhaps its the> assumption that there's a one-to-one mapping from the> model to the real thing, between some assumed set of> things to software objects. Just as a model airplane> excludes some features of a real airplane, it also> includes some things a real airplane wouldn't (like a> giant rubber band).

I completely agree that there is always a process of abstraction in your sense of selecting, disentangling, accounting for constraints and so on. And this is also true to some degree for non-physical objects. But, I think, this doesn't cover the normative aspects, where we say how it _should_ be. A law maker, for example, doesn't model the real world, he makes new rules that apply to the real world and that then constitute part of the real world. The laws are of course formulated in terms of abstractions of things that exist but they also create something new that wasn't there before and that doesn't have to be modelled upon anything.

I think this difference between analytic understanding of something that exists and the formulation of rules to express how things should be, is a fundamental logical idea that seems to be neglected in the phrase "modelling the real world".

What I meant is that I've not seen any ArrayLists, Vectors or (especially) HashTables in the wild. Even when writing an egg management application, you will probably not use an EggCarton class; you'd probably just use an array.

I'm not saying this is good or bad, I just remember the difficulty I had when I first started with OOP, trying to decide to what extent software should or shouldn't try to model reality.

In fact, in my first "OOP C++" class, we were to write a program to play a dice game. The instructor proceeded to write a "Dice" class that had two ints which could have values from 1 to 6 and so on. I was already confused. Shouldn't there be a "Die" class and shouldn't we create as many instances of those as we need?

Revisiting the original blog for this thread, it looks like Robert is complaining more about how programmers market OOP to management, then how it may actually be used.

If you have read some of the OO literature you will have noticed that the authors tend to use physical objects in their examples and sometimes even natural physical objects.The literature ranges from excellent to mediocre.

It's no surprise that physical objects are used in examples - most people find them easier to think about than abstractions.

It doesn't work as well with other things like laws for exampleWhy not? Where does it fail?

> It's no surprise that physical objects are used in> examples - most people find them easier to think about> than abstractions.> > It doesn't work as well with other things like laws for> example> Why not? Where does it fail?

Because when you build a piece of software that models or simulates a physical object, you don't change or even create that physical object. When you sit down with a bank manager and talk about some new financial product, and then you go and build your software, the result might be something that just wasn't there before. It's not the model of something else, it is itself the real thing. That's fundamentally different and it's the very reason why social sciences and natural sciences have very different methods of research. I tend to see computer science more on the side of social science than on the side of natural science. At least the software development area.

> 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.

You want to give Kristen Nygaard a sound trashing? You must be having a bad day. Your "parody" is over the top and unfair.

(For those of you with a weak grounding in history, Kristen Nygaard and Ole-Johan Dahl invented Simula67 and are generally credited with inventing/discovering object-oriented programming. The (posthumously) received the Turing award last year for that). They - like most followers of the so called Scandinavian school of OO - were quite fond of applying the "modeling the real world" methaphore and quite skilled at avoiding its more vulgar variants.)

> (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.

Who brought up "solely"? "Religious OO" is dangerous as is "Religious X" for most values of X.

> Who brought up "solely"? "Religious OO" is dangerous as is> "Religious X" for most values of X.

This whole diatribe was instigated by a post on comp.object where some poor guy asked whether it's ok to put validation methods in an object. He was told by the "architects" at his workplace that since the real world objects don't validate themselves the software objects shouldn't either.

I see so much of this kind of thing in my consulting travels that I have learned to cringe at the mention of "model the real world."

It is *that* view, and not Nygaard's, whose creator I would like to find and thrash.

The problem here isn't whether or not they are trying to model the real world.

The problem is that this silly assertion is begging the question. So, the person who said this is simply making a flimsy argument on this particular point and using the fact that they are trying to "model the real world" as a weak excuse for it. Who says real world object don't validate themselves? What proof do they have of that?

What this person really should have said was "I prefer software objects that don't validate themselves." That would be more honest. Clearly this person doesn't care much about validity, even with respect to his/her arguments.

> > 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.

I think wrapping processes in objects is a very good thing. I tend to think that's what SOA is about. A service oriented object models a process, not data. Data may be passed in and out of the object as plain old structures or as more generalized bit buckets like a map or XML document.

An application that displays stock quotes may not have any notion of a 'stock quote' object but may implement a stock quote service object. The stock quote service object isn't a quote, it is how to get quotes.