Does Object Oriented Programming Really Model The Real World? [closed]

Question

I've seen it commonly repeated the object-oriented programming is based on modeling the real world but is it?

It seems to me that is not true of anything outside of the business layer. My GUI classes/data access classes aren't modeling anything in the real world. Even in my business layer, I've got classes like observers, managers, factories, etc. which aren't real world objects. I try to design my classes to take advantage of things like encapsulation but is the real world encapsulated?

While some objects I create are modeling real-world objects, would not pre-OOP code do the same? I doubt that OO was the first people to include concepts like Customer in their code bases. But OO is really about how to model things, and that method of modeling doesn't seem inspired by the real world to me.

So: does object-oriented programming really model the real world?

Answer 1

No, not at all.

However it's a methodology that does allow to create a nice abstraction to hold complex data structures along with some methods that act on the data structures.

Answer 2

Models, of any kind, do not model the real world, not entirely.

They model selected portions, those that are relevant to the application at hand.

What you are talking about (observers, managers, factories etc...) is infrastructure that is there to help you with getting the abstraction right and support required functions such as persistence.

Answer 3

What is a model, anyway:
A model is a simplified representation used to explain the workings of a real world system or event

Does object oriented programming allow you to model the real world?

Definitely YES

It is almost impossible to model the system to exactly match the real world.

Do I always have to model the software exactly after the real world?

NO

Having said that you can model everything doesn't mean you have to model everything. In fact, the essence of useful modeling is to present a simplified representation. How much simplification is sufficient to express the current business need, and what needs to be omitted, is a fine balance between using the technique successfully vs. getting lost with it or not using it at all.

There are of course entities that doesn't exists really, but only through the modeling we can actually conceptualize well.

Answer 4

I think teaching that there is a relationship between nouns and classes causes annoying bad habits to develop that have to be crushed later by an impatient architect or senior engineer.

What should be taught is that the classes model abstract objects, just like your brain does. You have an abstract concept of "car" in your head that doesn't map to any particular physical car, it's reusable, specific implementations of car can inherit from it. Your brain even meta-models concepts for you. You have a mental model of what thought is, what a concept is.

If we taught people to identify the models they're already generating in your head, they'd be a lot better prepared to build real software.

Answer 5

...The world is richer than what can be expressed with object-oriented syntax.

Consider a few common concepts that people universally use to understand and describe all systems – concepts that do not fit the object mold. The 'before/after' paradigm, as well that of 'cause/effect', and the notion of the 'state of the system' are amongst the most vivid examples. Indeed, the process of 'brewing coffee', or 'assembling a vehicle', or 'landing a rover on Mars' cannot be decomposed into simple objects. Yes, they are being treated that way in OO languages, but that's contrived and counter-intuitive. The sequence of the routine itself – what comes before what under what conditions based on what causality – simply has no meaningful representation in OO, because OO has no concept of sequencing, or state, or cause.

Processes are extremely common in the real world and in programming. Elaborate mechanisms have been devised over the years to handle transactions, workflow, orchestration, threads, protocols, and other inherently 'procedural' concepts. Those mechanisms breed complexity as they try to compensate for the inherent time-invariant deficiency in OO programming. Instead, the problem should be addressed at the root by allowing process-specific constructs, such as 'before/after', 'cause/effect', and, perhaps, 'system state' to be a core part of the language...

quote source: Victoria Livschitz, The Next Move in Programming

Answer 6

Yes, OO can often be used to model real world entities.

Even in my business layer I've got classes like observers, managers, factories, etc. which aren't real world objects.

Do not confuse object oriented development with design patterns. OO analysis and design is a means to approach programming maintainable code. Coupled with an OO language, programmers are given the power to create re-usable code through the pillars of OO: encapsulation, polymorphism, and inheritance.

To encapsulate an entity we can model that entity after its real world counterpart. For example, if we have a guitar then a guitar class encapsulates the behaviors and properties of a real world guitar. We can further abstract the guitar as, say, an IInventoryItem to take advantage of the potential for code re-use through polymorphism and inheritance.

On the other hand, we may find that a factory of guitars could assist us in maintening a set of different types of guitars. This isn't because of OO. Rather, a factory is a design pattern that has stood the test of time as a proven means of successfully creating maintenanble code for such a purpose. In other words, we programmers are often solving similar problems. So we came up with a common solution for solving them (don't reinvent the wheel).

That does not mean OO has to model the real world, nor that it is always the most optimal solution to do so. Simply, that as a rule of thumb “OO modeling the real world” makes perfect sense.

Answer 7

It depends on which real world you're talking about.

Jorge Luis Borges wrote a story "Tlön, Uqbar, Orbis Tertius", where one of the inhabitant peoples seem to perceive their real world quite differently:

[...] the people of the imaginary Tlön [...] hold an extreme form of Berkeleian idealism, denying the reality of the world. Their world is understood "not as a concurrence of objects in space, but as a heterogeneous series of independent acts." One of the imagined languages of Tlön lacks nouns. Its central units are "impersonal verbs qualified by monosyllabic suffixes or prefixes which have the force of adverbs." Borges lists a Tlönic equivalent of "The moon rose above the water": hlör u fang axaxaxas mlö, meaning literally "Upward behind the onstreaming it mooned". [...] In another language of Tlön, "the basic unit is not the verb, but the monosyllabic adjective," which, in combinations of two or more, are noun-forming: "moon" becomes "round airy-light on dark" or "pale-orange-of-the-sky.

(copied from the wikipedia artice about the book)

To me, the point is not so much that the world can be perceived differently than we do, which is kinda cliché, but that perception of the structure of reality itself depends on the language we speak, be it a natural or a programming language. The Tlönese might be very happy with Lisp, and might see Java (AKA The Kingdom Of Nouns) as very unnatural, whereas most terran programmers tend to favor object oriented over functional languages. I like both styles, since I think it is mainly a matter of perspective. Some problems are best attacked with functional, some others with object oriented programming techniques. A good programmer always looks at a difficult problem from different angles, before he attempts a solution. Or, as Alan Kay put it: Point of view is worth 80 IQ points.

So, my answer to your question is: Which real world are you talking about? And How?

Answer 8

While some objects I create are modelling real world objects, would not pre-OOP code do the same?

I would say not. OOP ties down the relationship between things (properties/objects) and what they can do/can be done to them (methods), whereas procedural programming doesn't do this (aside from, to a small degree, when using strict typing). A model isn't just about defining discrete parts and processes, it's also about defining how they fit together, and OOP is particularly good at this.

Answer 9

I've seen it commonly repeated the object oriented programming is based on modelling the real world, but is it?

Yes. The emphasis here is based on. OOP doesn't model the real world (if it does, then incidentally) and it is not supposed to. What OOP does is to allow us model programming problems the way we model the real world: as a system of entities that are defined through our abstraction of their behavior.

Answer 10

OO code doesn't usually model the real world--at least that's not the goal, it simply allows you to think about your code in a manner that is more natural, more like the way you think about things in the real world--this is what the quote is trying to say.

Answer 11

It does not model our world, but it does model the human interpretation of our world. Humans naturally separe things as objects. OO is effective because it allows humans to program the way they think.

Answer 12

OOP may not be a perfect model of the real world and the objects contained there in, but it is a methodology that helps deal with the increasing complexity of real life software. It also helps write code better, by breaking it down in to logically related chunks.

While older procedure oriented methods will certainly deliver results too, OOP helps you get there faster and with relative ease, even when dealing with large & complex projects.

Abstraction and Encapsulation help concentrate on the core of the problem while hiding all of the plumbing that actually makes stuff happen. Inheritance and lets you establish a meaningful and logical relationship between various aspects of your code. Polymorphism promotes code reuse and lets you easily handle variations (those "almost same behaviour as an existing object" category of problems that happens so frequently) and extend code by extending the semantics associated with an object.

I feel OOP is more like a proven aid that lets you deal with all of the complexities of a real life system in an effective manner. So, while it may not be a very thorough model of the real world, it is close enough and helps you get stuff done, which IMHO is all that matters in the end.

Answer 13

I've seen it commonly repeated the object oriented programming is based on modelling the real world, but is it?

It seems to me that is not true of anything outside of the business layer.

No. As you point out, many of the things "modeled" in an OOP language are abstract concepts like message queues and controllers and stacks.

Even in your business layer, you're still not modeling "the real world". Assume you have an employee class. Employees are also People, who are also Mammals, who are also Animals, who are also… (yawn) Employees have favorite colors, and they wear certain clothes and believe certain things. In short, there's a huge range of complexity in the real world that we don't even attempt to capture in most programs.

In modeling, we only focus on the aspects of the model that are meaningful to the task at hand. If we're designing a time entry system, then we probably want some sort of Employee class, but that class doesn't need a property to express the employee's favorite color.

Therefore, models shouldn't attempt (or pretend) to completely represent the "Real World".

While some objects I create are modelling real world objects, would not pre-OOP code do the same? I doubt that OO was the first people to include concepts like Customer in their code bases.

You are correct. If you look at large programs that are not OOP, they are often still organized around data structures. A data structure and all of the functions that manipulate are defined near each other, for clarity reasons. (The subversion project is a good example of this. Data structures and functions are prefixed with module names so that it's clear which structures and functions are intended for use with each other.)

I'm no expert on the history of programming languages, but I imagine that OOP grew out of the casual observation that code was clearer and easier to understand when it was organized this way, so language designers started designing languages where that type of organization was more strictly enforced.

The biggest difference between OOP and non-OOP is that OOP binds code to data. So rather than calling code like this:

verb(noun);

we do this instead:

noun->verb();

Although this may seem like a grammatical difference, the difference is actually in mindset. We tell objects what to do, and typically don't care what the internal state or workings of the object are. When describing an object, we only need to describe it's public interface in order to work with it.

Answer 14

Does Object Oriented Programming Really Model The Real World?

Not completely.

Well in the real world, we face real problems. We wish to solve this problem using a paradigm which replicates the system we wish to build which becomes the model.

For example, if a Shopping Cart application was the problem on hand, we have different entities like

1. Product which is an abstract term which can have multiple members like Books, Gadgets, Cars which can again be sub divided.

2. Tax Criteria like ( Sales Tax ) would depend on which location the software is implemented as it is subjected to change based on government policies.

3. Tax is considered based on whether the product was imported along with tax criteria.

4. User could have a shopping cart which has a list of products etc.

So as you can see, there are real problems that we are trying to solve but modularized to the OOP paradigm to make it as close to the real system as possible.

Answer 15

I think you are reading too much into what is intended to be a very prosaic, historical, statement. Many of the ideas of OO programming, classes, polymorpism, virtual functions, etc. were introduced in the language Simula, back in the 1960s (http://en.wikipedia.org/wiki/Simula). As the name suggests, Simula was designed to be a language for writing simulations. So historically, yes, OO ideas were introduced in an effort to model the "real world". Whether they succeed more than other styles is a matter of debate.

Answer 16

While some objects I create are modelling real world objects, would not pre-OOP code do the same?

The greatest difference between OOP and pre-OOP code is that the former models a real world situation as a group of distinct entities interacting with each other, each with limited "power" regarding what it can do, and also capable of "reacting" to external events with actions of its own. The latter models everything as a big chunk of data that doesn't do anything on its own, while the computation represents "things that happen" and can affect any or all of them.

Whether it better models the real world or not, that really depends on which facets of the world you're modelling. A physics simulation, for example, where you want to describe the effects that, say, a fire being lit would have in the surrouding objects, would be better represented by a "traditional" approach, since both the light and the heat are well-defined processes that affect both external and internal state of other objects, and do not vary according to the behavior of each particular object, only being affected by their properties.

On the other hand, if you're modelling different components that interact to produce the desired behavior, treating them as agents instead of passive things can make it easier to do it correctly without missing anything. If I wanna turn on my TV, I just press the button, if the power cord is unplugged the TV.turnOn will check that for me. So, there's no risk of turning a cog and forgetting to turn that other that's touching it, since the cog itself (if programmed correctly) will take care of the secondary interactions that come as a consequence of the primary one.

But OO is really about how to model things, and that method of modelling doesn't seem inspired by the real world to me.

I believe it has more to do with the way we perceive the world than how the world actually is. One could argue that everything is just a bunch of atoms (or energy, or waves, whatever), but that doesn't help us handle the task of dealing with the problems we face, with understanding the environment around us and predicting future events (or describing past ones). So we make "mental models" of the world, and often those mental models find a better correspondence with OO than the data+processes one - which arguably models "better" how the real world actually operates.

It's also interesting to note that most people think of OOP as synonym with "classic OOP", where we taxonomically create sets and subsets of things, and unambiguously put objects in a very specific set. That's very useful for creating reusable new types, but not so great when the entity you're modelling is pretty much self-contained, and while it initiates interactions with other objects it rarely, if ever, is the target of an interaction. Or worse, when there are few (maybe only one) instance of that entiy, or the instances vary wildly in composition, behavior or both.

However, there's also "prototypical OOP", where an object is described by picking a similar one and enumerating the aspects where they differ. I'd suggest this essay for a good and not-too-technical explanation of the thought process (the whole post is too big, even for Steve Yegge's standards, so I'm pointing to the relevant section :P). Again, this is a good match for our mental models when imagining unknown instances by comparison to a known one, but not necessarily for how the real world "works"... (two cows are actually completely distict entities, even if we perceive them as being "alike" in many ways)

Answer 17

I think "Does" is the important part of this question. I think Object Oriented programming certainly Can model real world "objects", but this is programming. There is no methodology that can't be abused, so I don't think it's fair to say "OOP doesn't model the real world" just because you can do stupid things with Objects. That's no fairer than to say that Pointers aren't safe because you can do stupid things with pointers.

Wikipedia's article on the matter sums it up well:

Real-world modeling and relationships
OOP can be used to associate real-world objects and processes with digital counterparts. However, not everyone agrees that OOP facilitates direct real-world mapping (see Negative Criticism section) or that real-world mapping is even a worthy goal; Bertrand Meyer argues in Object-Oriented Software Construction[21] that a program is not a model of the world but a model of some part of the world; "Reality is a cousin twice removed".

The thing is unless your program is a universe simulation, you only care about parts of the real world--hence "model". That's what models are for, they give you the structure and the functionality that you need to display.

In the real world we have things (Objects) and things can perform actions (methods). We can quantify aspects of things (Properties). OOP has every potential to model real world things when used in a reductionist way; every complex thing has smaller or more specific sub classes and all of these things have natural interactions via methods.

OOP is a method of abstraction, so the practical thing is whether OOP really logically models objects in the Real World, it's less important that you're not modeling every single possible thing everything could ever do. If you need to do every single possible thing, you're not really modeling.

Answer 18

In order to think about object-orientation in its proper context, let's move up one level of abstraction and talk about programming in general, ok?

Regardless of whether you take OO or functional approaches, your program has to do something, doesn't it? The whole point of the program is to exhibit certain behaviors given a certain set of stimuli. So the reasons that programs exist at all is because they do something. The key word here is behavior.

In addition to considering what behaviors a program must implement, your program generally needs to exhibit certain qualities. For example, it is not enough for a heart-monitor program to have the behaviors required of it -- it usually also needs to performant quickly enough to operate in near-real time. Other "qualities" that a program may need to exhibit are: security, flexibility, modularity, extensibility, readability, and so on. We call these Architecture Quality Attributes. So we can say that our program needs to meet certain behavioral (functional) goals as well as exhibit certain qualities (non-functional).

So far, none of this has talked about OO, has it? Let's do that now.

Once an engineer understands the requirements (behavioral, AQAs, constraints, etc), the question arises: how shall I organize my code so that it does all the things it needs to do while also exhibiting the qualities necessary to be a useful program? Object-oriented programming is a strategy for organizing your program's functionality into cohesive modules of co-operating objects. Functional programming is just another strategy for organizing your program's functionality, and it does so in a different way. Both strategies have their strengths and weaknesses.

We have been witnessing a recent resurgence in functional concepts because it has strengths that are very compelling for hugely distributed processing, among other reasons.

But moving back to OO, you can see now that it does not necessarily model the "real-world"; what it does is organize the behavior of your program so that your program can exhibit the qualities needed to meet any number of business objectives. Techniques such as TDD, DDD, and BDD are the ways in which we discover how best to organize our objects. Books such as Principles, Patterns, and Practices, Growing Object-Oriented Software Guided by Tests, Specification by Example, and Domain-Driven Design lay out the theory and practice of object-orientation with a focus on behavior-driven design.

When you read about things like "observers, managers, factories, etc", you're applying OO patterns that help your program exhibit certain qualities that may be necessary for it to be useful. They are "proven recipies" that "tend to work", given that your needs match the problem that the pattern solves.

I hope that helps you understand what OO is about without appearing too biased between OO and functional paradigms.

Answer 19

OOP creates a nice model from the programming point of view, it does not reflect real world.

However, there are much better approximations of the real world, which are known by the term domain specific languages (DSL). For example Boo provides you with ability to write human readable code in nearly plain English (sample from the article).

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

Another example would be automated user acceptance testing frameworks based on Gherkin language.

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

Answer 20

It's up to you, finally. But OOP is a precise way doing so than other methodologies like Structured or Procedure-oriented programming. Procedureal tact could possibly solve your problems but by following OOP can make you life more easier.