Help
So let’s start from the top with an OOP FAQ – this isn’t going to explain the how of OOP, nor will it be couched in the traditional terminology of OOP (i.e. bringing up subjects like encapsulation, polymorphism etc...). It took me a long time wading through that jargon – so I’d rather this blog tried to address the subject in layman’s terms.
Q: What is OOP, and how does it differ from Procedural coding?
A: OOP is a large subject, so it’s a bit hard to boil down into one statement – but I’ll give it a go. OOP is a coding style that treats software as if it were a collection of components that can be combined to produce the application. Think of it as building a hi-fi separates system, each component does a specific job, and you can combine them to make a complete hi-fi. The hi-fi as a whole might need an amp, or a turntable, but you can mix and match the bits you want as time goes on.
Turning to a completely different analogy - procedural is more like the rain falling on a rooftop – the script goes one way or the other depending on a series of conditions until it reaches the bottom of the page. Code tends to become mutually entwined so it becomes increasingly difficult to change one part of the system without changing all of the code and tracking the flow of our metaphorical raindrop. A bit eclectic I know, but that's how I think about it.
OOP programmers tend to focus on designing an API (Application Programming Interface) whereas Procedural programmers tend to focus on aspects like flow, performance and speed.
Q: What’s so good about OOP?
A: OOP embodies many principles, perhaps one of the most important of which is DRY (Don’t Repeat Yourself). For each task in your application (i.e. sending mail, reading XML files, inserting data into the database) you would write a reusable class. In procedural, while you can wrap up some repetitive tasks in functions, you can often find yourself repeating bits of code from page to page. With repetition come errors, as a change in one part of your code might require changes across the whole site. OOP focuses responsibilities for types of task into classes – so when you need to change something, you only need to change one component in your system.
Q: Are there any drawbacks?
A: Creating objects inevitably imposes a performance hit. This can be mitigated to some degree with caching and diligent unsetting of unused variables – but in general, procedural scripts run about 10-20% faster than your average OOP script. Having said that - there are other performance gains from using OOP. In terms of project maintenance and maintainability OOP has some definite gains (although these are not evident to the user). Also, OOP applications can become “over-designed” or hard to follow as developers create complex object relationships.
Q: When should I use it?
A: There’s no reason any project should be written exclusively in one style or another. Plenty of great applications are written in both styles, and as many are written in a combination of both.
My personal rule of thumb is to use an object when a bit of code is so useful I want to develop it into a full blown API (i.e. an image editor, a database layer, a feed parser) or when I notice that I’m repeating the same tasks again and again. If it's a small 5 page brochure site, I might use an Object class I've made previously, but I probably wouldn't go to the trouble of writing a new one. Conversely, if the project is a large enterprise level social network, I'd use OOP to make the project more manageable.
Q: I understand all that, but I can't seem to get started with it...
A: A good way to start is to think about some of your existing code, and trying to identify a common, recurring task - then write a class to take care of that task which you can use for future projects. My first class automated some site configuration - and I've slowly added to it for general purpose jobs like loading css/js dynamically or handling errors.
To summarise:
OOP does not provide any new functions for those typical daily jobs (i.e. form validation, sending mail, interacting with a database) - rather it provides a methodology for organising your projects and creating re-usable tools.
(Edit: I've moved a code example out of this post and into a separate one so I can build on it).
Q: What is OOP, and how does it differ from Procedural coding?
A: OOP is a large subject, so it’s a bit hard to boil down into one statement – but I’ll give it a go. OOP is a coding style that treats software as if it were a collection of components that can be combined to produce the application. Think of it as building a hi-fi separates system, each component does a specific job, and you can combine them to make a complete hi-fi. The hi-fi as a whole might need an amp, or a turntable, but you can mix and match the bits you want as time goes on.
Turning to a completely different analogy - procedural is more like the rain falling on a rooftop – the script goes one way or the other depending on a series of conditions until it reaches the bottom of the page. Code tends to become mutually entwined so it becomes increasingly difficult to change one part of the system without changing all of the code and tracking the flow of our metaphorical raindrop. A bit eclectic I know, but that's how I think about it.
OOP programmers tend to focus on designing an API (Application Programming Interface) whereas Procedural programmers tend to focus on aspects like flow, performance and speed.
Q: What’s so good about OOP?
A: OOP embodies many principles, perhaps one of the most important of which is DRY (Don’t Repeat Yourself). For each task in your application (i.e. sending mail, reading XML files, inserting data into the database) you would write a reusable class. In procedural, while you can wrap up some repetitive tasks in functions, you can often find yourself repeating bits of code from page to page. With repetition come errors, as a change in one part of your code might require changes across the whole site. OOP focuses responsibilities for types of task into classes – so when you need to change something, you only need to change one component in your system.
Q: Are there any drawbacks?
A: Creating objects inevitably imposes a performance hit. This can be mitigated to some degree with caching and diligent unsetting of unused variables – but in general, procedural scripts run about 10-20% faster than your average OOP script. Having said that - there are other performance gains from using OOP. In terms of project maintenance and maintainability OOP has some definite gains (although these are not evident to the user). Also, OOP applications can become “over-designed” or hard to follow as developers create complex object relationships.
Q: When should I use it?
A: There’s no reason any project should be written exclusively in one style or another. Plenty of great applications are written in both styles, and as many are written in a combination of both.
My personal rule of thumb is to use an object when a bit of code is so useful I want to develop it into a full blown API (i.e. an image editor, a database layer, a feed parser) or when I notice that I’m repeating the same tasks again and again. If it's a small 5 page brochure site, I might use an Object class I've made previously, but I probably wouldn't go to the trouble of writing a new one. Conversely, if the project is a large enterprise level social network, I'd use OOP to make the project more manageable.
Q: I understand all that, but I can't seem to get started with it...
A: A good way to start is to think about some of your existing code, and trying to identify a common, recurring task - then write a class to take care of that task which you can use for future projects. My first class automated some site configuration - and I've slowly added to it for general purpose jobs like loading css/js dynamically or handling errors.
To summarise:
OOP does not provide any new functions for those typical daily jobs (i.e. form validation, sending mail, interacting with a database) - rather it provides a methodology for organising your projects and creating re-usable tools.
(Edit: I've moved a code example out of this post and into a separate one so I can build on it).
3 Comments On This Entry
Page 1 of 1
Recent Entries
-
-
-
A layman's OOP (PHP) FAQ
on Feb 23 2010 01:55 PM
-
For budding developers...
on Feb 23 2010 10:16 AM
My Blog Links
My Picture
I even learnt a thing or too myself!
I'll be checking back for more.