ABAP OO Design: 7 Basic OO Principles Summary
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:
- Access principles (Horizontally principles)
- Data hiding
- Inheritance principles (Vertically principles)
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.
Instantiation is creating an object instance based on a class.
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 = 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.
This series of blogs is very much like a university course on OO principles. I am not saying that is good or bad, just an observation.
In any event I would like to focus on this bit:
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.
Now, how do I know my father was actually my father rather than the Milkman? Because I act like him (inherited methods) and look like him and went bald at exactly the same age as him whereas my mates whose fathers always had full heads of hair their entire life never went bald (inherited public attributes).
So in OO terms the usual example is that a CAT IS IN ANIMAL. In the same way, since my surname is hardy I can say that PAUL HARDY IS A HARDY since I am just like both my father and my mother (what some languages call multiple inheritance).
The point I am making is that is what the term "inheritance" was intended to mean in OO terms. Like many things (e.g. general ledger) we are speaking of a "digital twin" of a concept that exists in the real world.
To stretch the analogy a bit further I am a white Englishman, and when I moved to Australia I married an Aboriginal woman and "inherited" two children.
So when I walked into the pub I am a six foot tall chalk white weedy UK guy, and my son was seven foot tall jet black aboriginal guy rippling with muscles and I would say to say to the barmaid "This is my son - doesn't look much like me does he!"
This is very rambling and I am sorry. I am signing off now.
Columbo: Oh yes, just one last thing.....
It is probably best not to explain concepts in university level/mathematical terms but rather by analogy. As an example....
The Japanese say you have three faces - the one you show to the world, you one you show to your family, and the one you show only to yourself.
In OO terms this translates as
The world - this is where the PUBLIC components (data / behaviour) of a class (or the interface, which is where all public methods attributes should be declared)
Your family - this is where PROTECTED components should be declared, that can be used by children of the main class
Just yourself - this is where PRIVATE components should be declared. What you think and do in private can change as much as you want, and to the public you are just the same as ever.
Your opinion triggered me to add paragraph “Parent / child example” to go deeper into this topic with an example. To me it is important that a "digital twin" is as close to a comparison as it can be and is as less confusing as possible. So to me the ”digital twin” of OO inheritance is Super class Mammal and Sub class Human and not Parent / Child.
I know we disagree on this topic and that’s ok. It's an interesting topic and a discussion about this topic makes it more interesting.
Thank you for your opinion.
Kind regards, Alwin.