Page 1 of 1

OOP... switching to php5

Posted: Fri Jul 20, 2007 3:09 pm
by Chalks
Ok, I know I only started with php a couple days ago but, I'm already convinced that I ought to switch from my php4 coding practices to php5. As a part of that, I'm going to redesign all of my existing code (man it's nice to be new*) in an object oriented manner.

When I learned java, I had drilled into my head to _always_ create accessor and mutator classes for my variables within classes (ie setUser(), getUser(), etc) and keep all variables and functions private not static. Also, I was told to create a compareTo() function so that I could check if objects were equal (and other reasons not applicable to php). Should I continue doing these things with php, or were the reasons for doing that specific to java? I don't really know if they were or not.








*Because I only have a couple hundred lines of code to change. Edit: :D

Posted: Fri Jul 20, 2007 4:56 pm
by califdon
I'm not qualified to give you a definitive answer, but those issues are pretty generic and I'd say you should apply them to OOP PHP for the same reasons that you were taught to apply them in Java. I'd guess the reason that there's perhaps less emphasis on those principles in PHP is that PHP is traditionally a procedural language and OOP has been added relatively recently. Also, I think the most general use of OOP by PHP writers is to sprinkle some OOP throughout a script, rather than truly build a whole application in strictly OOP fashion. After all, PHP is mostly mixed in with HTML and is not compiled, so there's less emphasis on formal structural rules than there is in typical Java programming. At least, that's the best answer I can come up with.

Posted: Sat Jul 21, 2007 2:57 am
by Chris Corbyn
Acessors/mutators - yes.
Comparison methods - no, only in specific cases
Private properties - yes, though "protected" is often a better choice.
I'm confused why you'd used "static" vs private, unless you meant "final static" which is "const" in PHP 5 ;)

Posted: Sat Jul 21, 2007 5:03 am
by Ollie Saunders
califdon wrote:Also, I think the most general use of OOP by PHP writers is to sprinkle some OOP throughout a script, rather than truly build a whole application in strictly OOP fashion. After all, PHP is mostly mixed in with HTML and is not compiled, so there's less emphasis on formal structural rules than there is in typical Java programming.
Not how I do it. I objectify everything I can so as to make it unit testable.

One of the core differences with PHP and Java is probably PHP's arrays, which are both highly flexible and not objects. People have written Vector and LinkedList classes for PHP but generally they are just overhead. Also because the standard library is pretty much all functions you'll find yourself using fewer objects to get things done. Other differences:
  • PHP has no namespaces yet. Many use faux namespaces and some go a step further with PEAR style class naming. It's worth learning what both of these are. One is more extreme than the other. When you use PEAR style naming you can use __autoload() to load all classes saving on a load of require_once statements. Although I don't recommend on relying on __autoload() being defined when writing libraries.
  • Use the PEAR or Zend coding standard
  • Only type hint for interfaces.
  • Not having static typing is not an issue having loose typing can be. Think whether you want === or ==, don't use == all the time just because it's one character shorter. is_scalar() is an under-rated function.
  • You can instantiate classes from a string assigned to it's name, use variable variables and access constants dynamically. I recommend none of these. As far as dynamic instantiation goes the Reflection API is usually much better.
  • Do study what reflection is, there are many functions separate from the reflection API that are do reflective jobs such as get_defined_functions(), class_exists(), extention_loaded(), __FUNCTION__ etc. As you can see from those links, there's reflection for functions, classes as well as the environment. Using these will make your code more flexible and portable. Don't go mad though they are generally only occasionally useful.
  • Object overloading is great but don't make your code obscure with it. __call() is often useful for simplifying and interface to entire set of classes to single method calls.