Results 1 to 25 of 190
May 22, 2006, 03:52 #12
Originally Posted by McGruff
- Join Date
- May 2005
- 0 Post(s)
- 0 Thread(s)
- Templates themselves (a "templating" class is usually a good idea, but templates should be pretty much just plain text with some conditional logic thrown in).
- Entry points / boot strapping
- Maintenance scripts
The primary advantages of classes are:
- Modularity (irrelevant since in php you're dealing with individual files...everything is already highly modular)
- Encapsulation (depending on context can be important or not. Generally speaking, it's a lot easier to encapsulate data with classes than without, but php's file-scoped nature means that you have other options).
- Reusability (largely irrelevant to a dynamically typed, interpreted language since you can very easily reuse the same function call or include line for many different types of data without issue)
- Aiding in self-documenting code (ppp methods are more about documentation than actually enforcing anything. Many languages don't actually enforce the constraints at run time, and are only checked at compile time).
That being said, using classes within php generally gives you some advantages, but they aren't the traditional variety:
- Using classes as "namespaces"
- Taking advantage of autoload / class_exists / method_exists / interfaces for some truly dynamic programming.
- Ability to override behavior of many engine internals using SPL.
And, of course, exceptions are tremendously useful, but there's no real reason why an exception has to have anything to do with objects.
Most of the traditional advantages afforded by classes are beneficial in the nasty world of strong, statically typed, compiled languages, but have little impact on the paradigm under which PHP shines.
Well, you can't deny that a code is definatly of better quality if it uses one class to handle let's say all the news functions instead of retyping all of the code everytime you need to do something with news.
The problem with java in this regard is that primitives aren't objects; if they were, all that functionality could simply be replaced with method calls to number objects, as they are in Ruby. So really, this is a case of the language not being OO enough.
Wrapping functions in a class is useful in PHP because there isn't a namespace, but wrapping the native functions that you're never likely to alter in a class just for the sake of being "more OOP" is a waste of your time. I can say with a fair degree of certainty that you're not going to be re-implementing functions like sqrt, pow, and other basic math routines any time soon.
There's nothing wrong with mixing procedural and OO code. Think about ordinary human language -- some times you say something with the noun first, then the verb, and other times you do the reverse.
dog.poop() makes sense, but
walk(dog) does too.
poop.dog() and dog.walk() aren't things I think anyone is interested in seeing.
yes you can program everything in procedural (but u can also do the same thing in assembly, (or even binary)) but it just gets rediculos!
OOP doesn't really make development go any faster or make it any easier to maintain. In many cases (such as C++, which is usually just more trouble than it's worth unless you stick to the basic features), it actually slows development down.
or if you have a fetish for brackets you can program in SCHEME, same thing the program will work but ittl be a waste of your time
write a multithreaded server and graphical browser in Java then write the same in procedural C and then youll see for yourself
except for php5 which as language is quite nice and fast but lacks thousands of packages and classes that make Java and .NET languages so usefull for programmers
You have missed the key feature of OO...
$table = new WithCrossLinks(new TableDisplay(new DefaultAccount()));
$table = withCrossLinks(tableDisplay(getDefaultAccount());
Changing the noun-verb relationship has very little real impact on project development.
OO vs procedural code usually boils down to...
$obj = new Object();
$obj = Object();
A lot of the OO stuff doesn't work so well in dynamically typed languages for other reasons; for example, most languages have all kinds of funky ways of creating containers. In php you pretty much always just use a map (what they call "array"). You never think about iterators or insertion operators or any of that. It's just not a problem that has to be solved.
The biggest failing of OOP is that it attempts to solve the problem of "large" systems, when in truth large systems should simply be avoided like the plague. You should break up large systems into small, modular, and INDEPENDENT chunks, ideally with each one operating in separate environments. For large scale systems, this is a must anyway, since scalability pretty much mandates that every component of the system operate on a separate piece of hardware. In this model, OOP vs procedural is meaningless.
Yes, as long as they address problems in PHP, not some other language