Page 1 of 1
OOP users
Posted: Wed Jun 29, 2005 7:14 am
by Roja
I'm working on converting from a purely procedural "users table" implementation to an OOP design.
Here's the extremely simple schema:
Code: Select all
<field name="email" type="C" size="60"><notnull/></field>
<field name="password" type="C" size="40"><notnull/></field>
<field name="c_code" type="C" size="8"><notnull/></field>
<field name="active" type="C" size="1"><notnull/><default value="N"/></field>
<field name="notes" type="X"></field>
Notes allow admins to store information about a user, active is set only after they've gone through the confirmation sequence, and password is a sha hash. Email is email.
Any suggestions on what I'll need the class to have? I figured I'd need at least the following methods:
adduser(), rmuser(), activate_user(), usernote()
Any suggestions beyond that are welcome.
Posted: Wed Jun 29, 2005 10:13 am
by pickle
I would have 1 object called, of course, `user`. In that class I would have all the get and set functions for all the different properties.
I wouldn't have the adduser, removeuser, etc. functions in the user object - seems illogical to me to have the user object add itself (and to what?). That's just me though.
I'd suggest having an object that represents the environment in which these user objects are used. For example, if there are multiple users attached with a customer account, I'd make a `customer` object and throw the add_user(), remove_user(), etc. functions in there.
Posted: Wed Jun 29, 2005 12:11 pm
by Roja
pickle wrote:I would have 1 object called, of course, `user`. In that class I would have all the get and set functions for all the different properties.
Interesting approach, hadn't thought of it that way.
pickle wrote:I'd suggest having an object that represents the environment in which these user objects are used. For example, if there are multiple users attached with a customer account, I'd make a `customer` object and throw the add_user(), remove_user(), etc. functions in there.
Actually, its the other way around.
There are users, and those users have "characters" in various games (multiple).
The games however shouldn't generally touch the users - only the characters. The user objects would only be touched by the login/signup system (aka the frontend).
Thoughts?
Posted: Wed Jun 29, 2005 12:19 pm
by pickle
What would these function do?
adduser(), rmuser(), activate_user(), usernote()
Do they act on the users or the characters? If the user, you could probably make an activate() and add_note() function to the user object.
I read somewhere that a function in an object shouldn't need to have the object name in the function name. For example, activate_user() should be called activate() if it's included in the `user` object.
If it's just the login that uses this object, I don't think the creation and removal of the user account needs to be in an object itself. Plain code should suffice to add, remove and do other things to the user.
Posted: Wed Jun 29, 2005 12:49 pm
by Roja
pickle wrote:What would these function do?
adduser(), rmuser(), activate_user(), usernote()
Adduser - adds a new user
rmuser - removes an existing user
activate - sets the "active" flag in the user account
usernote - sets a note on the user account
pickle wrote:
Do they act on the users or the characters? If the user, you could probably make an activate() and add_note() function to the user object.
Correct - the users.
So what about the create/delete? Should I use a constructor for that?
pickle wrote:
I read somewhere that a function in an object shouldn't need to have the object name in the function name. For example, activate_user() should be called activate() if it's included in the `user` object.
Good point.
pickle wrote:
If it's just the login that uses this object, I don't think the creation and removal of the user account needs to be in an object itself. Plain code should suffice to add, remove and do other things to the user.
Well, to be honest, I was kind of trying to see if it lent itself to OOP. It seemed like a natural object, and I've been doing nothing but procedural code for several weeks now.
So, we've got object user, with activate and note. What do I use for creating and deleting the user objects?
Posted: Wed Jun 29, 2005 12:57 pm
by pickle
Well, I guess you could put those functions in the user object as well. I got to thinking about them, and ya, they would fit in the object.
If I were doing this, I'd use different terminology, though, like "initialize()" and "destroy()". Those seem more fitting to what's being done. Calling the functions add() and remove() doesn't make me immediately think they should be in the object. The initialize() function would, in my head, store all the values you've already set for the user, in a database. The destroy() method would just remove all properties for the user from the database.
However, your brain probably works different than mine, so just call them whatever works for you.
Posted: Wed Jun 29, 2005 7:55 pm
by McGruff
Patterns like ActiveRecord or RowDataGateway (I think you might have the book - see
http://martinfowler.com/eaaCatalog/ if not) might be useful.
But what exactly do you want to do? Usually a "User" object is discouraged as being too vague. What roles do you want objects to perform? I find it more helpful to identify "doers and jobs to be done" rather than "nouns" which often turn out to be just data. I can see:
- registration
- authentication
- authorisation
- persisting changes to user data
If you like, we could try evolving the system using test-driven-design?
Posted: Wed Jun 29, 2005 10:04 pm
by neophyte
McGruff wrote:
I find it more helpful to identify "doers and jobs to be done" rather than "nouns" which often turn out to be just data. I can see:
- registration
- authentication
- authorisation
- persisting changes to user data
Great advice! I'm working on a user system myself in php5. I've made a complete mess of it. I broke into two: authorization and user managment. Authorization handles login, logout, and anything that has to do with auth. Part two is an extentsion with creation, update, and recovery. I figure it's pretty much goes into the category of "the giant do everything class". Did I mention it reports errors and validates too?

I'm hoping to break it up. I need to read more about oop patterns. Good luck on your system Roja!