I am familiar with OOP. I have taught myself everything I know and have an ok grasp on it. I'd say medium at least but i'm sure someone will chime in and drop me down a peg or two.
Anyway, I guess i'm having a problem figuring where to put database select, delete, update, insert function/methods.
Like say I have a user class and I have all of my private variables and the constructor and the get and set methods in my class already. Now I want to interact with the database. I want to load a user object with data from a database record, insert a new record, update, delete etc.
My question is: Do I put these methods in the USER class (with the get and set methods) or make a new class which handles the Database side of the USER class () possibly called USERS. I guess I am asking what is considered the best form in terms of OOP principles. I was just thinking I probably would not want to get a list of all users from a single user object though I may want to update the single user object in the DB. I may have already answered my own question.
Thanks for everyones insight in advance.
OOP PHP Help
Moderator: General Moderators
- novice4eva
- Forum Contributor
- Posts: 327
- Joined: Thu Mar 29, 2007 3:48 am
- Location: Nepal
Re: OOP PHP Help
It is perfectly OK
, but i was not clear somewhere in the middle if you were asking for a abstraction layer, i mean a class that has wrapper functions for all your database related functions{mysql_query(), mysql_fetch_array() etc etc}. If that's not the case then i don't see anything wrong with your concept. But if my hunch was true, then you should make separate class for handling database related functions, and use this class to make any DMLs, DDLs. Few advantages i see with this are:
1. When you think of moving the database say from mysql to oracle, then your work is reduced. The sql is more or less same, all you've got to do is make a function with same name the does oracle equivalent job(ummm haven't faced this issue but i think this must be achievable)
2. And as you said from your {get, set} functions, sounds like they will be used a lot(common thing). Putting common things is one bag SOUNDS good : IS GOOD, again when modifications has to be made it's just in one class.
I think everybody knows these things, i don't want to be officious
There are more brilliant people out there, i think even i'll get out of this achieving something more.
1. When you think of moving the database say from mysql to oracle, then your work is reduced. The sql is more or less same, all you've got to do is make a function with same name the does oracle equivalent job(ummm haven't faced this issue but i think this must be achievable)
2. And as you said from your {get, set} functions, sounds like they will be used a lot(common thing). Putting common things is one bag SOUNDS good : IS GOOD, again when modifications has to be made it's just in one class.
I think everybody knows these things, i don't want to be officious
There are more brilliant people out there, i think even i'll get out of this achieving something more.
Re: OOP PHP Help
i guess what I was really trying to get at is:
i have a class: say user, it has its methods to do with a single user object. it's methods deal with one particular user in general. one instance if you will. and I can see where you would want to use some sql methods ("select" to load the object, say given an id) ("update" to save the object back in the db after data has been altered) and possibly delete a record in the DB.
However, inserting a new "USER" (at least in my mind) does not seem to fit in this class/object. It seems it should be somewhere else. I am thinking also that getting a list of objects of all users would not seem to fit into this class/object either.
Maybe I am wrestling with singularity vs plurality? As if I should have a User class and a Users class. One to handle the single object (User) and the other to manipulate groups of objects (Users).
Does this clarify things?
If i am looking at a DB table, is it proper to think of a single record in that table as a single object? And to think of the table records wholly as a group of singular objects yet all of them together comprising an object itself?
Can someone suggest some reading on this topic?
i have a class: say user, it has its methods to do with a single user object. it's methods deal with one particular user in general. one instance if you will. and I can see where you would want to use some sql methods ("select" to load the object, say given an id) ("update" to save the object back in the db after data has been altered) and possibly delete a record in the DB.
However, inserting a new "USER" (at least in my mind) does not seem to fit in this class/object. It seems it should be somewhere else. I am thinking also that getting a list of objects of all users would not seem to fit into this class/object either.
Maybe I am wrestling with singularity vs plurality? As if I should have a User class and a Users class. One to handle the single object (User) and the other to manipulate groups of objects (Users).
Does this clarify things?
If i am looking at a DB table, is it proper to think of a single record in that table as a single object? And to think of the table records wholly as a group of singular objects yet all of them together comprising an object itself?
Can someone suggest some reading on this topic?
Re: OOP PHP Help
You can go for a factory-esque pattern, where the Users class gives you a User object: you do something like "$u = Users::byName('Alice')" rather than "$u = new User('Bob')".
Personally, I make classes like
By organizing stuff like that it makes more sense (to me) to put them inside the "singular" class rather than create a factory or "plural" class.
Now collections are a different matter: they're more than just multiple objects. In those circumstances I create a second class like
So I guess my rule of thumb is like this:
If it's simply a list of users with no real meaning then I make a User::fromFoo static function which returns an array of Users; if the list of users has another meaning then the "meaning" itself gets its own class.
Personally, I make classes like
Code: Select all
class User {
public function __construct($name); // only used when creating a new user, not loading one
// static functions to create a User
public static function fromName($username);
public static function fromID($id);
public static function fromGroup($group); // this returns an array of Users
public function save();
}Now collections are a different matter: they're more than just multiple objects. In those circumstances I create a second class like
Code: Select all
class UserGroup {
public $users; // array of Users
public function __construct($groupname); // only for creating a new user group, not loading one
// returns a UserGroup
public static function fromGroupName($groupname);
}If it's simply a list of users with no real meaning then I make a User::fromFoo static function which returns an array of Users; if the list of users has another meaning then the "meaning" itself gets its own class.