Primary enemy in understanding OOP is all this noise which quite often leads to labelling as OOP things which are not OOP in any sense.
First of all let's take look at procedural programming. Take a look at wiki: https://en.wikipedia.org/wiki/Procedural_programming
Indeed!...The focus of procedural programming is to break down a programming task into a collection of variables, data structures, and subroutines...
Seems legit, but no, this is usual 'blah-blah-blah' without correct accent....whereas in object-oriented programming it is to break down a programming task into objects that expose behavior (methods) and data (members or attributes) using interfaces. The most important distinction is that while procedural programming uses procedures to operate on data structures, object-oriented programming bundles the two together, so an "object", which is an instance of a class, operates on its "own" data structure.
So, take a look at practical programming.
For example: typical procedural and modular C library: FILE stdio.h
Code: Select all
FILE *f = fopen(...); fwrite( ..., f ) fclose( f );
This is what is known as 'incapsulation' - very good technique which traditionally described as invention of OOP. But this is false: incapsulation is good and productive technique known before.
Now if we want to change inner structure of FILE - we may edit functions from stdio module only (modularity on the march) and everything will be ok.
So: we have object, we have incapsulation, we have strongly dedicated functions which cannot be applied to other objects due to types control: so isn't it OOP really?
But no. Some could say what we lack of inheritence and this is why it's not OOP? Not really.
Let's express main idea of procedural programming: 'Write code (procedures) which works with known objects'.
There is a lot of procedural code. Examples could be: complex numbers library (and it's not important if it is 'std::complex' or java.math.Complex), string library (and also it's not important if it's final public String - it's not OOP!) and so on.
So where OOP begins? It's very simple, lets hear Alan Kay, inventor of Smalltalk - one of the earlies OOP-languages:
And that's it: polymorphism is the nature of OOP....the early work of Doug Ross at MIT (AED and earlier) in
which he advocated embedding procedure pointers in data structures,
Sketchpad (which had full polymorphism -- where e.g. the same offset
in its data structure meant "display" and there would be a pointer to
the appropriate routine for the type of object that structure
Now, let's define main idea of OOP and compare it with procedural one: 'Write code which works with UNknown objects'.
Difference is 'known' vs 'unknown'. OOP objects in contrast with procedural objects have some layer of indirection to code which handes them and hiddens somehow exact data which they contain.
It's called polymorphism.
In strongly typed languages primary technique to implement polymorphism with type-checking is inheritance. That is why it is included in 'sacred trinity of OOP'.
But it's not true what inheritance is required as such. In non-typed languages polymorphism can be implemented without it. It's known as 'duck typing'.
In general it's not important how to implement it: you write OOP code then objects which it works with could have different internal structure and could react in different ways to the same 'messages' in runtime.
For example: HWND with PostMessage in WinAPI is OOP. It's not procedural, but OOP library. (For sure: if you write GUI you either end up with OOP or with extreme shit).
All these 'fruits' and 'apples' is just about 'write code which works with unknown (in runtime) objects'.
So, that's all and simple.