What is Modern OOP
Misconception
First, OOP is not the use of what a (programming) class could do. Classes have inherency, encapsulation and so on. OOP is not about it. For example, An OOP code could use hierarchies, but it is optional, not mandatory!.
In fact, unless you are creating a visual object, inherency is something that we don’t need to use it at all.
So, what is modern OOP?
Let’s say the next example (a customer system)
string name=”John”;
int age=20;
string email=”john@doe.com”;
This example could work but, is it possible to group those variables?. Yes and it is the core of OOP
The next code could be written as
customer=new Customer();
customer.name=”John”;
customer.age=20;
customer.email=”john@doe.com”;
It is the same code, but every variable (now called fields, or properties, or states or setter/getters) are grouped and work together inside a class.
Why we should use OOP?.
1. Usage
Let’s say that we have a function that shows the customer.
Without OOP, the function will be called as
showCustomer(name,age,email)
And with OOP, the same function would be called as
// CustomerService customerService=new CustomerService ();
customerService.show(customer);
Where the function is also inside a class (called CustomerService).
While the first version looks cleaner and short but lets say that a customer has 20 variables. So, the function would look like
showCustomer(name,lastname,age,email,address,secondAdress,isActive…);
versus the OOP version that it still called in the same way
customerService.show(customer);
2. Serialization
For example, serializing the three variables returns three different serializations:
{“John”}
{20}
{“john@doe.com”}
Versus, serializing a model
{“name”:”John”
,”age”:20
,”email”:”john@doe.com”
}
It is easy to work with OOP and it is compatible with serialization. Instead, working with variables is not.
For example, it is what Twitter’s API returns
{
“text”: “RT @Example..”,
“truncated”: true,
“in_reply_to_user_id”: null,
“in_reply_to_status_id”: null,
“favorited”: false,
“source”: “<a href=\”http://twitter.com/\" ,
“in_reply_to_screen_name”: null,
“in_reply_to_status_id_str”: null
}
Twitter only works with OOP and practically all API works in this way.
Cargo Cult
However, it is easy to jump from a modern code to over-engineering.
For example, what could be used
- Hierarcy is optional
- Encapsulation is optional. It has a purpose but sometimes this purpose is not used. In fact, setter and getters sometimes are a burden than a help. For example (an example of Java). But some habits never dies.
someobject.getAddress().setSecondField(‘Sunset blv’); // it is not clear
versus
someobject.address.secondField=’SunsetBlv’; // its way clear.
Microsoft knows that, so they created (in C# language the concept of property). Technically a property is a function (setter and getter) but it is written in a single line.
someobject.Address.SecondField=’SunsetBlv’; // where Address and SecondField are properties
- Interface are optional, they are not mandatory. For example, to write one class one interface is usually useless. The goal of the interface is a contract and reusability (1 class = 1 interface is not reusability).
- OOP is not cargo cult, it is a good practice but nothing more. The end goal is the simplicity and a code that it’s easy to work and to keep update.
