General OOP Question

Kudose

Hello all.

Is it better to write your classes with or without SQL contained within the methods?

Should I have a database class and extend the rest from the DB class?

Thanks. 🙂

thorpe

ok... im only new to php, and even newer to oop, but... this is how ive been doing things.

say your making a blog. i would create a database abstraction class, containing methods that return result arrays, and booleens for queries that return no results.

i then create a blog class, with methods such as add(), editbyid($id),delbyid($id), getall()......blah blah.

i then create an instance of my database absraction class inside the construct of the blog class. the blog classes methods deal with all the sql.

i suppose you could make the blog class an extension of the db class, but this is how i would do things.

planetsim

A class is meant to be specifically created to do one task. Its also meant to be reusable and portable to other projects, after saying that some classes will be specific to the project at hand although can and should be usable from within the project would be utterly useless in another.

Now thorpe hasnt done too bad a job explaining OO, however going back to extending classes not entirely specific to that class is poor OO design.

The reason being to be really extending another class it should be specific to the class being extended. Although Blog may use DB Class methods its not related in anyway to the DB Class.

If you plan on extending a class making sure the two classes will use the methods, variables of the class and are similar. An example of this is having a class called animal as the top layer class. Controlling things like the Animals age, name, location etc, and creating a Dog Class which extends the Animal class still using the Age, Name, Location but adding specifics like breed, colour, etc.

We could than create other classes from Animal like Bird, Cat, etc we could also create a Class called Spaniel Specific to the Dog class (taking out the breed bit of course) with more specifics to breed.

I hope that helps a little on how Classes should be extended.

Now before you delve deeply into OO, you should really learn OO Concepts as they may seem pretty easy at first but there is more to OO then meets the eye. There are specific books on OO Concepts and many tutorials with a good Google Search would find you some.

pohopo

IMHO,

If possible, all your SQL should be in stored procedures. If that is not possible (ie you use MySQL) I would say it depends on what you are writing it for.

If you plan to create an open source application that you want to work with many different databases you would want a database abstraction class. Though I have not used it before pear.php.net offers this class so you might want to check it out.

If this is specific to one database that is not going to change then I don't see anything wrong with having the SQL in your classes. This would be the easiest way, but it is not as robust as having an interface class.

Bunkermaster

rule #1:
seperate processing and interfacing.

Example:
I have a class with all my business processing and it holds all my interfacting with my SQL DB too + the queries. My boss comes in and tells me I need to change DB system. I'm screwed.

Solution:
Seperate process and interfacing. Should the data source change you would only have to modify the data interface and not the processing.

My 2 cents (which made my systems highly maintenable and easy to develop with a good design)

Bunkermaster

oh yeah and never put any mysql_xxx call in your code, use generic methods for the db class you'll have cleverly created in case just the db changes, not the db and the storage format.