OOP users

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

OOP users

Post 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.
User avatar
pickle
Briney Mod
Posts: 6445
Joined: Mon Jan 19, 2004 6:11 pm
Location: 53.01N x 112.48W
Contact:

Post 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.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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?
User avatar
pickle
Briney Mod
Posts: 6445
Joined: Mon Jan 19, 2004 6:11 pm
Location: 53.01N x 112.48W
Contact:

Post 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.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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?
User avatar
pickle
Briney Mod
Posts: 6445
Joined: Mon Jan 19, 2004 6:11 pm
Location: 53.01N x 112.48W
Contact:

Post 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.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post 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?
User avatar
neophyte
DevNet Resident
Posts: 1537
Joined: Tue Jan 20, 2004 4:58 pm
Location: Minnesota

Post 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? :oops: I'm hoping to break it up. I need to read more about oop patterns. Good luck on your system Roja!
Post Reply