Object isn’t about real world Objects

The OOP paradigm in programming isn’t about modeling objects from real world with properties as we were told before, but about interfaces that communicate with each other. Interfaces are like contracts that tell what they offer you and what they must receive, the object answering it doesn’t matter much, which is the original concept from smalltalk that was the first to have this paradigm.

Interfaces

One of the best ways to expose it is through golang interfaces.

type Shape interface {
     Perimeter(...sides int) int
}

When we pass the type Shape to a function, it doesn’t matter if the object is a triangle or square, the only thing that matters is the message being passed and the answer received.
As I want to reinforce, It is the way it was intended to be as a paradigm. The Object was a template of how the messages would be processed and responded to, they worked the same as the interfaces we have today and it makes a lot of difference when programming and thinking about the result.

The Object leaves the main point and you start thinking about the contract between them, you don’t model them after a ’thing’ that exists in real life, but as the behavior you expect to have accordingly to a certain message being received to be processed.
Using the example of shapes, if you receive a message with 3 sides, you know it is a triangle, then the template regarding triangle (the object) will take this information and work on it… same if it was 4 sides, you would use the rectangle object…

What we have today, that is basically highlighting the objects and classes so much, is due to the inheritance of java. It being used as a standard way to learn OOP brought a lot of weird thoughts regarding this paradigm and how it should work. I too was really confused about it because of the usual and lazy explanations, so I am writing about it to clarify and bring this perspective into light.