What are the practical advantages of using object orientation in the day-to-day life of a development team?

Question

Work in a company that does not use object orientation, although the language allows (and encourage).

I have studied and study object orientation, and do my personal projects in OO, but I do not know exactly what arguments could be used to motivate a company (which is in a comfort zone, from the technical point of view) to consider developing new projects in an object-oriented way.

Anyway, if I went to talk to my manager, what would be the most convincing arguments in favor of object orientation?

Answer 1

Standardization

Just as a child who is learning to read has difficulty joining the letters to form words, an earlier one already reads whole words but strives to join them in sentences, and a proficient reader already "sees" whole sentences, so does programming. If you saw a noose for If you go through a list every 1 million times, you don’t get lost in the syntax of that specific instruction, your look already falls into the particular details. Similarly, if you’ve seen N online examples of a task being done in a certain way in the X language, seeing a similar code already becomes its second nature.

If a language works predominantly with OO practices, adopting these same practices in its code makes it more readable than not adopting them. Not because OO is more readable than procedural, functional, etc., but because professionals with experience in that language are already conditioned to think that way. If a project is being made from scratch, by professionals who are not foreign to syntax and OO semantics, developing it in the most "usual" way to the platform contributes to its maintainability, especially if a group of professionals other than the one who wrote it may possibly be responsible for supporting it.

Flexibility in the workflow

A strictly object-oriented program has neither a "start" nor an "end": instead, it has a set of objects capable of exchanging messages with each other. The order in which these messages are exchanged matters, of course, as well as it is possible to save even global state using objects. But changing the order in which certain subroutines are invoked is something (at least in theory) more feasible in an OO architecture than in a procedural one - because it doesn’t necessarily involve restructuring the entire code.

Explaining this better (because my last statement is dubious), in a system where operation A always occurs before B, one can assume certain things about its state at the time B is executed. If you decide to pass B to before A, it is necessary to make an assessment of all that was assumed to be true in B and verify what is still true and what is no longer true - and therefore needs to be adapted.

Object orientation does not "magically" solve this problem, but it does help modularize the decision process: by establishing (formally or informally) that object X has certain invariants, and only programming assuming such invariants as true, avoid falling into the addiction of writing code that "only works if A, B and C has already happened". Instead the OO forces you to evaluate whether the state of the objects involved in certain computation are able to perform this computation, regardless of the sequence of events that brought them to that state.

Switching in kids, it is easier to create a script (in the sense of "script") to put order in a system that allows N actions than to divide in N actions a system expressed by means of a script...

Levels of abstraction

Ideally, we should always program at the right abstraction level to represent the problem we’re dealing with. That’s why no one "programs a game", for example: a program engine games, and uses the scripting language of that engine to create the particular game. This can be done even if you do not intend to reuse this code in any other game.

Some recommend using Dsls ("Domain-Specific Languages") to achieve this goal, but in general this is very impractical - it’s not easy to learn a new language, or at least it’s not easy to "get the hang of it" quickly how to do the X action in the new Y language. A more common language is preferable, but it makes no sense to limit itself to the basic primitives of this language to develop at the higher levels of abstraction.

It is at this time that the use of types defined by the user is interesting: the concept of "object" may not be exactly the same concept of "type", but they have a lot in common (and a "class" can be used to represent a "type"). By uniting data structure and functionality into a single unit, and combining the basic operations of that unit to perform complex computations (as opposed to doing it using the basic operations of its components), you are reasoning at a higher level, more appropriate for the problem to be solved.

Reiterating: custom types are not the privilege of the OO paradigm, but are one of the benefits of using this paradigm. If you encapsulate the numerical components of a matrix or vector it is not "for any careless programmer to tamper with them by mistake" - but rather to enable you to express your computation as a series of operations on vectors/matrices instead of expressing-It was like a series of scalar operations. If you evaluate that your system would benefit from a greater wealth of types (great "if" - I personally am of the opinion that there are many cases where a basic structure is more appropriate, and that the use of classes is Overkill), may be an argument in favor of adopting this particular OO resource (with or without inheritance and polymorphism).

Extensibility

Sometimes it is necessary for a system to be extensible, especially when it is necessary to support different data formats and/or interface with third-party systems. In some cases this can be done in a purely functional way (i.e. a dictionary mapping a name to the function that deals with that name), but in others a set of distinct but related operations may be required (and perhaps still retaining state) to accomplish a certain task.

In this case the use of an abstract/interface class specifying what needs to be done, along with N concrete classes performing What has been specified seems to me to be a very appropriate way of dealing with that scenario. Other paradigms (e.g., logic programming) may also have adequate means, but if their options are "objects" and "chains of ifs, "I would say that you have a good argument at hand in defense of the use of inheritance and polymorphism.

Answer 2

I begin with the following definition of Paradigm, extracted from Wikipedia:

Paradigm (from the late Latin paradigm, from the Greek παράδειγμα, derived from παραδείκνυμι «show, present, confront») is a concept of sciences and epistemology (the theory of knowledge) which defines a typical example or model of something. It is the representation of a pattern to be followed. It is a philosophical assumption, matrix, ie a theory, a knowledge that originates the study of a scientific field; a scientific achievement with methods and values that are designed as model; an initial reference as a model basis for studies and research.

It sounds like a super complex definition, but it’s not. Basically a paradigm is a suggestion to approach something, a way of thinking. In our case, as system developers, it is a suggested approach to problem solving through computational automation. I started by this definition because it is easy to forget that there is the letter "P" there in the acronym "OOP" that does not necessarily mean "Programming". When I started studying the subject, it was much more common to translate "OOP" as "Object-Oriented Paradigm". Which, let’s face it, makes a lot more sense, since programming is just the act of building - planning the solution of problems goes way beyond that.

My main reason for using (and indicating) an "object-oriented way of thinking" comes from the nailed approach (read: "of the way of thinking").

The structured paradigm is intimately directed to the resolution of a problem through the routing of the solution. That is, when programming, basically it describes step by step what needs to be done for the problem to be gradually solved. This approach is very natural because the computer is much better than we humans in executing precise instructions very quickly. And that’s just it the definition algorithm:

An algorithm is a finite sequence of well-defined instructions and not ambiguous, each of which can be performed mechanically in a finite time period and with a finite amount of effort.

This way of thinking is enough to solve various problems since they can be scripted, and in fact has been used since the first computers were created (either using valves or punched cards). It turns out that as the complexity of the problems to be dealt with grew, the scripts became larger and more difficult to read and understand (by us humans). It must be easy to imagine how hard it is to interpret the function of a sequence of instructions (arithmetic operations on variables, for example) in the middle of a really extensive program (and perhaps devoid of local comments). :)

Incidentally, it is not surprising that many structured languages provide the possibility of creating functions. Maybe you haven’t thought about it until then, but the semantic meaning of the word is this: a function does something important, that is, it has some role (a function! hehehe) in the global resolution of the problem, in an atomic and reusable form. This division into functions allows not only organizing problem routing in a way that is humanly understandable (because for the computer it is all jumps to even memory addresses)but by itself already brings numerous advantages such as reuse of code and ease of maintenance (arguments that are commonly used to qualify OOP, but that do not actually depend on this paradigm).

What OOP is, in fact, is an evolution in the way of thinking the solution to a problem. There is a consideration at a slightly higher level than just the functional character of solving small aspects of a larger problem. There is also the representation of the entities involved. In another issue on the origin of OOP one can observe that there are various inspirations for this way of thinking, and note that the main need is related to understand also:

1. Which entities are involved in the problem area
2. What are the relations between these entities

Entities can be called many forms (classes, frames, it doesn’t matter), but they represent something relevant to the problem and they group (and clearly identify) not only the functions (or methods, or behaviors) but also the data (or attributes, or slots) that are manipulated and necessary for the problem to be actually dealt with.

It should be easy to see that this is a way of thinking that, at its core, is independent of a programming language. You can construct the equivalent of classes in C language using structures with regular variables to serve as attributes and function pointers to serve as methods. And new structures can have pointers to existing structures as a way to simulate inheritance. What many modern languages do is simply facilitate the use of this paradigm, as has already been well put by colleagues in comments. But even if you use C++, C# or Java, there is still in the methods the necessary routing for the resolution of the component parts of the larger solution to happen. Because remember, computers do just that: execute instructions very quickly.

And the advantages?

Having discussed all this (sorry if it was too long - I just tried to be didactic), the main advantage of this way of thinking (i.e., of the object-oriented paradigm) that I see is in the organization of work. As one starts thinking about the entities involved, their roles in the general resolution of the problem and the relationship they have with each other (and that also help in the solution of the problem), it is much easier to build the solution gradually. You see, complex problems have a difficult understanding, and it’s common to notice certain nuances throughout development. An object-oriented design organization facilitates the evolution of the code (in certain cases, just inherit a class - and here I think it is advantageous for you to read regarding the discussion of multiple ifs, which was also mentioned in comment).

It also facilitates maintenance as it is easier for a human to remember the entities involved in solving the problem than their individual behaviors. Imagine that you need to maintain a project of your own, but after many years. If there is an issue related to order printing, it should be easier for you to simply spend your time analyzing code from the Request class than to seek to understand and find related functions in the middle of several code files.

P.S.: Note how anyone who argued that simply organizing functions into closely related files would be, in a sense, using this paradigm unknowingly! hehehe

But remember that not everything is an advantage. As also mentioned in comments, a team that has not studied and does not know the paradigm can spend valuable time learning. The experience (and the large number of questions here at SOPT) indicate that there is a beautiful learning curve involved. In addition, for critical applications where running speed and/or memory usage are important non-functional requirements, the additional computational effort stemming from the facilities provided by OO resources (such as overloading methods and operators, or copying builders) may bring relevant disadvantages.

Answer 3

Usually, if you try to defend object orientation in a company that doesn’t put it as a basic premise, the first thing you’ll hear is: -For what? does not work fuinciona? In team that is winning we do not touch.

Actually, the noodle code has its advantages. It’s easy to do, it’s very fast to develop, and usually, programs that go into production using this "architecture" run frighteningly faster than their puffy cousins.

For you to get a macaroni code that you made is one thing. Another completely different is to put this software in the hands of a new developer. The guy will go crazy. Another problem arises when someone wants to improve this software. That old story...my software sells apples. But now I want to sell grape...

Clarifying the context let’s go to my justifications.

• Dependency of Professionals - Whoever understands a macaroni code is only its creator. If another professional gets his hands on it, he’ll probably spend months deciphering what the other developer did. This creates a dependency relationship between the company and the system developer. This professional becomes more expensive every day, after all the system can not stop and it is not easy to find someone who can continue the project. The subject becomes virtually irreplaceable, which is not good for the company.

• Maintenance and Evolution - As I said before, the software is to sell apples and not grapes. Then starts the gambiarras. You look at the code and you start to find a lot of "flags" and a lot of "if’s" like: if(Uva)...in a little while the software doesn’t handle maintenance anymore. Then they go crazy and rewrite all the code, because it’s quick to do without design standards. The cycle continues and the creator of the software one of these hours is earning a thousand dollars more. And everyone thinks he’s the guy, because nobody’s been able to touch the software. Another important factor is change management. How to manage changes in a software where probably not even the programmer can say what the ramifications of that change?

• Side effects of evolution - Have you noticed that by changing a functionality in software developed outside of OOP standards there are always unexpected errors in other areas of the software? Of course, after all that field you had to remove from CRUD affects another 300,000 areas of the software. These side effects directly damage the company’s business, generating losses.

So the practical advantages in my opinion are:

• OO code is easy to understand.
• An OO project can be easily developed by a team, which does not occur with the macaroni code.
• With OO code it is easy to find professionals who can continue projects
• Allows company employees to take vacations
• They ensure better maintenance and system evolution, since they use "small blocks of functionalities"
• They are less susceptible to side effects, as dependencies are mapped more clearly.

And mainly,

• It ends with the newness of programmers.

Answer 4

This could be a further question for the Workplace than technical. Whenever it involves convincing management we may come across several barriers that go beyond the code or system itself.

Imagining that we will not have these barriers, say, policies within your company that can prevent this, and that the company could allow a more "abrupt" change in a new project or existing project (besides OO, it could be a new language, framework, etc), that your colleagues are also aligned with your thinking, then we can go to the main point of this discussion.

I will try to argue in a less technical way, because you need to align your speech according to your interlocutor. If he argues very technically, he may not understand.

And, finally, I won’t get into the merits of whether or not it’s better than very common procedural approaches like Transaction Script.

The difficulty of putting it into practice

Although the subject of object orientation is always in the "mouth of the people", experience shows that it is not simple to implement it in practice.

If you look at the subject reference books, you will often come across very simple examples, or ones that start from questionable premises (example: using a bank entity as an object) or complex ones (DDD in general).

That is, when we are thinking only of the organization of objects to meet a problem, everything looks beautiful: I create an object Ordem, who receives a Pagamento, that can be done with Cartao, etc..

But when we start talking about Apis entering data, saving information in the bank, validations, transactions, integrations, queues, retentatives, etc., things start to get very challenging and other approaches become more seductive. And this is what we didn’t even get to the challenge of composing the objects correctly (I get there).

So the ideal is to start with a problem simple and isolated. This would be the ideal scenario to propose this to your boss. Preferably, it could be embedded in a new system separate from the others. It is inevitable that there will be a huge learning curve if you haven’t worked professionally with object orientation yet, so this would be a good space to make mistakes and redo some things without affecting what already exists.

But why OOP?

Someone will ask.

Here it will be inevitable to compare the model that works (or "works") with your object proposal.

The most common argument here is to "hit" the current pattern: it’s confusing, disorganized, no pattern, scattered rules, etc. Depending on how the current pattern was implemented, this may help the discussion, but it may not necessarily be true to the standard. Maybe the confusing code in the current pattern is only there because the people who participated in the development don’t want/might/know how to improve.

So I would try to bring the advantages by avoiding the comparisons a little.

Advantage 1: proximity of business

An object organization allows the conversation between business people (Analysts, Pos, etc) and developers to get much more transparent. When speaking that the Pedido gets a Pagamento, this will actually be occurring in the code:

pedido.adicionarPagamento(cartao);

With the team’s effort in trying to use the same business language to model objects (known as ubiquitous language).

If your analyst/PO has some technical baggage, it can even help you with some code decisions if you know how to direct it in your understanding of it.

In other solutions you will see something quite different: maybe a DTO, service classes, validation classes, a repository, mapper, etc. Something more distant from the "reality" of business.

Advantage 2: Code becomes more self-explanatory

Another advantage that I see is that it limits a little the "evil creativity" of developers when organizing the application. As the searchlight of the application are the objects, you will always have a good notion of where to implement a new Feature or make a correction. For example, if you have any validation on the card part, you will search for objects related to Cartao.

This also leads to a natural movement of organize your system by packages according to business and not by Pattern.

However, in other solutions, this rule may be in some service class, validation class, entity, etc.: Is it in the CartaoService? RegistrarCartaoService? CartaoValidation? ProcessarPagamentoCartaoValidation?. Anyway, you can use other class names that you think have more meaning, but with the growth of system code this tends to quickly become a problem without a more rigid and clear control for class names and package organization.

Advantage 3: there are simple approaches to applying OOP

You don’t need to rely on dense DDD books to create a robust object-oriented application. There are approaches today, such as the Elegant Objects, which allow the use of object orientation without having to completely isolate its objects, requiring less code "infra" to save information or perform integrations. However, violating some principles considered "sacred". It also brings some welcome practices to the code, such as avoiding null. But it’s not a recommendation, because he has some views polemical. It’s just an example.

I could think of others yet, but I believe this is a good start.

Show me the code!

Often, it is necessary to literally draw so that people can understand your idea, what you are offering or saying. This is perfectly normal, some people are more visual. In the world of programming this can be achieved with a functional implementation.

Choose some simpler project functionality that already exists, and implement it using OOP. This will allow a comparison between the current model and the object-oriented model you want to propose.

And if he refuses?

You can have the best arguments in the world and not be able to convince your boss. Sometimes, it’s not what you say, but how you say it. Or there may be situations that run away from even his control that prevent this and that he can’t tell you.

Finally, ask him to explain the reason for the refusal if possible and, depending on his answer, ask him what he would need to do to make this possible.