How do I know if I am programing procedurally in object orientation?

Question

How to know if I am programming in a procedural style in an object-oriented language?

Answer 1

TL; DR

To me if you’re not using the pillars of OOP you’re not doing OOP. And for me almost every project that says OO (not programming) in the background calls OO because it is fashionable. Some people disagree with this. Cohesive and unmatched projects are always desirable and this can be obtained in the procedural, especially if you apply modularization, people take it as something of OOP simply by not knowing paradigms, just memorize the cake recipe they find around.

Detailing

I already answered about procedural programming. We try to answer what it is object orientation (about the term can help). Note that there is even a consensus of what this is and everyone thinks that its definition is correct and that of others is wrong. Be sure to see about modular programming because I’ll talk about it. How is there confusion about structured programming in other answers read also (plus).

I like defining the title of this question: Meaning of "code acting on data" and "data controlling access to code", I think this question can be asked for you to identify what you’re doing, I don’t know if it helps that much, but it’s good. And a analysis comparing both can help answer quite broadly.

If you want a practical example of analysis have a question: My code is object-oriented?.

So telling you what is OOP or not depends a little on who’s telling you. That’s the reason I think no one can give a good answer. Maybe if you follow the pillars of OOP be a form. Some will say no. Some will confuse object-oriented design with object-oriented programming. Get more confused? It is. One of the reasons I abhor UML is because while designing it uses terms and preaches different things what people use in programming, including because it disregards performance and specific characteristics of the technology used.

There are chains that preach certain rules and others that preach others. For example the controversial use of getters and setters (Yeah, you gotta read 'em all links there to understand well), just to quote an example.

A common mistake is mixing abstraction with encapsulation. I did this a lot myself and I need to review my answers to see if there is anything wrong yet.

What many make a mistake is thinking that using a class is object-oriented programming. Class by itself is a simple data structure that has something similar in non-imposition-oriented languages. The way you create the class will define whether it is OOP. A simple class at most is a modular procedural programming. E OOP does not require class.

So you can see that the least voted response talks about things without compromise with accuracy. She’s not strictly wrong, but it doesn’t mean anything.

The most voted answer (until the moment I write here) gives some code style rules (even good in general), but that has nothing to do with OOP, you should follow that in procedural programming as well. Including what else you have to understand to ride a good design code is about cohesion and coupling, that is the origin of SOLID (it is only a different form of marketar the original concept, is a "Noodle tip") and the first items of the answer is then summarized in the latter when it speaks in SOLID. SOLID is not the same as OOP. The answer also says nothing that helps.

The latest answer is full of errors:

• She thinks that having objects is something unique to object orientation, and it is not.
• Speaks in exchange for messages, which is not a mistake per se, but today no one shows thinking about it, it is a theoretical concept that has been lost because it makes no difference.
• Having an object graph has to do with data structure and not with OOP.
• A sequence of steps is something about imperative programming and not procedural.
• The rest of the paragraph without a clearer definition means nothing.
• Already Linkei something about cohesion and coupling, this is much older and is something applied to OOP or procedural or modular, is not unique to OOP, is concept of design systems (and need not be programmed).
• Any complex project demands significant effort, the problem of OOP is that if you get it wrong in design it is not so easy to fix afterwards (I already answered the AP about this I did not find in which question was).

I think the presence of tag programming-structured may have helped in the confusion.

Pure procedural today is not much used except in languages of script since there is no complexity and OOP without complexity does not make much sense (I speak of this in one of these links). In general we use procedural with modular. Then it becomes more difficult to see differences because the module can be a class.

Some people are so dogmatic with OOP that if you do as they want you will have an ideological code and not always meeting the real demands of the system.

If people don’t even understand what all this stuff is, do you think they’ll apply it right? Oo is something so ill-defined that people use the term without even knowing if they’re doing it.

Tips to evaluate

Some people say that the fact that you access the methods by the object is OOP, something like that:

objeto.metodo()

As opposed to this procedural:

metodo(objeto)

I put in the Github for future reference.

Swears that only this detail is object oriented programming?

Others say it’s almost that, but looking at the class side, they say it’s the methods that are close to the state. In fact it is a unique way that the "OO Paradigm has, so it could, but only that defines? Maybe. But some tend to put things together that shouldn’t be there. That is why they started to create rules to make smaller objects, so small that it is clear that the cohesive object is practically without objects (having some of course, in all paradigms there are objects).

But people talk a lot about doing object orientation the right way. There is a set of rules that people talk about, not all are consensual, but essentially all are rules of good design that must be applied in any paradigm. Again, the fact that people don’t understand this says a lot how they learn in a very crooked way.

Some say it is to simulate the real world, but today many people consider it silly, even because it means little, besides not being able to do it, the world is much more complex.

Some say that only encapsulation matters, because Alan Kay defined it that way. But even he admits today that what he described and called object-oriented is actually message-oriented. And out of OOP it always existed and called itself abstraction. And there has the fight about being valid to encapsulate with getter and Setter or not.

Probably object-oriented programming is utopian, so everyone has their own way of accepting it.

What I’m sure of is that many people do design very bad because they only know how to follow the rules that don’t help you at all, they just memorized them and didn’t understand the motivation.

Completion

OOP is not understood by people and this has to do with how the subject is taught and how the concept was created. Much of what people believe to be OOP is actually only good design code, when in fact it is a design bad but people think it’s good because it decorated the wrong cake recipe. That’s why I always finish my lectures with:

A lie repeated 1000 times does not make it true

This has to do with the idea propagated by Joseph Goebbels. I’m not saying that proponents of OOP are Nazis, see? P

I know you can answer it better, probably by showing examples, maybe one day I will, but I had to answer here at least to make it clear that it’s not as simple as some think to determine it.

Answer 2

It is difficult to say what is right or wrong, because everything depends on a context, however in object orientation there are some topics. Some things that can help are:

• Avoid giant classes (also known as God class).
• Separate parts of software into components with a well-defined responsibility.
• Create objects to represent the parts that make up a project.
• Use composition to make objects work together (Dependency injection is a great practice to do this).
• Study the SOLID principles.

Anyway, there are several topics, I mentioned some that I think are important. Start by trying to understand the principles and be critical of your own code. Object orientation is a complex and very conceptual subject, you must always be studying.

Answer 3

(reflection) My idea is procedural or object oriented when coding?

I understand that you want an orientation for your use while programming, and suddenly you’re wondering, am I programming precedurally or compatible with the object orientation paradigm? You want to know whether what is coding, at a given time, for a given "chunk" of code is object-oriented or procedural, or was "mastered" by what strategy. It should be clarified that, while programming, it is also performing detailed project (some say low level design) and the question makes perfect sense. In addition, the answer below is above the lexical or syntactic level of the code produced, that is, it focuses on the semantics of the code in question, instead of the constructions offered by programming languages.

• If you are not using objects and your code is not being organized by exchanging messages between them, then you are probably not actually using POO. Probably, in your thoughts, there is no graph of objects among which responsibilities are adequately distributed.

• If you’re thinking of a sequence of steps that solves a particular problem, an algorithm, a flowchart, and follows this script, then you’re probably programming procedural. You follow a recipe, organize your code into routines, and even if they are part of the same class, the routines are there almost accidentally, just divide the recipe into smaller parts.

• If the cohesion is low and the coupling is high, then surely does not make effective use of OO.

Finally, note that the effective production of an object-oriented project demands significant effort. Maybe someone can do this "naturally", but it seems more likely to be the result of an intentional effort. The intention is to clarify that this is not a simple choice, between one and the other, there is a mental effort to be carried out and, depending on it, the corresponding code will be closer to a procedural or object-oriented code.

Answer 4

When you call a process directly without sending a message to a specific object so that it takes care of it you are being procedural.

When you touch properties of an object outside the class of the object itself you are being procedural.