Quote:
Originally Posted by edgeprod
(Post 15715418)
Thanks very much. For error handling in the Hello class, I used the default handler in switch(), rather than throwing an actual exception. I wanted the code to be backward-compatible with PHP4. :)
|
Well, considering PHP4 is well and truly gone now...(but I do understand your frustration)
Coders discussing style always turns into a pissing contest, but here we go.
There are a few things that could be built on / improved. Not sure if you left them out because it was a simplistic example, or because you don't use them.
I spent pretty much every moment of the day coding, and could have done w/ some sage tips, especially w/ OOP in PHP when I was learning, so take this for what it is.
- Making the $returnText shouldn't be public. It should be private, with an accessor function.
- You shouldn't refer to it as $returnText .= " " - it should be $this->returnText This will save you a hell of a lot of frustration with scope, and missing and overwritten variables down the line
- Returning a string for error checking isn't really that strong, because you then have to further check that string for errors.
You can do this two ways, easily
#1 - Via exceptions - simply throw an exception when you receive bad data, and catch it on the other side, or in the parent class, depending on your heirachy.
#2 - PHP4 Compatible: Have it return a boolean for the results, and let the user fetch them (ie, if (!$helloWorld->GetHelloText('1')) { // error code } else { $helloWorld->GetResult(); }
and so on.
These things become increasingly important as your classes get more complicated - it's important to do it from the ground up.
Using __construct() is very important, too.
The problem, at least in my interpretation, w/ OOP in PHP is that it's not as strict as say Java or c++, meaning that it can be done poorly, which leads to headaches later on.
In any case though, kudos for posting this - there aren't many coders (esp on this board) that are much more than scripters, even less than those that understand design pricinciples and flow (specification, implementation, verification, documentation, etc), normalised db designs, and the big one: security. The number of scripts that I see getting passed around on here that are insecure is scary.
Anyhow.. didn't mean to sound like a grumpy old bastard, the merit of your post inspired me to reply.
