Larger programs usually model aspects of the program's domain. For a business application, the domain might be the business processes of a given company. For a RPG game, the domain is the fantasy world in which the events take place. For Pac-Man, the domain is the flat, 2D maze and the Ghost, pills and fruit that inhabit the world with the circular hero.
Object oriented languages are a popular way of modelling the domain. In this way of thinking, we want each interesting object in the domain to correspond to an object or set of objects in our program. An object could be a simple concrete thing, such as an enemy, a gun or a cactus. It can be more abstract, such as an unit or build order in an RTS game or a tile in a tile-based game.
We will quickly note that many of the objects come in groups, and are similar. For example, we will have different types of enemies, different guns or different orders we can give units. In an object oriented program, these groups are modelled as classes, and the individual objects are so-called instances. In an object oriented Pac-Man, there might be a Ghost class, and four instances for Inky, Binky, Pinky and Clyde. The fundamental idea is that you can write some code that will work with any Ghost, and sometime later in the program that code could be used on any particular instance of the Ghost class that might be around, without caring which particular ghost was used.
Most computer programs make a profound distinction between code and data. Most programming languages define the program code in a number of functions or procedures. The data is the contents of the variables in the program. At the time object orientation was being introduced, the popular languages at the time had a very simple mapping, code was represented as functions or procedures that acted on data, which was stored in data structures. Any function or procedure could typically change any data it wanted in the data structure. It could sometimes be quite difficult to track down the code that changed a variable to an unexpected or bad state in a large program.
Object orientated languages usually try and put the code (or behaviour) and data of an object together, often giving the programmer the option to hide certain bits of behaviour and data from the rest of the program. The belief is that an object should mange it's own data, and should be responsible for enforcing some rules about it's data. For instance, a Ghost in Pac-Man can either be alive (if you pardon the expression, I mean chasing Pac-Man), or be flashing blue, or be "dead" (returning to their pen). An object oriented purist would insist that the Ghost class be written so that it would not be possible to put the Ghost into an invalid state, or here multiple states. So any data that represents this state would be preferably hidden from the program, and the Ghost would only expose the methods necessary for the program to inform the Ghost of events such as Pac-Man eating a power pill, Pac-Man touching the Ghost, and the Ghost entering the pen. Then the ghost could decide to change it's state in response to these events.
Unfortunately, demonstrating the value of object orientation is challenging to a beginner, as the kind of complex program where this becomes an issue would be very difficult to explain. Generally speaking, the practical value of such rules is only evident to programmers when they start to build medium sized projects that pass a certain amount of complexity.
Edited by rip-off, 19 November 2013 - 01:26 PM.