Related
I have been using regular PHP for some time now. My formal code training is zero. Whatever I've learned I've found here, on the PHP documentation site, the MySQL documentation, etc.
I write PHP from scratch. I use functions for tasks that re-occur, I apply MVC to write more maintainable code, and I recently wrote a nice little library with some of my functions so I can save time in future projects. Long story short, without being some sort of guru, I have a decent relationship with PHP, and so far it seems to get things done for me.
So my questions are the following: Why should I start writing object-oriented code in PHP? How will it make my programming life better and why is it better than the traditional way of doing things?
OOP was made to make programming languages more similar to real life.
What does that mean?
We live in a world of objects. You are an object (Person), you live in an object House, that House object (as well as any other House object) has an House::$address and House::$number, your house probably contains other objects such as LivingRoom and Kitchen. The Kitchen can hold Oven and Stove and Refrigerator, which are all extensions of the KitchenAppliance object.
OOP programming takes that approach, and incorporates it into the programming world.
How does it help me?
Well, there are several things:
It makes your code more maintainable. Instead of dividing your program into tasks (functions), you divide it into objects, if you think of a database connection as an object (meaning, there can be multiple database connections, they share methods and properties, but each is preformed on a different instance), it makes it easier to understand and maintain.
It makes your code more readable. You define an object with the class decleration, and then call it with the new ClassName() keyword.
It allows for extensibility and flexibility. Just like KitchenAppliance can be extended into Oven or Stove, so can your objects and classes.
Summary
OOP programming comes with many advantages. It requires a slightly different way of thinking, but eventually, it's worth it.
You have received a lot of comprehensive answers, so I will use one argument: design patterns. (http://en.wikipedia.org/wiki/Software_design_pattern).
You can find tones of solutions for commons problem, which can save your time and improve quality of your code.
Some design patterns examples:
Strategy pattern (http://en.wikipedia.org/wiki/Strategy_pattern) - for using different alghoritms/solutions in class without changing it
Observer pattern (http://en.wikipedia.org/wiki/Observer_pattern) - you can invoke different actions (and register them during execution) - when state of object changes.
Decorator pattern (http://en.wikipedia.org/wiki/Decorator_pattern) - you can extend your object dynamically, and use new objects in same manner as old.
Franky speaking, if you want to better understand OOP, you have to:
Learn or understand common design pattern.
Start using unit testing, you will find out that lack of dependency injection can be real pain in bad architecture.
learn and understand OOP principles, like SOLID http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29.
Without this you will be using functions encapsulated in classess, like in namespace, not OOP.
For sure you can write your code without OOP and try to implement designs/patterns like MVC without using just a single object.
I don't want to answer why to program in OOP. This you could read in e.g. on this Stack Overflow question.
I think you want to know, when and why you would fail with your coding behavior:
This would be at the moment when you try to work with another person together. The other programmer would never find your code readable. He will take a long time till he understands how your software works.
I think it's hard to separate tasks in your code for teamwork. How are your files separated, and how is the naming convention? You have to solve this by your own and don't reuse every known pattern.
What are you doing with third-party stuff? How do you integrate them? I do not know any usable library without using an OOP schema...
There are many more problems which are surely possible to solve, but every time you lose the possibility for others to understand your code and to reuse it in other programs...
One word: cohesion.
When you start developing software using objects (especially when those objects use Dependency Injection), you find that common functionality starts to gravitate into their own specialised classes that are reused. This makes maintaining and enhancing the software MUCH easier, and results in higher quality software.
Example:
Many applications use sessions, for storing all sorts of stuff. When all session data is managed by a specialised session manager class, all the code that is responsible for dealing with the session is kept in one place. If you want to change the way you application uses session data (perhaps to make it more secure, or more efficient), you only need to change code in one place.
I made the jump to OOP PHP three months ago and it is one of the best things I have done.
I started off with PHP Object-Orientated Solutions and have just finished Real-world Solutions for Developing High-quality PHP Frameworks and Applications. Both of those books have helped me a lot, and I highly recommend them.
The learning curve is quite high. But I guarantee, you will be glad you've turned to OOP.
With OO you can develop applications a lot faster and in a cleaner way. You could easy to reuse your extisting classes with extending them (reducing your code base).
With OO design you only have to deal with small pieces of codes at any one time, not a bunch a functions in a file with 3000+ lines of code. You should also look after the
SOLID guidelines.
I know there are countless questions about the difference between OOP and procedural, when to use either and whether the benefits outweigh the extra overhead, learning the syntax, inheritance confusion, etc. Most of what I've found tends to just discuss differences and benefits and not whether its necessary.
I generally mix OOP and procedural within the same sites scripts depending on what I'm doing. I'm still fairly new to OOP and actually quite like the modular nature of OOP and the benefits it gives, even if there's a minor overhead. Inheritance can get a little confusing at times though!
To me the major benefits only seem to be in better organisation and protection of the code. Of which, the developer or team of developers are the only people to appreciate it. I guess there's a case for deployment speed but wouldn't say there's a lot in it for most sites unless you've inherited someone else's birdsnest :)
Is OOP necessary in most PHP apps though, especially when execution speed is the holy grail for most sites? ok, so the milliseconds overhead won't really notice unless a heavy use site but as a fan of electronic music speed is king!
I get using OOP in complex things like gaming and real-time cloud software, but static websites? even database heavy ones?
Does anyone have real world examples of typical sites that benefit from OOP and why?
Assuming both cases are well structured, would heavy use sites like ebay or monster.co.uk benefit more from OOP or the speed improvement of procedural ()? and why?
At least with procedural you can debug from the top down without having to bounce around the script to check classes and extensions and interfaces.
Can't I just apply OOP modular thinking with clear MVC and well commented code?
For example, I keep re-usable functions in include files and group related functions together. All I have to do is include the file like I would a class file and call up the functions. If the function needs to change, it gets changed in just one place, similar to a class.
And a kind of inheritance already exists in procedural without having to jump through hoops to declare it. You don't have the same level of control but it gets the job done nice and quick.
You could even simulate a class by grouping functions within a parent function and use a selector function to access them. That's taking it a bit far though!
Also, as far as I'm aware when a function is called it stays in memory making subsequent uses quicker. Whereas with OOP you would have to create two objects of the various methods to use the same function for two different variables. Correct me if I'm wrong.
Why create an object and use a method to 'get' a value when I could just reference the value directly with procedural?
well done for getting this far, hadn't realised I'd typed so much. Anyway, before I digress any further I'm going to end it here.
So if you've got any good examples of actual sites or parts of sites that benefit from either OOP or procedural I would really appreciate the clarity.
People managed to write good, clear, well organized code long before OO languages became popular. I see no reason why it can't still be done now.
Generally OO principles make it easier (which is one reason why OO is so popular) but they are by no means a necessity.
There are lots of questions here. I recall writing a long essay addressing some of these points while at university, but I don't want to reproduce something similar here, so instead, let me share a few thoughts:
Is OOP necessary in most PHP apps though, especially when execution speed is the holy grail for most sites? ok, so the miliseconds overhead won't really notice unless a heavy use site but as a fan of electronic music speed is king!
I think that if execution speed is a really big deal for you, php is not the right language for your website. Compared to the large performance cost of using an interpreted language, a little overhead is negligiable compared to the advantages of the OOP programming style for creating large systems. Do not discount the importance of making something easy for programmers to do, as this means faster releases, less bugs, and more maintainable code.
I get using OOP in complex things like gaming and real-time cloud software, but static websites? even database heavy ones?
I agree with you here. A nice thing about websites is that they are naturally modular because they are separated into pages. It hard to write code so bad that future programmers can't maintain it (for a fairly simple, static website).
For example, I keep re-usable functions in include files and group related functions together. All I have to do is include the file like I would a class file and call up the functions. If the function needs to change, it gets changed in just one place, similar to a class.
You can write good procedural code, but its harder than writing good OOP code. Weaker programmers are less likely to write insane spagetti code when given an OOP system to work with.
Why create an object and use a method to 'get' a value when I could just reference the value directly with procedural?
This is your only real implemenation question. The idea with Getters/Setters is so that you can change the internal workings of the class without breaking other code that depends on it.
I get using OOP in complex things like gaming and real-time cloud software, but static websites? even database heavy ones?
Implying that you don't want speed in games but want speed in websites.
PHP is never the bottleneck, if it is, write it in C.
Don't write procedural code because it is "faster". That's silly.
Does anyone have real world examples of typical sites that benefit from OOP and why?
Websites benefit from modular code that is maintainable and well organized.
You don't need OO for this, you can do it with functional or imperative styles. However PHP is known for it's ease to write bad code in a procedural style.
I would personally say that it's more likely your code is modular and maintainable if it was OO.
It's not necessary though.
And a kind of inheritance already exists in procedural without having to jump through hoops to declare it. You don't have the same level of control but it gets the job done nice and quick.
In OO programming it's all about encapsulation which means binding a lump of data to some functions that manipulate it.
You can do this just as well with a set of functions which take a data object as the first argument or classes.
Classes and OO just gives you sugar and utility.
It's a tool to write modular code, if it's helps you use it.
Don't pre maturely optimize OO away because it's "slow". If you care about that kind of micro optimization then start writing C or ASM.
I think a lot of people who promote OO are younger and have only ever written/been taught OO and so have a very negative view of procedural as old fashioned and 'legacy'.
IMO it is easy to write modular procedural PHP that is DRY and can be easily maintained. The trick is to use functions and 'include' to reuse standard php and html respectively. At the end of the day PHP is just reading DBs and generating html - there is no specific need to add the extra complexity of OO if you don't want to.
There are many debates on whether Object Oriented Programming is good or not. But, using OOP in Php is slower. Would it be a good trade to use procedural programming and faster speed and OOP with slower speed (since classes have to be initiated every time a page loads and big websites will start to become slow).
More importantly, would it be good to wrap stuff inside a class and use static functions or would it be better to just have many lying functions with a prefix ex: wp_function().
If the reason you're worried about using OO with PHP is speed, fear not: PHP is a slow language all around. If you're doing something that's processor-intensive enough for the speed loss from using objects to matter, you shouldn't be using PHP at all.
With regards to static functions, this is a design choice, but I'd err on the side of avoiding classes made up entirely of static functions. There's really no advantage to it over prefixes, and using a construct just because it's there isn't a good idea.
Yes, it is almost always a good idea to use OOP. This is because OOP is a style of coding, and coding styles for the most part are easily able to be transferred accross languages.
People don't use coding-styles because they use a certain language. People use coding styles because the style of coding offers good methods to do things they feel are desirable. Therefore, as long as the basic elements are there (inheritance, class properties, etc), it will always be viable to write in that coding style.
No, using procedural functions to access them probably isn't a good idea. This is because, you probably will have to do something like this to maintain the state.
function myFunc()
{
global $class;
$class->doMethod();
}
function myFunc2()
{
global $class;
$class->doMethod2();
}
This is a bad idea as it creates a ton of global state.
I strongly disagree with Chacha102's answer.
A proper answer to this question would fill several books - never mind a 20 line post here.
Both approaches have their benefits and drawbacks. I would recommend anyone who wants to consider themselves a good programmer to have significant experience in procedural, non-procedural and object-oriented programming. As well as experience with different methodologies such as SCRUM, cascade and RAD.
Regarding PHPs suitability for OO vs procedural coding, certainly the roots of the language are in the latter (but note that both Java and ASP are hybrid rather than true OO languages).
Peronally, I tend to write procedural code when I need to produce something which is either very simple or must have its behaviour to be thouroughly defined and predictable. However when writing complex code where the behaviour will vary greatly at run-time, I find OO to be vastly more efficient in terms of developer time - despite the design being based around a finite set of use-cases.
To argue that you should always write procedural code because it will run faster than OO code:
1) is not necessarily true
2) totally ignores the relative cost of developer time vs hardware costs
would it be good to wrap stuff inside a class and use static functions
Given that namespaces are now available in PHP, this is a really messy way to avoid namespace collisions and not something I would recommend.
C.
The same arguments about performance were made about Objective C and C++ back in the day. And the answer to that problem was to take advantage of available memory and processing power that is continuously getting bigger, better and faster.
Yes, OO requires more resources to run. But the benefits of using OO outweigh the hardware cost $$ (which is likely to be insignificant) of supporting OO applications.
It is, however, a good thing to be concerned about software performance. However looking under the hood of procedural vs. oo as a place to start is a bit misguided. You need to be focused on writing efficient code to begin with, whether procedural or OO (and both are relevant).
Keep in mind that even though PHP may not be the fastest platform out there (Java, for instance, kicks its butt) PHP is used to power some of the most traffic heavy websites on the Internet: namely Facebook.
If you have any other doubts about PHP and OO, just look at Zend and Magento (based on Zend). Magento is a VERY resource-intensive platform, memory usage can be upwards of 36MB per instance. However the platform itself is capable of handling millions of hits. This is because a properly configured server environment with a healthy serving of hardware resources make all the benefits of using OO far outshine the cost of the server itself. But in a world of clustered computers, NOT using the processing power and memory (responsibly) available to you is--IMHO--clinical insanity.
In my humble opinion, PHP developers should not try to go solely one direction. (procedural vs object-oriented) In some cases, all you need is a few global functions, other times it is more beneficial to use objects. Don't try to force everything one way or the other, be flexible and use what works best for each situation.
I was curious of this myself. Unfortunately after I changed my code from procedural to oop I ran some benchmarks and not beforehand.
Here's the benchmark code.
class game{
function maxp($val){
return max(0,pow($val,0.5));
}
}
$game = new game;
for($i=0;$i<100000;$i++){
$game->maxp(100);
//game::maxp(100);
}
OOP results ranged between 0.13 and 0.2 seconds;
Procedural results ranged between 0.08 and 0.1 seconds.
The results remained consistent over a good length of time.
I encourage you to run your own tests.
php 5.4.3
There's really no perfect answer since it depends on so many unknown variables, and then it doesn't have to be all-or-nothing.
For example, if you split your application into the MVC model, you might have your Model be OO but keep the Controller more simplistically procedural.
You could use classes as a means to simply group common static functions, or you could take it a lot farther into the active record pattern.
If you're building a small single-page webform that shoots a POST off in an email, you really don't need OO--lest you perhaps include an existing mail class to leverage.
Nobody can give you proper advice without understanding the project you're taking on.
That said, if your only concern is speed, then OO will be slightly slower. And there's a lot of sneaky things you can do in even procedural PHP to mimic some of the OO gains. But unless you're taking on a huge project, the added overhead will never amount to much. And by the time you have a huge project, the pros of OO might outweigh the cons of its overhead.
OOP has more merits than its de-merits. See PHP OOP, What Are The Benefits?. Also see for OOP vs PP in PHP.
Yes as your application grows.. (and it will) it will save you many hours of frustration. And repeating yourself (copying pasting code all over the place).. :)
I'm hoping to get some tips to kinda help me break out of what i consider after all these years a bad habit of procedural programming. Every time i attempt to do a project in OOP i end up eventually reverting to procedural. I guess i'm not completely convinced with OOP (even though i think i've heard everything good about it!).
So i guess any good practical examples of common programming tasks that i often carry out such as user authentication/management, data parsing, CMS/Blogging/eComs are the kinda of things i do often, yet i haven't been able to get my head around how to do them in OOP and away from procedural, especially as the systems i build tend to work and work well.
One thing i can see as a downfall to my development, is that i do reuse my code often, and it often needs more rewrites and improvement, but i sometimes consider this as a natural evolution of my software development.
Yet i want to change! to my fellow programmers, help :) any tips on how i can break out of this nasty habbit?
What is the point in using object-oriented programming when you cannot find good reasons or motivation to do so?
You must be motivated by the need to conceive and manipulate ideas as objects. There are people who feel the need to be perceptive of concepts, flow or functions rather than objects and they are then motivated towards programming oriented towards concepts, ideas, or functional flow.
Some 13 years ago, I switched to c++ from c simply because there were ideas I needed but c would not easily perform. In short, my need motivated my programming oriented towards objects.
The object-oriented mind-set
First, you have bytes, chars, integers and floats.
Then your programme starts being cluttered with all kinds of variables, local and static.
Then you decide to group them into structs because you figured that all the variables which are commonly passed around.
Conglomeration of data
So like printer's info should have all its variables enclosed into the Printer struct:
{id, name, location,
impactType(laser|inkjet|ribbon),
manufacturer, networkAddr},
etc.
So that now, when you call function after function over printer info, you don't have functions with a long list of arguments or a large collection of static variables with huge possibilities of cross-talk.
Incorporation of information
But data conglomeration is not good enough. I still have to depend on a bunch of functions to process the data. Therefore, I had a smart idea or incorporating function pointers into the Printer struct.
{id, name, location,
impactType(laser|inkjet|ribbon),
manufacturer, networkAddr,
*print(struct printer),
*clean(struct printer)
}
Data graduates into information when data contains the processes on how to treat/perceive the data.
Quantization of information
Now laser, ribbon and inkjet printers do not all have the same set of information but they all have a most common set of denominators (LCD) in information:
Info common to any printer: id, name, location, etc
Info found only in ribbon printers: usedCycles, ribbon(fabric|cellophane), colourBands, etc
Info found only in inkjet: ink cartridges, etc
Info found only in lasers: ...
For me and many object-oriented cohorts, we prefer to quantize all the common info into one common information encapsulation, rather than define a separate struct/encapsulation for each printer type.
Then, we prefer to use a framework which would manage all the function referencing for each type of printer because not all printers print or are cleaned the same way.
So your preference/motivation oriented away from objects is telling you that your programming life is easier if you do not use objects? That you prefer to manage all those structural complexities yourself. You must not have written enough software to feel that way.
The necessity of laziness
Some people say - necessity is the mother of creativity. (as well as, Love of money is the root of evil).
But to me and my cohorts - laziness in the face of necessity are the parents of creativity. (as well as the lack of money is the other parent of evil).
Therefore, I urge you to adopt a lazy attitude towards programming so that the principle of the shortest path would kick into your life and you'll find but have no other choice than to graduate towards orienting yourself towards programming with objects.
Step 1. Read a good Design Patterns book. http://www.oodesign.com/
Step 2. Pick something you already know and rework it from an OO perspective. This is the Code Dojo approach. Take a problem that you already understand, and define the object classes.
I did this -- and wrote down what I did.
See http://homepage.mac.com/s_lott/books/oodesign.html#book-oodesign
You can do the same series of exercises to get the hang of OO design and code.
The OO mindset is based on principles that lie at a much more basic level than design patterns. Design patterns are somehow fashionable these days (and have been for a while), and they are useful, but they are just one more layer that you can put upon more basic stuff that you absolutely must learn and master if you want to do OO properly. In other words: you can do OO perfectly without design patterns. In fact, many of us did OO well before the phrase "design patterns" was even coined.
Now, there is stuff you can't do without. I suggest you start at the basics. Read and understand "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer. It's probably the best book on OO programming around, both in width and depth. That is if you're interested in programming.
First, congrats on taking steps to learn something new! I hate it when developers decide to NOT evolve with technology.
As far as moving from procedural programming to OOP, I would say that one thing that you can do is take an existing app (as others have mentioned) and, before you even open a text editor, sit down and think about how each aspect of the application would be converted. I have found that more than half of OO programming is defining the conceptual objects in your mind first.
Again, I will agree with everyone's recommendations on design patterns. Specifically, I would look into the MVC (Model-View-Controller) pattern as this one might be the easiest one to grasp. You have already written code, so you should be able to look at your existing applications and begin putting each part into the M,V or C categories.
Best of luck and have fun!
There are already quite a few answers about where to find information on programming in an object-oriented fashion. Indeed, there are many great books out there that will define the basic concepts however I think the question was more on how to "stick with it" through development for someone new to the method.
Of the many concepts in object-oriented programming, the main one that will keep you on track as a newcomer is encapsulation. Does my class know how to take care of itself? Does my class have behaviour? If it doesn't, then you don't have a class, you have a structure and you'll likely be writing a lot of procedures to change its state (as it's said, "you are back to writing C in Java"). Does my class only expose methods publicly that are required for its use? Those questions may not be terribly elaborated upon but perhaps consider this thought experiment when designing your classes: What if each one of your application's classes were to be developed and maintained by a different developer on the internet and the classes also had to interact with eachother over the internet. Would each developer agree that the class they are writing and maintaining adheres to the single responsibility principle and therefore be happy that they aren't maintaining what should be someone elses code?
Regarding the design of class interfaces, consider writing all of the code that uses your classes first. Don't worry about what has to happen at the metal yet. You should be able to stub out the entire program in terms of the class relationships before you write your first bit-twiddling implementation detail. If you can't do this without twiddling bits or making a variable public, then it is time to go back to your class relationship diagram and see if you are missing an abstraction. Phrased another way, use your code before you write your code. Do this first, and you might be suprised how clean your code and interfaces turn out if you've never done it before.
While design patterns are certainly good to learn, and some are extremely powerful, they aren't generally intrinsically object-oriented and as some argue (and I tend to agree) design patterns are often just exposed weaknesses in the language. One language's design patterns is another's basic founding principles. So when starting, don't get hung up on whether or not some relationship is a good candidate for a bridge or a facade; this is not specific to object-oriented thought, this is related to what a specific language's constructs afford.
Don't.
First, learn writing. Second, learn user experience and interaction design. Third, learn business analysis. Fourth, learn role modeling.
Now that you know what objects are, you will come to see that objects are not found in code. They are found at runtime; in the space between the machine and the user's mind. This is what object orientation really means. Unfortunately recent academia has twisted it into an engineering concept. Nothing could be further off the mark. And try as they might to emulate, the end result is crap. Why? Because the "OOP" paradigm as the industry knows it today is built on a fundamentally flawed idea: decompositional analysis of identity. How is this flawed? Because identity in and of itself is meaningless. It is void. In a mathematical sense, in a philosophical sense. This is not how a human being perceives and interacts with the world.
Canon: Alan Kay, Trygve Reenskaug, James (Jim) Coplien
How I wish I was in your position. :)
I think it helps to first skim over some existing, decent, proven object-oriented code (e.g. Qt source code) so you can get a feel for "how it's done". After that, learning from a book or creating your own framework will be much more effective.
In general, it really helps to see things in context before reading about and practicing them, as it gives you moments to say to yourself, "Oh, that's why they did that!" At least that's how it works for me.
The hard part of OO is which stuff should be put together into one object. As you already mentioned the evolution of your source code, here you have a simple guideline on how to evolve your source code towards an OO design:
"Put stuff together that changes together."
When two pieces of code have similar change velocities, that's a hint that they should be placed in the same object. When the change velocities are different, consider placing them in different objects.
This is also known as "Change Velocity".
If you follow that guideline your code will naturally evolve towards a good OO design. Why?
Fragments of code often have similar
change velocities if they access a
common representation. Every time the
representation changes, all the pieces
of code that use it must change at
once. This is part of the reason we
use objects as modules to encapsulate
representation. Separating interface
from implementation makes sense under
this guideline too - the
implementation changing more often and
thus having a higher change velocity.
If a class has a stable part and an
unstable part, that's a difference in
change velocity that suggests moving
the stable part to a (possibly
abstract) base class.
Similarly, if a class has two parts
which change equally often but at
different times or in different
directions (that is to say, for
different reasons), then that again
suggests refactoring the class.
Sometimes replace "class" with
"method". For example, if one line of
a method is likely to change more
often than the rest - perhaps it is
the line which creates a new object
instance and contains the name of its
class - consider moving it to its own
routine. Then subclasses can easily
effect their change by overriding it.
I came across this concept on C2 wiki many years ago, but I've rarely seen it used since. I find it very useful. It expresses some crucial underlying motivation of object oriented design. Of course, it's therefore blindingly obvious.
These are changes of the program.
There is another sense of change
velocity - you don't want instance
variables changing at different rate,
or rather that is a sign of potential
problems. For example, in a graphics
editor you shouldn't keep the figures
and the handles in the same
collection, because the figures change
once a minute or once an hour and the
handles change once a second or once a
minute.
In a somewhat larger view, you want a
system to be able to change fast
enough to keep up with the changes in
the business.
PS: the other principle that you should follow is "Law of Demeter", that is, an object should only talk to its friends. Friends are: yourself, instance variables, parameters, locals, and members of friendly collections - but not globals and static variables.
You might consider using the CRC (Class/Responsibility/Collaboration) card approach to OO design. This is nothing too scary - just a way to sort out what your objects should be, and which object should be responsible for which tasks by writing stuff down on a bunch of file cards to help clarify your thoughts.
It was originally designed as a teaching tool for OO thought, and might work for you. The original paper is at: http://c2.com/doc/oopsla89/paper.html
A poster above suggested programming in Smalltalk to force you into OO habits, and to an extent that's a good suggestion - Smalltalk certainly did me a lot of good, but
a) you may not have the spare time to learn a new language. If you do, great.
b) I used to tutor a university course in OO programming, using Smalltalk, and the students did an excellent job of proving that old joke about how "You can write FORTRAN in any language".
Finally: when I was learning about OO (from books) I got the impression that you subclassed a lot, creating complicated class hierarchies. When I started working with OO programmers I realised it didn't happen as often as I thought. I think everyone makes this mistake when they're learning.
The only way to write better code is to write more code. Take a project you've implemented procedurally and convert it to OOP (assuming you're working in a language that supports both). You'll probably end up with a fragile, tightly coupled solution the first time around, but that's ok. Take the bad OOP implementation and start refactoring it into something better. Eventually, you'll figure out what works, and what doesn't.
When you're ready to take the next step, pick up a Design Patterns book and learn some of the OOP design terminology. This isn't strictly necessary, but it will give you a better grasp of some of the common problems and solutions.
I think you should convince yourself by researching all of the downsides with procedural programming, for example (some buzzwords following, watch out): scope, state ... practically you'd be able to extract many terms just by reading examples of design patterns (read: common examples of using objects together.)
Stressing yourself into learning something you don't believe in won't get you anywhere. Start being really critical on your earlier work and refactor it to avoid copied code and using the global scope, and you'll find yourself wanting more.
For me the ah-ha moment of OOP was the first time I looked at code and realised I could refactor common stuff into a base class. You clearly know your way around code and re-use, but you need to think around classes not procedures. With user authentication it's clear you're going to have a username and password, now they go into the base class, but what if you need a tokenId as well, re-use your existing login base class, and create a new subclass from that with the new behaviour, all your existing code works without change.
See how that works for you.
Well, first off design patterns are about the worst thing to pattern your programming to.
It's just a big set of things. It's nothing to do with OOP, and most of them such as singleton are constantly used for all the wrong reasons (ie initialization). Some of these things you have to use so telling you about them is pointless, others are counterproductive, and the rest are just special case things. If you try to learn anything this way everything will start to look like some bizarre doodad someone came up with for a very special problem or because they needed infinite genericity (which is seldom true). Don't let people con you into using a million iterators and templates for no reason and make things ten times more complicated.
Really OOP is a simple subject that gets massively overcomplicated. Unfortunately in C++ it has a lot of issues but really simple virtual methods are what matters. Pure virtual base classes used much like a java interface object are the most useful but also just plain virtual methods here and there will come in handy.
It's mostly been overblown. It also doesn't lend itself well to every problem. If you make database and gui stuff it lends itself well to that. If you make system tools it is usually not as helpful.
I found that one of the things which has really helped solidify the benefits of OOP for me has been writing unit tests with a mock object framework (such as EasyMock). Once you start to develop that way, you can see how classes help you isolate modules behind interfaces and also allow for easier testing.
One thing to keep in mind is that when people are first learning OOP, often there is an overemphasis on inheritance. Inheritance has its place, but it's a tool that can easily be overused. Composition or simple interface implementation are often better ways of doing things. Don't go so far in attempting to reuse code via inheritance that you make inheritance trees which make little sense from a polymorphism standpoint. The substitution principle is what makes inheritance/interface implementation powerful, not the fact that you can reuse code by subclassing.
A great step would be to start of with a OOP framework, you can still write procedural code in the framework but over time you can refine your coding habits & start converting functionality into objects.
Also reading about patterns & data modeling will give you more ideas about to code your logic in a OOP style.
I have found that a very intense way learning to train abstraction in programming is to build a OOP library with a defined functionality, and then to implement two projects with similar but still different requirements that are building on that library, at the same time.
This is very time-consuming and you need to have learned the basics of OOP first (S.Lott has some great links in the other answer). Constant refactoring and lots of "Doh!" moments are the rule; but I found this a great way to learn modular programming because everything I did was immediately noticeable in the implementation of one of the projects.
Simply practice. If you've read everything about OOP and you know something about OOP and you know the OOP principals implemented in your language PHP... then just practice, practice and practice some more.
Now, don't go viewing OOP as the hammer and everything else as the nail, but do try to incorporate at least one class in a project. Then see if you can reuse it in another project etc..
Learn a new language, one that helps to move you gently to OOP. Java is nice, but a bit bloated, though. But its system library is mainly OO, so you are force to use objects.
Moving to another language also helps you not to reuse your old code :-)
I think it´s important to learn the theory first. So reading a book would be a good start.
I believe that the mechanics of OOP seem completely arbitrary and make no sense until you read a book on design patterns and understand the "why" of it. I recommend Head First Design Patterns. I thought OOP was ridiculous and completely useless until I picked up this book and saw what it was actually good for.
OO makes a lot more sense when you understand function pointers and how it relates to indirect function calls and late binding. Play around with function pointers in C, C++, or D for a little while and get a feel for what they're for and how they work. The polymorphism/virtual function part of OO is just another layer of abstraction on top of this.
Procedural is the right tool for some jobs. Don't act like it's wrong. IMHO all three major paradigms (procedural, OO, functional) are valuable even at a fine-grained level, within a single module. I tend to prefer:
Procedural is good when my problem is simple (or I've already factored it enough with functional and OO that I now have a subproblem that I consider simple) and I want the most straightforward solution without a lot of abstraction getting in the way.
Object-oriented is good when my problem is more complex and has lots of state that makes sense in the context of the problem domain. In these cases the existence of state is not an implementation detail, but the exact representation is one that I prefer to abstract away.
Functional is good when my problem is complex but has no state that makes sense at the level of the problem domain. From the perspective of the problem domain, the existence of state is an implementation detail.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a start of a webapp that I wrote without using the Object Oriented features of PHP.
I don't really know if it is worth it to go back and rewrite the parts I have finished. Is object oriented PHP worth rewriting all or part of a decent working app?
Given that you have an incomplete app I would say that reworking it into an Object based app will probably be helpful.
One thing to consider is the expected size of the end application. Below a certain complexity Object based may be overkill except for the learning experience.
I started out avoiding Objects like the plague because my initial introduction to them in university classes was terrible. I somewhat recently had to work on a project which was implemented in php objects. making the required changes was much easier than other projects. I have since then worked in the object model frequently and find it very handy for quick creation and easier upkeep.
Just to disagree with the consensus... I would say no in most cases. Not as an academic exercise on commercial code anyway. If it's working don't re-write it. If you have to go in to change / add bits, then refactor towards OO practices (there are lots of posts on SO about refactoring when you are changing code anyway, and not just for the sake of it).
In practise if you haven't done a lot of OOP, then you'll want to start small and get a feel for it.
Once you get a handle on the basics, a good beginners guide to Design Patterns (I like the Head First book) is very useful. Most PHP books would teach you OOP fairly poorly. They teach you about inheritance, but usually don't teach you about loose coupling and favouring composition over inheritance. A design patterns book will give you a better insight into this.
PHP still has a reputation for not "doing" OO right. I don't think this is fair, but is a reflection of the fact that it's so easy for people to get started without really grokking OOP. I would go out on a limb and say the majority (ever so slightly - call it 51%) of PHP programmers aren't comfortable with OOP. I think it's possible to do good OO in PHP, and if you're already comfortable with the language it's a great way to grow your skills.
EDIT:
Just to add a couple of disclaimers...
My comment about most PHP programmers not being comfortable with OOP wouldn't apply to the current SO audience!
Not suggesting you aren't comfortable with OOP, this applies if you're not
Typical answer: "It depends."
I tend to write the display page as a start-to-finish, < html > to < /html > scripted page. But the things that happen on that page were objects. Kinda like a poor man's ASP. While you can have OOP-base output, I alwasy thought it too cumbersome for a task as tedious as dumping data to a browser.
So, business rules and data access were OOP. Presentation was script.
If you have business rules that are not OOP, I would seriously consider writing those as objects on two conditions: (1) is "Do you have time/effort/money to do so?" and (2) is "Do you have a good PHP IDE that will make your life easier?" If it works, and changing it means writing in Notepad++, then I would call it done. :-)
I wouldn't say it is critical, but if you are going to go much further with the app, I would recommend doing it now while it is not as much of a monumental task. I would say the maintainability of a well written OOP program could far outweigh the up front costs. Especially when you consider that you will be able to refactor much of the code as you go along.
Learning object oriented techinques will be really useful, especially for programming in other languages in the future.
Since you have only just started the application, you could rewrite and improve the parts you have written. It depends on your deadline.
There are two possibilities: either your app is a one-off that just has to work right now and will never be touched, adapted, expanded or modified, or else your app is the beginning of something that you will keep working with and using over a long time.
If the former, don't break perfectly usable code. You have better things to do with your time.
If the latter, you have to bear in mind an important fact about PHP, which is this: poorly written PHP is a nightmare to maintain. Not as bad as poorly written Perl -- because what is? -- but bad enough that sooner or later you will feel a strong urge to steal a time machine, travel back to the moment you wrote the code you now find yourself maintaining, and stab yourself in the eye socket with an icepick.
So if you're going to be maintaining this code over time, take the time to do it right. That means: some kind of templating system, no PHP tags embedded inside HTML, separate files for separate functionality, and classes classes classes!
Your eye sockets will thank you.
I would say try and go OO just because what you have can be reused much easier than procedural if done right
I will also say that OO is much more organized then procedural. When your at a small scale it's easy to get away with sloppy code OO or not. But when you get to larger projects your procedural must be much more organized and thought out. Where as on some larger projects OO tends to force you to be more organized making things a little easier.
No, i think if the app is working like it should there's no need to rewrite it.
PHP isn't really OOP at all. They try hard but sometimes i think even the PHP-Developers dont really understand the sense of OOP.
If you wish to learn OOP (which is surely a good idea) try a real OOP-language like Smalltalk to learn the basic concepts. Java is also nice 2 learn the basic, although it isnt fully OOP as well
I'd like to reiterate the other answers here. It depends upon size of application and how much you'd like to learn about OOP. I'd be careful of learning OOP by using PHP though.
As for how much PHP is object oriented... PHP4 had some OOP elements slapped onto it, PHP5 is better but it's not baked into the language. PHP works both ways, and personally I like that you can choose.
In my mind, we phper can thorouly throw away the concept of Object(class instance), we only need Array and Mode Class:
All arrays in initial mode support any array function as it's method:
<?php
$array1->array_flip(this);
?>
Use ->mode() to validate the minimal data set, and then switch mode class:
<?php
$array1->mode('class1', $success);
?>
Any mode class has no ->construct() in it, but has ->validate() to validate the minimal data set.
The array in a mode still could use array function as its method, but after using any of them the array will be switched back into basic array mode,
and we need to use ->mode('class1', $success); to switch mode back.
The radical thought is data-centric programming, we need separate the data(array) and the activity(class method).
We could modify PHP engine, to get rid of parts of OO(object oriented), and support Mode Class, we could call it MyPHP.
For example:
$array_man1 could be set into two modes:cls_normal_man and cls_crazy_man:
<?php
$array_man1->mode('cls_normal_man')->normal_method1()->mode('cls_crazy_man')->crazy_method1();
?>