You have already seen that a model is a useful representation of something. Object-oriented programming applies a similar idea to software by organizing a program around objects that represent the things the program needs to know about.
Object-oriented programming (OOP) is a way of organizing software around objects that represent meaningful parts of a system.
An object is not the real thing. It is a software representation of selected information about that thing.
For now, the important idea is the way of thinking. You do not need to write object-oriented C# code yet.
A program may need to represent several different things.
Each represented thing can have information associated with it.
Objects can also be connected to other objects as part of a larger system.
Imagine software that helps keep track of a soccer match. The program might need to represent:
These are possible objects because the program may need to keep track of information about each of them.
A real soccer match contains an enormous amount of information.
It includes players, uniforms, weather, grass, spectators, sounds, advertisements, shoe colors, player positions, the score, the ball, the teams, and much more.
Software does not automatically need all of those details.
A useful question is:
What things does this particular program need to represent?
If the program helps a coach manage a team roster, players and teams may be important objects.
If the program tracks a match, the match itself and the ball may also matter.
The objects a program needs depend on what the software is supposed to accomplish.
A software object that represents a soccer player is not the actual player.
The real player has thousands of characteristics. A particular program may need only a small amount of information about that player.
The same is true for a soccer ball. A software object does not need to reproduce every physical detail of a real ball. It represents only the information useful to the program's purpose.
This is the same modeling idea you have already encountered:
A model represents selected information for a purpose.
Objects give software one way to organize those representations.
There is no single perfect software representation of a player.
Different programs can need different information about the same real-world thing.
For example:
The useful representation depends on what the software is supposed to accomplish.
An object-oriented program can contain multiple objects that together represent a larger situation.
A soccer match might involve player objects, team objects, a ball object, and a match object.
For now, you only need to recognize that these represented things can exist as separate objects and can be related to one another.
Later, you will look more closely at:
Imagine you are helping design software that displays basic information about a soccer match.
Identify three things that could reasonably be represented as objects.
Then consider this question:
Why might the program leave out information such as the color of a player's shoelaces?
A useful answer should connect the program's purpose to the information it needs to represent. Not every real-world detail belongs in the software model.
Once developers identify possible objects, they still have an important decision to make:
What information about each object actually matters?
Real things contain far more detail than software usually needs. Choosing the useful details—and intentionally leaving other details out—is the idea explored next through abstraction.