Page 4 of 6

Posted: Wed Sep 14, 2005 2:24 pm
by Ree
In my opinion, one should start OOP as soon as possible. The fact is, that most sophisticated projects are always coded using OOP paradigm. So, if you think you will ever want to participate in development of one of those, why waste your time coding procedurally only? Use OOP from the start, it works in all kinds of projects while strict prcedural does not. And I've noticed that very often in more serious job offers they include OOP knowledge as a must.

Sorry to go offtopic, but I've just noticed a quote in McGruff's post I'd like to ask him about. I hope you don't mind.
Email validation for example would certainly be carried out by an object - or rather a whole group of objects designed to carry out input validation.
Now, why would you want to validate email by using a separate object just for that? What methods/properties would you code in the class? I'm really not sure, because with email validation (or any other field) it's a pretty simple process: is the field empty - for that you have PHP's native function, no need to use your own, is the value an email - for that you would probably use a simple regex method. I can see only one method here (validation). Is it worth to create a new class just to contain one method and probably only one property (the value to validate)?

Posted: Wed Sep 14, 2005 2:36 pm
by josh
He probably meant with different checks, like the class would give a detailed report, like it had an @ sign and a domain but wasn't compliant with the RFCs, he probably had a method for each check and a method to get back an array of booleans on which tests it passed, at least that's what I would do for a validation class, i just usually do (!isempty() && preg_match('#(.+)@(.+)#i'))

I'm going to be validating the email by making them click a link in their email anyways, why even bother checking for every RFC standard, the email could be non-standards compliant but if your MTA is able to deliver the message it could still be "valid", that's why I always just check for the @, but i could think of a few other cases where validating emails would need a class.

Posted: Wed Sep 14, 2005 4:02 pm
by McGruff
Ree wrote:Now, why would you want to validate email by using a separate object just for that? What methods/properties would you code in the class?
A Rule interface might be:

Code: Select all

class Rule
{
    function validate()
    {
    }
    function getError() 
    {
    }
}
Perhaps one of the main advantages is testing. In a unit test, you'd test the email (or etc) validation code in isolation, throwing everything under the sun at it to make sure it works correctly. You really, really want to get these right.

Classes don't have to be big and complex - that could be a smell that you're trying to do too much with one object.

I use Rules mainly in the context of validating arrays such as GPC: a Validator class might have methods to set rules for various keys, and methods to access validated values or errors. The object would act like a filter only ever letting safe, validated values pass through. I would expect that some kind of formalised structure like this would eliminate a lot of copy-pasting of code which applies validation regex's etc.

I first came across Rule classes in WACT which might be worth a look.

Posted: Wed Sep 14, 2005 4:37 pm
by Roja
Ree wrote:The fact is, that most sophisticated projects are always coded using OOP paradigm.
Thats not really a fact. Of course, it all depends on your definition of sophisticated. I would however say that any project deployed on hundreds of sites, or in widespread use and development for years is fairly sophisticated.

In reality, the vast majority of sophisticated projects (by that definition) in php today arent purely OOP. On freshmeat, the top three most vital and most popular php projects (excluding PHP itself) are: PHPMyAdmin (procedural), PHPBugTracker (procedural), The Gallery (procedural), SquirrelMail (procedural), and EZPublish (Mixed). Lets not forget phpbb, powering this forum and dozens of others.

Its much the same in the corporate world, where you are generally tasked with migrating legacy apps that were written in procedural long ago.

So to answer your question about why you would spend time coding in procedural, its because its the most common coding style for the vast majority of projects out there. However, no one in this thread suggested coding in pure procedural - just the opposite. All of us encourage some level of OOP, just varying degrees.
Ree wrote:Use OOP from the start, it works in all kinds of projects while strict prcedural does not.
Please cite some examples where procedural can't work. Unless the definition of the project requirement is "OOP only", procedural can "work" in all kinds of projects too.
Ree wrote:And I've noticed that very often in more serious job offers they include OOP knowledge as a must.
Agreed. Again, everyone in the thread has been supportive of OOP.
Ree wrote:Now, why would you want to validate email by using a separate object just for that? What methods/properties would you code in the class? I'm really not sure, because with email validation (or any other field) it's a pretty simple process: is the field empty - for that you have PHP's native function, no need to use your own, is the value an email - for that you would probably use a simple regex method. I can see only one method here (validation). Is it worth to create a new class just to contain one method and probably only one property (the value to validate)?
Thats the example I used, and I think its telling. McGruff's answer is essentially, yes, you'd have two methods. Since a function can return either (yes its valid, no its not), it accomplishes the same goals. McGruff's argument that it bolsters testing (in this specific case) isn't quite valid either: By using the definitive regex, which has (itself) been tested in a huge variety of applications, we ensure quality.

I'd argue that the number of tests required to duplicate that level of certainty would easily turn a one-page function into a prime example of why OOP *can* yield bloated code to accomplish the same task.

I'll be very fair and say I chose email validation because it was a totally loaded question. There actually is a definitive best way to validate, and choosing to NOT copy that is the literal equivalent not of reinventing the wheel, but of recreating an entire car. Using sheet metal and a hammer.

OOP has strengths.. I can give a half-dozen examples where the opposite is true. Places where procedural would stumble, look extremely fragile, spaghetti-like, and possibly run slower.

Which of course brings me full circle to my point: Screws need screwdrivers and nails need hammers. OOP and procedural are both valuable. Ignore either, and you ignore a significant tool in your arsenal.

Posted: Wed Sep 14, 2005 4:44 pm
by Roja
jshpro2 wrote:I'm going to be validating the email by making them click a link in their email anyways, why even bother checking for every RFC standard, the email could be non-standards compliant but if your MTA is able to deliver the message it could still be "valid", that's why I always just check for the @, but i could think of a few other cases where validating emails would need a class.
Simply put, to reduce the number of undeliverable emails that your server will attempt to send. If you didn't validate it by having the click a link in the email, then you could be open to a massive denial of service attack. Someone could simply setup a script that would attempt millions of invalid addresses through your form, and poof, your mail server load skyrockets.

I only mention it because it was a very real issue in our game. We had an attacker take down a seriously large game by doing exactly that several years back. The admin for a variety of reasons (mostly due to hotmail email users not getting mails) had turned off validation. The attacker setup a script, and hammered away. We added validation shortly after, and each version I've looked for better and better validation methods, until I found the definitive RFC regex.

Now, even if you hooked up a script, it would simply spike the load of the webserver - something most hosts are more understanding about and usually, they are setup to handle it. (Of course in the game we have a protection against even that attack now as well).

So yes, there is a valuable use for validation. :)

Posted: Wed Sep 14, 2005 5:15 pm
by Buddha443556
Roja wrote:In reality, the vast majority of sophisticated projects (by that definition) in php today arent purely OOP. On freshmeat, the top three most vital and most popular php projects (excluding PHP itself) are: PHPMyAdmin (procedural), PHPBugTracker (procedural), The Gallery (procedural), SquirrelMail (procedural), and EZPublish (Mixed). Lets not forget phpbb, powering this forum and dozens of others.
Gallery has gone OO (PHP4), even boasting about unit testing, but it doesn't seem to have made the script anymore shared server friendly. JMHO.

Posted: Wed Sep 14, 2005 5:17 pm
by Roja
Buddha443556 wrote: Gallery has gone OO (PHP4), even boasting about unit testing, but it doesn't seem to have made the script anymore shared server friendly. JMHO.
The "Gallery" directory in their cvs is far from it. While the Gallery2 tree is definitely "more" OOP, its not a complete rewrite.. plenty of procedural left in there. :)

Posted: Wed Sep 14, 2005 5:21 pm
by Buddha443556
Roja wrote:
Buddha443556 wrote: Gallery has gone OO (PHP4), even boasting about unit testing, but it doesn't seem to have made the script anymore shared server friendly. JMHO.
The "Gallery" directory in their cvs is far from it. While the Gallery2 tree is definitely "more" OOP, its not a complete rewrite.. plenty of procedural left in there. :)
Your correct. I was referring to Gallery2.

Posted: Wed Sep 14, 2005 5:23 pm
by McGruff
Roja wrote:I'd argue that the number of tests required to duplicate that level of certainty would easily turn a one-page function into a prime example of why OOP *can* yield bloated code to accomplish the same task.
Tests don't actually add anything to the code - although they can shape code in a beneficial way. The test cases are completely separate classes which exercise the class under test by setting up fixtures and making assertions about behaviour in different conditions.

People often start testing by applying tests to existing code (which isn't the best way to do it) and they almost always find bugs they didn't know about. The discipline of testing leads you to think much more carefully about the behaviour of a class.

Posted: Wed Sep 14, 2005 6:03 pm
by McGruff
Roja wrote:In reality, the vast majority of sophisticated projects (by that definition) in php today arent purely OOP.
The only two of these I've dipped into are phpmyAdmin and phpBB. Sophisticated is not a word I often hear used to describe the code. They're both excellent examples of just how difficult maintenance can be with poor design.

Say I want to add a new bbcode tag in phpBB. It's a nightmare simply trying to identify the relevant chunk(s) of code. There are no tests to run after an edit so I don't know if the new feature works or if it broke something somewhere else - made all the more likely with global variables flying around. When I install it live, again there are no tests to run to check if everything's OK. It basically has to be tested by site visitors which isn't terribly professional.

Compare that to a fully tested OOP design. Encapsulation allows me to identify discrete units of functionality easily. After every little edit, I'll run the tests. I'll catch bugs early while they're easy to fix rather than later when they've disappeared over the horizon god knows where. Fine grained tests will instantly tell me what's going wrong. That's called regression testing: the application never regresses to an unworkable state.

Come install time, I'll once again run all the tests. I might make a test install in a sandboxed area of the live server, test, install for real, and test again. The really neat thing is that can all be scripted. I can click a button, go off and read a couple of emails, and it's done.

There could be thousands - tens of thousands - of individual tests accompanying one app. As you can see I've been running them constantly throughout the whole process. It's simply impossible to do anything remotely comparable with ad hoc, manual checks clicking around in a browser or using print_r's.

Testing is a big deal (and there's much more to it than I've touched on here). I'd go as far as to say it's unprofessional not to test.

In procedural apps like phpBB, I'm not sure how you would identify discrete units to test in the first place and I've never heard of a procedural analogue for test driven design. If you're looking for sophisticated programming the modern agile movement is where to look - and it's all about OOP.

Posted: Wed Sep 14, 2005 6:20 pm
by Buddha443556
McGruff wrote:In procedural apps like phpBB, I'm not sure how you would identify discrete units to test in the first place and I've never heard of a procedural analogue for test driven design.
You wouldn't. You would test the state of shared data structures.

Posted: Wed Sep 14, 2005 6:49 pm
by Christopher
You guys are still at it? At this point I often make some scandalous, tabloid style post (usually at McGruff's expense ;)) but I just can't bring myself to.

Can you at least move from bickering about coding style to a comparison of the current state of Structured design and OO design. It would perhaps be enlightening to huddled masses yearning to build better apps to learn about the available design options.

Posted: Wed Sep 14, 2005 6:54 pm
by McGruff
arborint wrote:You guys are still at it?
:)

Well, hopefully there are a few ideas in here which someone might find interesting.

Posted: Wed Sep 14, 2005 7:01 pm
by feyd
There is discussion among the moderators to create a "superthread" about this subject, discussing the rises and falls of each side of this subject. Afterwhich, because of highly volatile feelings and fragile emotions on the subject, further threads will basically be barred from existing.

The details of how and who can participate are still being debated, but stay tuned.. We hope to lay out rules for it shortly if we're going to go through with it.

Posted: Wed Sep 14, 2005 7:04 pm
by Nathaniel
McGruff wrote:Well, hopefully there are a few ideas in here which someone might find interesting.
I find all of this very interesting, please do continue :)