Page 1 of 1
Question for you OOP developers
Posted: Tue Aug 20, 2002 12:26 pm
by JPlush76
What do you use objects for mainly?
I've been reading alot of samples on the web that aren't pratical applications of OOP
I'm trying to figure out the advantages of OOP and see if I'm in need of streamlining my site with objects.
Posted: Tue Aug 20, 2002 12:54 pm
by BDKR
This is the kind of thing that's likely to turn into a holy war (Flame war for you purists). Many believe that the use of objects just leads to bloated code. Just read the linux kernel developers mailing list for a bit.
Now when you get right down to it, you can use objects for whatever you want, but it's the kind of thing where in a web environ, they are best kept small. Many in the php community use objects to abstract database connectivity. This makes tons of sense as well. There is support in PHP for a large number of db's, but with objects, all of that can be abstracted into one set of commands. Something like...
Code: Select all
if($query_conn->doQuery()==true)
{ /* Do something with query here */ }
... would work with Postgres, Mysql, Oracle, Sybase, and on and on and on.
Objects can also be used in a modular fashion. As opposed to worrying about hierchal trees and all that oop jazz, you have an object that stands alone and does one thing and one thing only. It only has enough to do that job and nothing else. The good thing about objects like this is that they become very easy to plug in to your code if they are well designed (the interface) and have very little overhead.
Ultimately, I feel that objects are cool, but should be used carefully in a web environ where the life of a running process is extremely short and is best designed with that in mind.
There are other issues concerning execution speed as such. But that's not what you signed on for so I'll stop right now.
Seriously, just read some general books on oop if you can and develop your own methodolgy for doing things. And consider those of others as well. It won't be long before you're pretty comfortable with your own approach.
Later on,
BDKR
Posted: Tue Aug 20, 2002 1:04 pm
by nielsene
The larger a project is, the more objects I use and the more object-oriented my designs become. I'm blessed with a relatively high power server that's underutilized and will likely remain that way, so I'm willing to take the object performence hit. I suspect as versions of PHP progress, objects will becoming increasingly efficient, but will probably never equal straight procedural code.
I have my own DB and QueryResult class that I used for all database interactions. (Keep meaning to migrate to one of the "standard" DB abstractions, but haven't) I tend to subclass by DB to <AppName>DB to provide the common information queries needed by a given application. My DB is bare bones, connects in the constructor and provides 3 methods: query, getError, and getLastOID. The AppNameDB would make things like getNumPosts, getLanguangeChoices, etc. For me these are always information retrieval only and only for things like statistics. Most database queries are handled by the next layer.
I have a "StoreableObject" base class that handles mapping class attributes to database tables/fields. It provides retrieveByID,post, and search methods. Then I subclass Person from it and the constructor defines the actual mapping of attributes to table/fields. In my main project the storeable objects are Person, Competitor, Couple,Organization, and RegOrginzation. Most of my "business" logic lives at this level.
I have a UIBase class and the derived HTMLDisplay class for formating output. Similarly I have a LaTeX class for formatting data for printed form.
I'm working on my authentication class family now, will probably look something like User, Guard, Gate. User tracks the username,id,and permission level. Gate blocks access to a page unless the user possess the proper permission level. Guard is a utilitiy class that will probably handle most of my data sanitizing; it might also have the ability to grant higher permission levels to a user in well-defined circumstances.
I aim to implement a proper n-tier architecture with increasing levels of abstraction. Only my DB class uses database specific commands. Only StoreableObject, its descendants, and DB descendates should include SQL queries. Only UIBase, and its descendats, generate output. Ie only HTMLDisplay fools around with html tags.
Everytime I've gone back and converted a series of related function/data from my utilities include, my code has gotten cleaner and easier to understand and maintain.
Posted: Fri Aug 23, 2002 3:16 am
by daemorhedron
The only time I could personally justify oop in web design would be in a db layer (already mentioned) and MAYBE a skinning/caching/templating engine, but the one I wrote is just procedural code. CLI applications however are a whole other story. I just personally don't see the use of oop in web design, or at least as often as I see it on the web. It seems annoyingly trendy to use oop in php these days, and everyone seems to be cramming their functions into a class to join the club. Just use the right tool for the right job, and you'll do fine.
Posted: Fri Aug 23, 2002 3:02 pm
by Takuma
I created MySQL library, Mail library, and creating Tempalte library in OOP. I think it's good having to use OOP in PHP as using only functions can get a little tidious when you are stuck with thinking a function but the one you have already defined.
Posted: Fri Aug 23, 2002 3:59 pm
by BDKR
daemorhedron wrote:CLI applications however are a whole other story.
You prolly want to be careful there as well.
I wrote a load balancer using PHP that is using a combination of objects and procedural code. I feel that the freedom to use either / or is extemely powerful and the elegance of being able to abstract huge hunks of code behind an object is, to use a term form the 70's,
BITCHIN!
I just personally don't see the use of oop in web design, or at least as often as I see it on the web.
I agree for the most part. Just because we can doesn't mean we have too! But let's not throw out the baby with the bath water.
....., and everyone seems to be cramming their functions into a class to join the club.
This brings up something that I agree with heartily. Objects should not be former function libraries. However, some classes are desigjned as though they were. A good example is all of the available mysql functions. Just becuase it's mysql, do you put all of them into your mysql class? Last I checked, there are over 40 functions for mysql alone!
Instead, an object should only have what's needed to do
A (as in one) job. Anything else is bloat. Just take a look at the Form class in the Pear library. In each instantion of that class, you're not going to use a third of those functions! That is what I call unneeded overhead. Where as the query object from the Eclipse library (version 1 at least) only has what's needed to execute and return queries.
Anyways, I like OOP, but much of what's going on in the PHP realm where OOP is concerned is a little off track. It's the kind of thing where you need to really learn about it as opposed to just figuring out how to instantiate and object and you're off to the races. Perhaps there needs to be a best practices concerning OOP in php. However, that's almost certain to start a flame war.
Later on,
BDKR