2006/9/29, Ray Hauge <ray.hauge@xxxxxxxxxxxxxxxxxxxxxxx>:
I think people have pretty much hit the nail on the head with OOP. One thing that I would like to point out is that OOP isn't necessarily needed in every case.
Actually there's never a need to use OOP. As I said before OOP doesn't provide anything in terms of functionality. The client will give a shit if you use OOP, AOP, Modularity, Structural Programming, Functional Programming or anything else there's out there. It's not about if we need it or not, because we don't. It's about if we prefer to use OOP or not. Real OOP is not just being able to code classes. Real OOP is about designing useful classes. There are times when making a class to abstract a certain
feature/process is a good idea, and there there are times where it can go a bit too far. This is definitely a very simple example, but the usual "Hello World" script doesn't exactly need to be writen in a class structure.
Why not? If you're simply thinking of a class that does an echo, then there is no point in using classes or not, but if you start thinking the problem in terms of object abtraction there is a whole bunch of things that can be shown with a simple "Hello World". I usually try to ask myself this question when I'm designing something:
"What are the benefits of using OOP?" If the answer is simply "To use OOP" then you're probably headed in the wrong direction, at which point I step back and look at the big picture again.
You're right: if you don't know how you can benefit with OOP then you definetely shouldn't be using OOP. In short, OOP is something to be used to your advantage, but if overused can
just cause unnecessary overhead and confusion (IMO)
I think *overused* is misleading, I would say *misused*.
