60
I am learning PHP, and by the example I have seen on the internet there is a mixture in the coding of programs, of object orientation and structured procedures.
Is that really common or am I mistaken?
If PHP is an object-oriented language, how interesting is this mixture?
45
You’re not entirely mistaken, but you’re a little.
Informally we can say that it is mixed even, but almost all so-called object-oriented languages do the same. The bulk of the code is procedural (or more precisely, imperative). Object orientation enters another level, more into code organization. It acts more on the data structure and where it will place the algorithms than on the algorithms themselves, which are imperative.
Some say OOP isn’t even a complete paradigm.
In the PHP documentation itself there are several examples of writing the same code with procedural mode and OOP mode. We can accept this definition, but strictly that is not quite OOP. PHP is a language that does not usually follow the correct definitions very well.
Basically what they mean there is that you can choose between: 1) passing an object as a parameter to a method; or 2) using a syntax where the method is invoked by the object. What in practice gives in the same under the cloths. In the background this last case the method will only have an extra parameter called $this that is hidden. You are just changing the place parameter.
This has some advantage with tools (IDE for example) that can help you encode and analyze data already knowing what it is. Other than that, there are no real advantages. Individually there may be some secondary advantage that was best solved in the case of object-highlighting syntax, but it was something additional that they took advantage of and solved when they were creating this extra layer. There may be a downside to generating an extra layer.
Mixing syntax doesn’t cause problems, at least it shouldn’t. Neither should paradigms. The mixture is always good if it better solves the problem, purism is dogmatic, is to force something by taste and not by need.
But using this syntax cannot be considered object-oriented programming. At most, whoever created these classes programmed it object-oriented, not who consumed it. Even this is complicated to say because the use of classes does not define that it is object-oriented programming. This paradigm even requires the presence of classes.
OOP is something much more complex, and deep down most programmers have no idea how to program this way. This includes those who say they program object-oriented and actually don’t, or do it all wrong. This is explained by Dunning Kruger effect.
OOP is a methodology to better organize the code and promote its reuse in a specific way.
Not everyone agrees with all definitions, including the author of the term says that the definitions they use are wrong. Although the use of OOP somehow predates the use of the term.
One of the most accepted forms is that OOP occurs when there is inheritance, polymorphism, and encapsulation. Abstraction and other concepts are usually included in some definitions, but these three achieve more consensus.
Most programmers who say they use OOP do not use or do not know how to use the fundamental concepts correctly. So we can say that this person is actually using OOP?
In general they only create classes, which can suit encapsulation if it does the right thing. But this is possible to do in any paradigm in one way or another. Deep down, when people do this they are programming in modular paradigm.
In that question (read mainly the part of OOP, it is important to understand) I even say that one of the things that most boosted programming is modularization, and one of the ways of modularizing is encapsulating. This is not exclusive to OOP. In fact it is something very important.
Precisely because of the heritage OOP is a hand in the wheel to represent hierarchies and complex relationships between objects. Great for Guis and some types of games (and other types of application, of course, I won’t quote everything). But it’s not so good for all problems.
OOP really helps to organize large code bases manipulated by large teams. But OOP has a cost too.
In scenarios where hierarchies are not so important, the relations are not so complex and the development is done in an individualized way or by very small team, or at least the application is developed very fragmented (natural modularization, typical of PHP applications, since they are scripts), OOP, really, it’s not that useful.
And it’s even less so when you don’t have a deep understanding of what you’re doing. And what we see right here on this site is that people make a lot of mistakes, some grotesque ones. I make mistakes, even having studied the subject a lot, it is not easy to get right with this paradigm, and it needs to be right to take advantage of it well, it is not easy to correct later if done wrong in the beginning, although some people believe otherwise (if refactoring solved so well then doing procedural would be no problem either).
OOP bureaucratizes development. Whether this is good or bad depends on each case and I will not take a stand.
Sopt itself uses object-oriented so-called language (though it is a lie to classify C# as such), and his engineers, some of the best in the world, have consciously chosen not to use this paradigm for its construction, did not follow folklore, and they benefited a lot from it. If this project, which is anything but simple, is better off without OOP, why do you think your simplest web project will benefit from it?
PHP iswas a language of script, isit was a language without ceremony, it shines in it, if not use so much cacareco that they put after.
It executes small snippets of code at a time and dies. These scripts do not last in memory, do not carry everything the application will do, executions are more watertight.
It is much easier to administer this type of code than in an ERP system monolithic, for example.
PHP makes a modularization in a natural way, you only use what you need for that momentary context. You include what you want extremely easy, with nothing OOP.
PHP is not object oriented. It is originally imperative/procedural and more recently adopted additionally OO concepts.
These language extensions to manipulate OOP are great for transforming PHP into a general purpose language, but help very little in the domain where it succeeds, the web.
These extensions make it easier to use OOP, but it was possible before. Since people don’t understand what OOP is, they thought it wasn’t. The tools just got more obvious.
Actually PHP is one of the easiest languages to adopt OOP even before there is specific syntax for it. All class system, inheritance, polymorphism, etc. of PHP was developed upon the arrays associative (I’m not saying he uses exactly the same arrays of the language, as Javascript does, is just something very similar) and it is not difficult to simulate all OO concepts using this mechanism (has naive example in this question). It just didn’t have the most convenient syntax and already well recognized in other traditional languages that implement classes.
I’m one of the few people who ever used PHP for a non-web application, where the whole code ran together for hours, so the code was more "together". And even in this case I didn’t miss anything object-oriented, imagine in ephemeral codes that is the typical case of web applications.
Most PHP code that uses classes I see around wouldn’t need to be written this way and wouldn’t have harms using pure procedural, as long as it’s done right. Programming right is necessary in any paradigm.
Many say it is more organized. I even agree that OOP can help to organize more code for those who can’t organize otherwise. I understand that cake recipes in OOP are usually well organized and recipes that do not use OOP are usually more disorganized, because they were made at a time when people did not dominate so much what they were doing, but it only helps if one is a recipe follower.
If the programmer will create programs on his own, he will have to learn to do right, and can do organized in the two paradigms, in most scenarios.
The famous, general and most useful design patterns and architectures - type MVC - can be very well applied in OOP or procedural.
Many Also famous design patterns only work for OOP. But they exist to solve the problems that OOP began to impose (complementary information in the comments by rray). The abuse of these specific standards has become meme.
Others exist because the language is static. Dynamic languages, such as PHP, are much more flexible and require fewer "artificial" design patterns. They want to "end" this too (I even like static language, but PHP is what it is for being dynamic).
Principles were created to help people use OOP in the right way, but most people don’t know when to use it and when to leave it alone.
All this adds complexity to the software. When he needs it, great, this complexity helps software that needs to be complex be easier to maintain. If I didn’t need it, it was just a complication.
I agree that OOP helped create the frameworks current ones that are so successful. In fact this paradigm helps this type of software. I even question a little the use of them. Not that I don’t have leverage, they just don’t solve everything. And it’s common for people to adopt them because they don’t know how to do things right, the reason is wrong.
But in more common codes I see few advantages in its use.
Contrary to what some people believe, OOP is full of flaws, well-stocked, and does not solve all problems. The question is when it has more advantages than disadvantages, and choose its use consciously, and not because it has heard (heard from someone who is passionate about methodology and often makes money by spreading it, heard it is good for you and will solve all your problems).
No one has ever presented proof, or even empirical evidence, that OOP gives more productivity than other paradigms. On the contrary, there is at least one study showing that there are no gains. Other showing that languages do not benefit fundamentally from this paradigm.
But my favorite analysis is of Paul Graham when he defines mediocrity as a determining factor for the success of the paradigm.
OOP does not reproduce the real world as some preach.
Note well that I am not saying that OOP is crap that should not be used. Some people tend to see only this part of what I say and not the weighting, because they do not consider the use. They think, "Either you’re a friend of OOP or you’re an enemy". I use OOP where you need it.
There is a widespread problem of understanding what computing is and the scientific process as a whole. Then one reads a book that gives a vision, buys this vision and goes on to repeat it without knowing what he is talking about. And I hate academicisms. And the best programmers I know are not trained (this has changed a little).
There’s a article that gathers several critical grounds on the use of OOP.
I’ve made several simplifications here. The intention is not to write a thesis, it is to warn and try to make the person reflect and search for more information, even asking new more specific questions, even questioning what I said, so other people can write and give a plural view. It’s bad when you blindly accept a person’s vision, even if it’s my vision. Distrust them, too. Be proactive, just don’t be stubborn, only you lose (if the people who hire you, they lose by default).
Use both. Learn what has advantage in each and take advantage of the advantages. Avoid the golden hammer.
About languages that gave support to OO there at the beginning(when?) it seems that they sold better, the concepts defined by Alan Kay were practical transformed into simple functionalities to use as the 3 that were cited in the answer beyond state and more flexible scope(global local variables X), although some mechanisms already exist as in that question about polymorphism in procedural language. If I understood correctly what happened was, languages with simpler resources to use and its use should follow the OO paradigm. It seems fused, as if the mechanisms do not ...
As if the mechanisms didn’t exist without the concepts. Another point they sell is procedural focuses on solving the problem but at low level OO equation relies heavily on high-level abstractions calling low-level abstraction to solve problems('technics', bits&bytes). It is also possible to create certain abstractions with procedural and even apply refactoring as 'compose method'. Apply the concepts of OO in examples carro.motor.funcionar() it is quite simple, at the time of playing this for a real problem balancing the level of abstraction and where it to stay is a little more complicated.
I agree with the 1st. comment fully. I’m not sure I understand the statement. Are you saying from the myth that procedural is more concrete, lower level? This is actually a myth, you can abstract well in procedural. Oop has some better mechanisms for some types of abstraction. But to use them you need to understand how to do this right. I see every statement here on the site of people who "adopt" OOP... They don’t have the slightest notion and think they’re right. Creating abstractions is certainly not an easy thing, even to name variables that is still a creation of an abstraction.
About "procedural being lower level" this is seen in books generally and argue that "OO is simpler by trying to imitate the real world". Another point about PD that almost no one comments is in the GOF book most of them are applied to solve GUI problems and the examples are in C++ and was published in 94, before that the standards should already exist but were not popular and maybe had no names. GUI problems in that decade seemed to be the bug.
OOP is bad at imitating the real world :) This is part of Mkt. Earlier said ñ were necessary pq ñ used OOP q created the problems q they solve :) Of course there is something that is universally useful. And there is a problem because the language is static. OOP was adopted because of GUI, then there were people who thought they should use everything. The Gof organized and popularized some of them.
My votes are back, +1 for the reply and thanks for the clarifications.
In an object-oriented application that uses PHP, can you say that the initial execution will always be procedural? For example, the Symfony framework is object-oriented, but has the "app.php" that starts and ends the cycle, where everything is initialized. What I mean is that an application that uses PHP always depends on some procedural code, right?
@Filipemoraes I believe so, I don’t know him to say. In fact even OOP at the bottom has a (not so) little procedural, people expect a purity that does not exist.
17
There are many internet examples out of how to use the language wrongly, such as date formatting, usage of obsolete functions, code vulnerable to sql Injection etc.
The language of support to object-oriented and procedural paradigms, the definition of which to choose is the responsibility of the programmer. Procedural and OO are ideas of how to organize the code or is it possible to program procedural in languages '100% OO' or 'pure''.
+1. With the obsolete codes that are disseminated on the internet by the PHP programmer do not seek to inform and update themselves. And I say more: Tutorials in PHP in Portuguese are (in most cases, not generalizing) bad. So I developed the habit of researching things in English (that’s how I met SOEN).
Browser other questions tagged php oop encoding-style paradigms procedural
You are not signed in. Login or sign up in order to post.
PHP is definitely not an OO language, it is getting these options recently. The question is, if language allows the 2 paradigms, nothing smarter than using the best of each where it suits. The rest is fashion. In fact, there are several languages that allow this. The one I most use, which is Harbour, OOP use for GUI and some other modules, and the "executive" part I do procedural. Save time, stay organized and readable.
– Bacco
To understand what object orientation is, I recommend the answers of mgibsonbr and Luiz Vieira in this question: http://answall.com/q/55493/14584, which are the best source of OOP definition I know here at Sopt. Note for example that inheritance is a very unimportant detail of this paradigm and is far from defining it. Frameworks in static typing languages benefit from inheritance. Other than that, heritage only gets prominence in OOP in beginners' handouts and dubious design systems.
– Caffé
A definition of OOP that is very much scrutinized on the Internet: https://en.wikipedia.org/wiki/Object-oriented_programming where everything that is in my answer speaks. I see that some people confuse OOD, OOM, or something like that with OOP (which clearly indicates some characteristics needed to fit the paradigm). Even if the definition were different, this is what almost everyone uses, so everyone can be wrong (not that I think so), but it’s what everyone understands.
– Maniero