There many blog posts about OO principles. The reason for me to write also a blog post on this subject is because it can be a struggle to get out of all these blog posts a clear unambiguous understanding of the terms and the relationship between the terms. So this blog post is focused on how to remember them and the principles cohesion. And also to give some information about relative class names.

Basic OO Principles Overview

The basic OO principles are:

• Instantiation
• Access principles (Horizontally principles)
  • Abstraction
  • Encapsulation
  • Data hiding
• Inheritance principles (Vertically principles)
  • Inheritance
  • Realization
  • Polymorphism

1 + 3 + 3 = 7

Instantiation is the “1” principle. The other 6 principles are split into 2 groups “3 + 3”.
These groups are “Access principles” and “Inheritance principles”.

Access principles are about accessing the class via the methods. Access are drawn by dependency and association relations horizontally in a class diagram, so these principles are the “horizontally” principles.

Inheritance principles are about inheriting classes and interfaces and these relations are drawn vertically in a class diagram, so these principles are the “vertically” principles.

So we have instantiation, 3 horizontally and 3 vertically principles.

Short explanation

Instantiation

Instantiation is creating an object instance based on a class.

Access principles

Abstraction, Encapsulation and Data hiding are 3 principles which belong together.
The picture below shows the coherence between these terms.

• Abstraction = design the class interface which contains the pubic data types, constants and method definitions.
• Data hiding = make data not accessible from outside the class.
  This is realized by making the data private (-) or protected (#).
• Encapsulation = encapsulate the method implementation and data.
  So from outside the class these are only accessible by the class interface.

Inheritance principles

• Inheritance = Sub class inherits the class interface (public + protected) of the Super class and the implementation of a super class.
• Realization = Interface class is implemented by an implementing class.
  An interface has no implementation, so the implementing class must implement the interface.
• Polymorphism = One method definition can have more than one method implementations. In this example methodA() is implemented three times.

Appendix: Relative class names

Basic relative class names

Relative class names have a purpose in relation to another class.

• A dependency relation is that class A uses class B.
  This is a “uses-a” relation where the Client class uses the Supplier class.
• An association relation is that class A is the whole and class B is a part of class A.
  This is a “has-a” relation where Whole class A has a Part class B.
• An inheritance relation is that class A is generic class of specific class B.
  This is a “is-a kind of” relation where Super class B is a kind of Sub class A.
• A realization relation is that class A is an implementing class of interface B.
  This is a “implement” relation where Interface B is an interface of Implementation class A.

See also the graph below. The relative class names and the relations are mentioned.

Abstract class vs Concrete class

In relation to inheritance also the terms abstract and concrete are used. An abstract class is a class which cannot be instantiated and a concrete class can be instantiated. For example you have a class Purchase Order and a class Sales Order and both inherit from super class Order. Order is too abstract to be instantiated, that’s why it is abstract.

An abstract class can also have abstract methods. Abstract methods are not implemented in the abstract class, which mean that they have no code. The concrete sub class must implement the code.

Parent class vs child class

The terms parent class and child class are sometimes used for inheritance and sometimes for associations. In the real world a human child is not inheritance (“a kind of”) the parent. That relation could be a association relation (“has a”). “A human parent has a human child.”. A human child and parent are both “a kind of” human. For inheritance I would stick to the terms super and sub class.

In object hierarchy structures the terms parent and child are also used, which are than association relations. In this case I think parent en child class are very useful.

Parent / child example

In real life we speak about inheritance when a child inherits characteristics from it’s parents.

In OO a father, mother and a child are instances. An instance is created based on a class (class Human). In OO an instance cannot inherit from another instance. An instance is created from a class. Only a class can inherit from another class (Human -> Mammal), see the Class diagram. Therefor a child instance Maria cannot inherit from her parents John and Sandra which are also instances.

So you could say that in real life we speak about “instance inheritance” and in OO we speak about “class inheritance”. Those are two different things.

In OO you could say that the mother instance created the daughter instance and set some properties based on her and John’s properties. But there are also properties which are random set. And that makes sense, because you might look like your father or mother, but you are not exactly the same. In many ways you differ from both.

Hopefully this helps that the terms parent class / child class might be confusing when using them for OO inheritance. It is purer to stick to the terms super class / sub class and compare it to “human class / mammal class”.

Software patterns relative class names

In software patterns can also contain relative class names. For example the facade pattern has the facade class. The factory method pattern has the factory class. Sometimes it is useful to use the relative name in the ABAP class name more often it is not. For example facade is not used in class names, but factory is used in class names.

Appendix: “Class interface” vs “Interface class”

There is an important difference between a “Class interface” and an “Interface class”, where an “Interface class” is often called an Interface and mentioned in UML as <<interface>>. And a Class interface is the interface of a Class.

A class interface is the interface of a class and is actually the public section of a class. The public section of class components are data types, constants and method definitions. It can also contain data, but due to the data hiding principle it is not allowed.

The complete class interface or parts of it can be pulled out of the public section into a Interface. The interface contains not the implementations of the methods. The implementing class will implement the Interface and that is called realization.