What does "representing" something in memory mean in OOP?

Question

While learning about OOP, I have found that the term "represent" is used a lot in OOP tutorials. For example I may find a statement like this: "a car object represents a real life car" (of course an object can represent anything, not just real life entities).

My question is, what does the term "represent" mean in this case, does it mean the following:

• We can't actually put a real life car inside of computer memory!! but we can put in memory some data (variables) that describe a real life car (for example: color, speed, etc.), and we can also put some functionality (methods) that describe the functionality of a real life car (for example: drive(), stop(), etc.), and these combined variables and methods are a car object.

• And then we can "imagine" or "pretend" that the car object in memory is actually a real life car, so for example when we do car_object.drive(), we can "imagine" or "pretend" that there is an actual car that is being driven (even though in reality what is happening is that some variables in memory are being manipulated, and not an actual car is being driven!!).

Am I correct in my understanding?

Answer 1

This question is not specific to software engineering: it applies to all disciplines working with information.

In 1929, the Belgian surrealist painter René Magritte explained it very intuitively in a masterpiece of art called the treachery of images: the painting shows a pipe on a uniform background, and a caption in French "This is not a pipe". It looks totally absurd, because you see a pipe, so why shouldn’t it be a pipe? This is because it’s not a real pipe. If he’d expressed it positively, he would have written "This is a representation of a pipe".

You explained it appropriately for OOP: a representation of a Car is not a car; you can’t use the Car in memory to drive home. In The Sims your avatar (your representation) could use it to go to the representation of your home. By the way, even in the game, The Car representation in memory (properties about the car, its state, and a 3D model) is different from the visual representation of the car representation on the screen (2D picture made with shapes and colors).

But there’s more behind it. The information in memory is just a set of bits. We decide what it represents. Take for example a simple byte 0b1000001. The same byte value could represent 65 if we want it to be an integer, A if we want it to be an ASCII character, a RES control code if we want to use it as EBCDIC character or even a set { garden, terrace } if we decide that it’s a bit encoding of a set where the 7th bit corresponds to a terrace and the first bit a garden.

In memory, there are only bits. The representation is the mapping we do to give them some kind of meaning. For an OOP object, that mapping is done between the values in memory and the state of the object and the methods that make its behavior. How is, of course, language specific (examples: C++, Java).

Answer 2

Yes, it basically means what you said. The representation of an object is meant to correspond to the object - it tells you some information about the object, or it identifies the object - but it's not actually the object.

"Represent" is an English word which is not specific to OOP. A photograph of a car represents a car, because it isn't a car, but we can pretend it is. The number on the car's number plate can represent the car, if you only need to know the number plate (e.g. if you're trying to catch cars with expired number plates). The phrase "a blue sedan driving south on Main St with a middle-aged male, no passengers" can represent the car, to a policeman trying to catch it.

Note that most programs about cars don't have drive functions. The DMV has no use for a drive function. Neither does an insurance company. A traffic simulation or a computer game might have a drive function.

Answer 3

Actually, between objects of the real world and representations, there is another layer: Terms & Informations.

In writing your question here, you have already used all three of those layers. Or maybe even just two. You have an abstract idea of what a car is. Something with four wheels, a motor, at least one dorr, at least one seat, a steering wheel and so on. But if you ask ten people to draw a car, they will all draw different things. The details are all different. And yet, when we talk about the abstract idea of a car, we have an idea of what is meant by it and can effectively communicate.

In fact, the three letters "car" are already a representation of that abstract concept. I could have easily written "Auto" (in german), "macchina" (italian) and so on, and it would all still be representations of the same abstract idea.

If we put the real world on the left, and the representation on the right, we can create the following diagram:

            Abstraction                                 Presentation
           ---------------------->                     ---------------> 
Real World                         Terms, Information                  Representations
          <-----------------------                     <---------------
             Understanding,                              Interpretation
             Comprehension
                                               

In the real world, you have a real car. But not all cars are the same. All cars are different. but we can abstract those differences away and get an abstract concept of a car. this is not the same as the letters that make up the word "car". The three letters 'C', 'a', 'r' forming the word "car" are already a representation of this abstract idea. A comic image would also be. So would a photo. Or the word "Auto" or "macchina". All different representations -- in different languages or media types -- for the same concept.

You can easily see that in order to write your question, the word "car" had to be stored in memory on your compuer, then on the many servers in between you and me, and finally on my computer. This representation of a car was and is in the memory of my and your computer. Its is one of the many ways how you could represent a car in memory. It just turns out that this representation is super useful for writing to each other, but absurdly unsuitable for writing a simulation involving cars as an OOP program.

Most books skip these details because we humans do this all the time, and going from the left to the right or right to the let in the above diagram is fairly easy in a lot of cases.

However, when you design a computer program, you need to put a little bit more work into it. Which properties of real cars are interesting to me? Those are the properties you need to model. And finally, when you create a new car by doing var myCar = new Car(), then you are creating an in-memory representation of some car. You can't say exactly which real car. Or if you have a database tracking e.g. the number plate, you can even say which real car. But the in-memory representation of the car is not the real car, and is also isn't the abstract idea of a car. Its a representation of some car.

We use our programs to model properties of those representations and how they interact. But in the end, its the human mind that gives meaning to it by interpreting what we see on the monitor.

Even if we use those representations to remotely drive real cars around - the representation still isn't the real car. Just one way to represent it. In a way our program can use it. In a way we can use it.

Numbers, for example, have been represented over the years in many different ways.

The following are three representations of the same number, which have all been in use and continue to be in use today:

|||| = IV = 4

Using vertical bars is still done, I do it in my sports team to keep count of scores. Roman numerals are ubiquitous in Europe. And finally, the arabic representation of the same number.

_{Fun question: What is 0 "in the real world"? Abstractly, its the idea of nothingness. But what is nothing in reality? Food for thought.}

Answer 4

I would not even approach this question from a technical (maybe even ontological) point of view, although Christophe is right, in the end it's just a bunch of bits. I'd like to address this from a more conceptual point of view, as it all boils down to a main concept of object-orientation, with the object Car being an abstraction of the class Car and the class Car being an abstraction of actually existing cars (may even have more layers between).

Car XYZ is a specific manifestation of the more abstract concept Car, thus making it a representation of what is actually meant with Car. The String Car XYZ obviously is not the car, but just a set of symbols representing this specific slice of reality. The difference is between addressing a class/concept and an instantiation/manifestation of those and it is crucial to have this in your mind at any time. OOP is all about that and I guess that's why most tutorials emphasize on using such correct, yet unusual terminology. One of my professors at university strongly stressed the importance of teaching us the fundamentals of abstraction as a core competence of Information System Science. By now, I strongly agree with him, as software in itself, as well as models, frameworks, architectures are basically all abstractions. Even in everyday life, we think in abstractions and communicate in abstractions, each word we use is an abstraction of a mental concept and as such, it's essential to understand how we perceive the world, not only, but especially as somebody working in IT. I'll just give you a brief overview of what I mean (both excerpts are taken from my own study paper, not violating any copyright as I am the author):

As far as designing software, software architectures and IT artifacts in general goes, abstraction is - simplified - understood as the removal of irrelevant or only slightly relevant aspects of an issue to be able to focus on its essential core (see [Aho and Ullmann, 1992]), [...]. Abstracting less relevant aspects of any regarded object in reality away - which means fading them out - leads to the remain of solely relevant parts: The issue becomes more accessible. [...] An example for this way of abstraction would be the representation of a person within an object-oriented programing language. [...] [I]f we assume some kind of banking domain, it would usually not make much sense to represent the height of the person or his eyes’ color. On the other hand, one would regard properties like for example his name, his birthday or his bank account ID as relevant. However, the relevance of certain aspects may or will depend on the individual creating this abstraction, as well as on the purpose of the process of abstraction (see [Kramer and Hazzan, 2006] [...]). Thus several people could form different abstractions of the same issue due to having different knowledge bases, a circumstance which relates to the semiotic triangle [...]

[...]

Despite being that important for computer sciences, the idea of abstraction does not origin in this field, since its origins lie in mental processes cognitive psychology originally dealt with. Therefore, one has to take a step back and view the idea of abstraction from a different field of study to fully identify its consequences. On the one hand, abstraction in cognitive psychology ”involves the selection of certain portions or aspects of an experience” [Posner, 1970] which inevitably means that the other portions or aspects of an experience - which can be experiencing a subject, situation, problem or idea - are unselected or removed, [...]. On the other hand, removing distinguishing aspects of several experiences can lead to commonalities, or as Posner describes in [Posner, 1970]: ”the classification of a stimulus into a wider or more inclusive superordinate category”. It seems that the second sense of abstraction is a direct consequence of the first one and that they are ultimately tied together. Gradually removing certain aspects from a set of experiences (to make it more abstract) will result in a set of more and more common experiences, up to the point that (they are so abstract) they do not differentiate anymore, since the aspects that made them unique towards each other vanished. This is what Posner means by ”categories” and, vice versa, to classify a set of experiences top-down into categories, the same steps are necessary, namely incrementally removing aspects in a way that only commonalities or - with our understanding - the common core remains. Those superordinate categories are also called concepts. This understanding from cognitive psychology [...] describes a process of thought trying to explain and understand reality through forming concepts (see [Gruber et al., 1993]) or more precisely, through the process of conceptualization. A concept essentially is a unit of thought which is abstracted from a multitude of objects via analysis of the properties common to these objects (see [Deutsches Institut für Normung, 2013] [...]). Those units of thought are the human basis to perceive the real world and communicate about very same. [...] To put it in other words, concepts are the building blocks to form a mental representation of the world, since we simply cannot perceive the world as it is, but only as our senses allow us to perceive it (see [Korzybski, 1946] [...]).

Sorry for the wall of text, I tried to shorten it but with less information, my main point may have been mitigated. Everything you communicate or think about, is an abstraction, thus a representation of a more abstract concept. Seeing a car triggers your brain to make the connection to your own personal concept of a car, which can be different for everybody. Without this implicit categorization, the word car would make no sense. To address a set of cars, people would have to exhaustively list "this object, this object, [...]" to be able to talk about all existing cars.

To reconnect all this to your question: represent means the car object is a purposeful abstraction representing the real life object to be able to communicate about that object, statements like "a car object IS a real life car" would simply be wrong. This point of view is important in OOP because there is a clear and important distinction between classes (generalized concepts) and objects (specific instances of those concepts) and I assume that's why you find this so often in OOP tutorials.

If you're further interested in how words, concepts and the real world are connected, you should definitely read on the semiotic triangle, really interesting and partially already covered by the answer of Polygnome.

Literature:

• [Aho and Ullmann, 1992] Aho, A. V. and Ullmann, J. D. (1992). Computer Science: The Mechanization of Abstraction, pages 1–23. W. H. Freeman.
• [Deutsches Institut für Normung, 2013] Deutsches Institut für Normung (2013). Begriffe und Benennungen – Allgemeine Grundsätze. DIN 2330:2013-07.
• [Gruber et al., 1993] Gruber, T. R. et al. (1993). A Translation approach to portable Ontology Specifications. Knowledge Acquisition, 5(2):199–220.
• [Korzybski, 1946] Alfred Korzybski (1946). An Extensional Analysis of the Process of Abstracting from an Electro-Colloidal Non-Aristotelian Point of View. Synthese, 5(5/6):239–241.
• [Kramer and Hazzan, 2006] Kramer, J. and Hazzan, O. (2006). The Role of Abstraction in Software Engineering. In Proceedings of the 28th international conference on Software engineering, pages 1017–1018. ACM.
• [Posner, 1970] Posner, M. I. (1970). Abstraction and the process of recognition. Psychology of Learning and Motivation, 3:43 – 100.

Answer 5

Object oriented programming was initially invented for the purpose of simulations. (The first OO language was called Simula and as its name indicates it was specifically designed for doing simulations.) In simulations you have objects representing things in the domain you are simulating. E.g. if you simulate traffic in a computer model in order to test some infrastructure design, you might have objects representing cars. These are indeed not actual cars - exactly as you describe.

Nowadays object oriented programming is used in all kinds of domains, not just simulations. So in most cases objects doesn't really represent anything beside what they actually are. For example a Stream or a List in a typically OO language does not "represent" or "simulate" something more real than the object itself.

Take an inventory management system for a car dealership. In such a system there might be objects or data records representing real-world cars. But the object representing cars will not have a drive() method since the system will not simulate the car driving around (and neither will it be able to get the actual car to drive). Instead it might have methods like sell() or reducePrice() or whatever. These methods does not represent the behavior of real-world cars, they represent what an inventory management system would do with the record of a car. This form of objects is much more common than simulation scenarios.

But because of tradition simulation examples are still used in many OO tutorials which IMHO create a lot of confusion.

Answer 6

Semiotics

You'll find that everything in IT is about representation. At the end of the day the computer itself is a fluctuating cascade of electrons across sand, or the dripping of fluid through a pipe, or the relative location of gears, cams, and spindles.

What is Real?

Is a really tough question (no, really).

Philosophers have literally wrung each others necks over this topic for millenia.

Thought experiment:

A Tesla car is a Car. It is also a computer containing a model of the car. Which is real, and which is the representation? the Car, or the model of the Car within the Car?

The Car is obviously physical. When the Car physical changes (such as moving) the model is updated. This would imply that the model is the representation.

But...

When the model of the Car changes, so does the Car. It's hardly imagined, no pretence need be made. So that would mean the Car is the representation of the computer's model.

So how to properly think about this?

Systems S, P, and E

• S Systems are well defined, and well prescribed operations like sorting. There may be many ways to achieve the result, but it is possible to achieve it and it is clear when it is present (or not).

• P Systems have a well defined problem, but there is no prescribed means or sufficiently rigorous way to solve it. For example the travelling salesperson problem, or an economic simulation. We know what we want, but there isn't a way to solve it outside of trying everything (which is impossible), approximating it (which automatically implies the result is wrong for a value of wrongness), or restrict it down to an S system which guarantees results but doesn't solve parts of the problem.

• E systems are emergent systems. They don't solve the problem, they are part of the problem. Think air traffic controller system. The very act of attempting to solve the problem, changes the problem.

The model and what it represents depends entirely upon the kind of system it sits in.

In the thought experiment the model of the car, and the car are not separate things. Even though part of it is physical.

You'll find that most textbooks talk about models representing X in the realm of S and P systems.

Answer 7

OOP is a modeling technique. Any model is a representation. Both of your descriptions could be accurate, the second one would fit a simulation.

Answer 8

Yes, you're correct. There is one small caveat as James_pic mentions in a comment, "There's no inherent reason why car_object.drive() should not result in an actual car driving somewhere." Even if drive() does make some real car move (and not just your "fake" car), then the word "represent" is still accurate.

Answer 9

A "representation" can be anything. The only real rule is that it should have a referent: a "car" should have some real car that it refers to (or an imaginary car, if it is representing an imaginary car).

Beyond that one rule, the only other thing that matters is a rule of thumb: symmetry. There should be a symmetry between the representation and the thing being represented. This means that, if you consider something you can do to the car, such as press on the accelerator, there is a corresponding something on your representation, perhaps car->accelerate().

The nice thing about these symmetries is that they compose. So if you do car->accelerate(); car->driveForNSeconds(5); car->brakes(), the result should relate to a car that accelerated for 5 seconds then slammed on the brakes.