Getting started with OOP

There are many object-oriented programming languages these days. C/C#/C++, Java, etc. are some well known examples of this.
On this page I'll explain what an object-oriented programming (OOP) means and how to work with it.

What is an object?

An object is a collection of related information and functionality. An object can be something that exists in the daily life (like an object employer), it can only have a virtual meaning (like a window on a display device), or exclusively an easy abstraction in a program (like a list with tasks).
An object is composed out of data that describe the object and the versions that can be executed on the object. The data stored in an object employer, could incl. exist out of identifying data (name, address), work data (function name, salary), etc.
The versions that can be executed on such an object, could be a salary counterfoil or documenting the promotion of this employer.


Inheritance is a fundamental possibility of an object-oriented system; it's the possibility to inherit data and functionality of a parent-object. Instead of creating a completely new object, the new code can be based on the work of other programmers, by only adding new required functions. The parent-object on which the new object is based is called the base class, the child-class is the derived class.
In explanations of object-oriented designs much attention is spent on inheritance; nevertheless inheritance isn't used on large scale in most of the designs. For this are several reasons.
First, inheritance is an example of something called in object-oriented programming a 'is-a'-relation. If a system includes an object animal and an object cat, the object cat could inherit of the object animal, because a cat 'is-an' animal.
For inheritance the base class is always more general than the derived class. The class cat could then inherit the function eat of the class animal. When creating for the daily practice such relations aren't used so frequently.
Second, to use inheritance, it's necessary that the base class is designed with inheritance in the back of your mind. This is important for several reasons. If the objects haven't got the right structure, inheritance can't work properly. Even more important is that a design that allows makes clear that the author of the base class wants to support other derived classes that inherit of this base class. If a new class inherit of a class where this is not the case, it can happen that the base class is modified on a certain moment as a result of which the derived class is broken.


If inheritance isn't the right choice, what is it then? The answer is containment, also known as aggregation. Instead of saying that an object is an example of another object an instance of that other object is contained in the object. Thereby you got, instead of a class that looks like a string, a class that has got an contained string (or an array/ hash-diagram).
The standard choice when designing should be containment and you should switch over to inheritance if it's necessary (when there is a 'is-a'-relation).


In OOP, encapsulation means the visibility (and thus the accessibility) of an object to another object. Encapsulation is done by scope levels, listed here:

  • public: visible to all classes
  • private: visible only to the class itself
  • internal: visible only to classes within the same package/assembly (C-languages only, in Java this is obtained by specifying no scope level, (e.g. int Example;))
  • protected: visible only to subclasses of the class wherein the object is declared.

If you want to encapsulate an object, you need to check where the object will be needed. An example (in Java):

public class Example {
private int x;
private int y;
private int sum;
public void setX(int value) {
x = value;
public void setY(int value) {
y = value;
public int addIt(x,y) {
sum = x+y;
return sum;

The integers x, y and sum are declared as private because there ought not to be messed with them. If we'd declare them as public, a client class would maybe do the following:

public class BadExample {
x = 102;
y = 113;
//this returns zero

Or the following:

public class AnotherBadExample {
x = 102;
y = 113;
sum = 150;
//this returns a completely wrong value because sum is accessible to the client

So mind you if you specify the scope levels.


If you want to understand polymorphism, you first need to know what reference/primitive types are:

  • Primitive type: A type that is part of the language, like int or String or double.
  • Reference types: These are specified by the user or a library, e.g. Complex.

Polymorphism is, in fact, conversion from one type to another. We can distinguish two types of conversion:

  • Implicit conversion: There is no data loss.
  • Explicit conversion: Involves data loss.

For primitive types

Now you might be asking yourself why there might be any data loss. Well, it can be explained with an example.

public class Example {
double a = 3.39;
double b = 4.25;
int c = (int) b;  //the (int) is named "cast", it is always necessary
int d = (int) d;

If you compile and run this code, you'll notice that c equals 3 and d equals 4. Where have the decimal parts gone? The answer is: int can only contain integers, and no rational numbers, so the decimal part is chopped off. This is Explicit conversion. Same goes for conversion from short to int, or from byte to long.

For reference types

These rules are similar for reference types. You can upcast an object to an object of the class it inherited from. Upcasting is implicit. But the other way round, by downcasting you get explicit conversion.

An example. Take a look at the following inheritance hierarchy:

  • Polygon
    • Parallelogram
      • Rectangle

If you want to convert a Parallelogram to a Polygon, there'll be no data loss, because a Parallelogram has all the properties of a Polygon. But if you try to convert it to a Rectangle, which has extra properties, there will be data loss.

Note: It's not so clear whether this information is used often, but at any rate, conversion of reference types is not used very often, except in advanced OOP.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License