All that surrounds us - objects

Published on August 23, 2012

All that surrounds us - objects

I came across object-oriented programming in 1993 when I switched from the usual Pascal to the Object version. Later I worked with C ++, Java, php, JavaScript of which only in Java it was immediately clear "here only objects and no steps to the side."

Usually, work begins not with a long study of the theory, but from understanding the problem to finding ways to solve it. Therefore, to create sites on the server side, php was used; on the client side, javascript performed certain functionality.
For other tasks, respectively, other languages. The fact that in javascript "everything is an object" I did not understand right away. Yes, there was such a thing.
And before that I was always tormented by questions such as “how would I use one common code or data, only expanding the functionality?”, “What if a function with the same name already exists?”.
Later, when I changed jobs and came for interviews, they asked me questions about “polymorphism” and “encapsulation”.
These terms were dry and did not contain a deep practical meaning.
In object-oriented programming (OOP), it made sense to me as follows:
  • Living space of objects with clear boundaries and their internal sovereign democracy
  • The ability to expand existing practices (done earlier) without changing the working logic and without breaking the project

As soon as I found out that it is possible to use OOP in php and javascript, I began to use it.

I see only two disadvantages in OOP: one needs to think through the structure of objects well (be able to design) and the resources of computers are more expensive.
Yes, knowledge is still needed, and there is almost no time to upgrade it. However, this is more a joke than a serious obstacle.
I listed the cons in case they were. And then without the minuses the picture will not be objective.

There are much more pluses:
  1. a clear map of the project (yes, it just exists! - “cities” —objects inside the “country” -project) - reducing the complexity of understanding “how it works”
  2. the possibility of reusing ready-made "cubes"
  3. faster and clearer understanding of one’s (after years) and another’s (OOP) code, its maintenance.
  4. Protection of internal algorithms and data from involuntary changes - “black boxes”

These were the four main ones, which in the end: reduce the time of development and support of the project, unload the brain from “non-core noise” and push the boundaries when the project turns into “porridge”.

Recently on Habré I began to meet more often articles written in the style of "procedural vs OOP".
This is probably a real problem (OOP - for / against) for people, since such topics arise. But personally, if possible, I choose OOP.
It’s more convenient and easier for me to work. It’s only important to understand that OOP is just a tool.
And to use the tool there must always be a qualification of a certain level.

By the way, Hanspeter Moessenboeck in 1993 already considered the pros and cons in his article “Costs and Benefits of OOP” .