Hi all,
Iv began learning PHP and see the letters OOP coming up on various sites etc, I was just wondering if someone can explain is PHP an OOP language and by learning PHP am I developing my OOP skills or is there different things I have to learn in PHP to have experience in OOP? Im just kind of confused if this all ties in together. Thanks all.
How will it not result in more maintainable and organized code? It takes the DRY principle to a whole new level. Albeit it is pointless using on small projects.
I’m not sure who’s general opinion you are considering when you make this statement, but in a professional environment using OOP for application level development is a necessity.
I agree with a number of the comments which have been made. OOP is pretty much mandatory for larger applications. Classes are simply too powerful a concept for saving your sanity, and they respect the time you’re putting into the construction phase of development.
For small items (one or two lines of PHP), there is an argument to be made that it’s handier just to write it and be done with it using procedural style. It avoids the OOP construct of having to find an abstraction to shove every single piece of code into. If it works, great. However, we all also know that small things tend to mushroom. AND if you have a small piece of code (even one short line) that appears on several different pages, whether you are using procedural or OOP programming, you’re in trouble if you don’t encapsulate that.
I do strongly disagree with the idea that you “ought” to learn procedural programming first because its easier. In many ways OOP is more natural, especially when you’re in application design because it more closely conforms to the real world things that you are dealing with in your program. This is one of the key reasons that procedural programmers developed the new language features as they did in creating OOP. What is not natural is trying to go back and forth. There are many developers who switch languages easily from PHP to C# to Java without batting an eyelash. I don’t know anyone who switches between procedural and OOP. Once you get a style it is hard to switch.
How will it not result in more maintainable and organized code? It takes the DRY principle to a whole new level. Albeit it is pointless using on small projects.
The point is, you can write bad OO code. PHPMailer is a good example, which SwiftMailer made huge improvements in more throughly decomposing the object.
I also disagree with the statement OO is pointless on small projects. For starters what is small. A simple one liner, in which case OOP is not useless but entirely impossible as a class declaration requires several SLOC.
That is akin to saying using a framework for a 50 line CLI script is pointless. Why is it pointless. If that script grows (which software has a tendancy to do) and more switch statements are added to segment functionality, refactoring that code into individual controller actions would certainly clean that code up.
I’m not sure who’s general opinion you are considering when you make this statement, but in a professional environment using OOP for application level development is a necessity
I assure you software software has been writing for decades without OOP. Drupal is a good example and its PHP and objects were available but used sparingly.
Just to note, I am a huge OO advocate. With the exception of my bootstrap and a few helper functions, everything else is an object. I am not suggesting we not use objects. I am just countering any statement that sounds zealous.
I will always play the devils advocate 
Cheers,
Alex
I think his point was that it’s not just the use of objects which improve code, but the OOP methodology overall.
PHP supports an object model, similar to that of other languages (Java, C#, C++, etc). You do not, however have to write code in OO fashion. You can write procedural code in PHP as well. Many projects do, Drupal (very well known) comes to mind.
The general opinion, is that objects will result in more organized code, more dynamic code and more maintainable. This is a myth.
You can write equally horrible code using objects or functions. There are volumes of books out there which suggest best practices.
If your serious about OOP learn the basics and syntax in PHP but don’t think your finished once you can write classes (thats the easy part). The challenge comes with years of trial and error, arguing and debating best practices with others and eventually working your way to project lead on a new project and being charged with responsibility of architect.
If the projects because you fail to deliver or junior developers leave because you cannot manage a project or the code is hard to maintain and a headache to work with, thats a good a sign you need to brush up a little more.
On the contrary, if it suceeds and everyone is happy, consider that a great success.
Cheers,
Alex
PHP isn’t technically an object-oriented language as such, but it is a language which allows for object-orientation, rather than forcing it. PHP is more of a procedural language generally.
By learning PHP, it will be a while before you really pick up on OOP because you need to learn the basics first. However, that’s probably a good thing - if you start with a language such as C# or Java, you have to learn the language and OOP at the same time, which can lead to confusion and a steeper learning curve.
I suppose the beauty of PHP is that whilst a pro can create an application which is efficient and adaptable/plugin-able (most likely in OOP but I have seen it done procedurally), a beginner can create an application which does the same thing - without the efficiency and plugin-ability, but it works.
The main difference is, with OOP (if you know what you’re doing) you can cut down the amount of code required. For example, an application with 10,000 lines in procedural-style coding can be converted into an application with 2,500 lines using OOP.
At first, however, most programmers can’t improve application efficiency using OOP, until they have learned OOP methodology. It’s one thing to use objects to assist your application - its another thing to use objects as the actual building blocks of your application.
Typically (not always), the first part of learning OOP is usually using an object to hold data, for example a class which replicates the structure of a database table, and can hold a row of information.
The second part is where you start to use polymorphism and composition to connect your objects and use similar objects in the same way.
The third is when you start creating a way for your whole application to run under control of specific objects.
I think the most fun with OOP is building something that has no real relevance in the real web-programming world. For example, objects representing real-life things, and pass it to a chain of objects which manipulate it in different ways. Of course, that just hammers in the OOP methodology but it teaches design patterns in a more exciting way.
OOPs strengths - its design patterns, multiple class instances, polymorphism, encapsulation, abstraction etc - are more suited to a large scale application. However, these applications can also occur in smaller scripts - there is just a higher probability that it will occur in a larger scale application.
At the end of the day. Use the programming paradigm that is best suited to the task at hand, whether it be procedural, functional or OOP.
I stand by my point that it makes large scale applications much easier as it is a great way to reduce dependencies.
Drupal is a good example and its PHP and objects were available but used sparingly.
Drupal has been around much before PHPs OOP systems were strong enough. I believe this is Drupal greatest shortcoming, simply because if I wanted to alter something trivial in its behaviour, I have to rely on previous/other developers hooks functions.
True, in a way.
Whilst using OOP doesn’t automatically result in better code, understanding OOP gives you the ability required to build such code. The best possible OOP code will always be more organised, more dynamic and more maintainable than the best possible procedural code, for most projects.
You can refactor bloated OO code using nothing but functions and reduce the code base just as well. That is the responsibility/experience of the developer not the tool.
However, this is usually using OOP principles. After getting an understanding of OOP, you can usually write better procedural code too. I suppose if you were an expert in procedural coding, you would have efficient and flexible code - but I’m talking about the average procedural programmer and the average OO programmer.
I’ll put it this way - I’ve yet to see procedural code which makes me thing ‘wow… that’s nifty’.
For example, an application with 10,000 lines in procedural-style coding can be converted into an application with 2,500 lines using OOP.
That is a myth. You can refactor bloated OO code using nothing but functions and reduce the code base just as well. That is the responsibility/experience of the developer not the tool.
This misconception is probably due to the fact that most experienced OO developers started in procedural langauges like C and made the gradual switch to C++, C# and Java. Using years of experience in combination with a powerful new tool would obviously allow someone to rewrite code making it more effficient and compact, flexible, etc.
Cheers,
Alex