Which of the following is the best way to make a user management system with oop

[matthewhaworth]

Ok, recently, as you can probably derive from the threads around this one, I have learnt a lot about, inheritance, abstract classes, interfaces and abstract factories..

 

After thinking a lot into I decided this is a possible option:

 

I create a class called 'UserFactory' that returns either the admin or user class.. but i don't think that's efficient because where would the register and login methods go? In the factory? but then its' not just a factory :S.

 

I create a user class, and usermanagement class, the usermanagement class deals with login, register, setsession etc, but the user class deals with stuff like, profile, pictureupload, etc..

[nloding]

Alright, this is getting downright weird -- that's exactly what I've been working too for my site ... at least that's what I'm starting with.  What use is a forum if you don't have users to post on it?

 

Here's my outline that I'm working on now and I think it'll work for me:

 

Database class, with child classes for users, security, forum, etc.  Anything that has a custom database call that is standard (ie, user database class has a specific register user function; the security db class has a function to compare the provided username and password for logging in).  There is a database factory for that.

 

User class, with a child class for admins.  Admins can do everything users can, plus some.  And a factory can create these too.

 

I think that's where I'm going with it -- I definitely know that's how I'm doing the database object at least.

[matthewhaworth]

Alright, this is getting downright weird -- that's exactly what I've been working too for my site ... at least that's what I'm starting with.  What use is a forum if you don't have users to post on it?

 

Here's my outline that I'm working on now and I think it'll work for me:

 

Database class, with child classes for users, security, forum, etc.  Anything that has a custom database call that is standard (ie, user database class has a specific register user function; the security db class has a function to compare the provided username and password for logging in).  There is a database factory for that.

 

User class, with a child class for admins.  Admins can do everything users can, plus some.  And a factory can create these too.

 

I think that's where I'm going with it -- I definitely know that's how I'm doing the database object at least.

 

I might implement the database class instead of passing it to the new object, thinking about it.. let me know how your forum goes

[keeB]

Let me give some hints:

 

AuthenticationInterface -- Interface which describes Authentication Services

AuthenticationServiceImpl ----- Implements AuthenticationInterface

 

If at some point, you ever want to register different types of things (I can't come up with a useful idea right now, but will think about it a bit more)

 

UserAuthenticationDao -- Member class of AuthenticationService, used to wrap UserAuthentication related SQL statements.

 

User

 

 

doLogin.php (the page which validates the login, or the object which does) would look something like this:

 

// this is dumbed down.
<?php
$user = $UserFactory::getUser($userName);// <-- could return an Admin User, Reg User, No User, and you're guaranteed that AuthenticationServiceImpl will accept all of them since they implement the same interface. (this is the fun, power of abstract factory)
$login = new AuthenticationServiceImpl($user);
$login->validate();

//this way if it's really inside client code
if ($login->status()) {
    //register session information
    //redirect to member page
}


//or this way if the logic is encapsulated in like Login.class.php

if(!$login->status()) {
    throw new InvalidLoginException("Could not be authenticated");
} else {
  return true;
}

?>

 

I hope that wasn't too scattered, I just woke up about 10 minutes ago

[matthewhaworth]

Let me give some hints:

 

AuthenticationInterface -- Interface which describes Authentication Services

AuthenticationServiceImpl ----- Implements AuthenticationInterface

 

If at some point, you ever want to register different types of things (I can't come up with a useful idea right now, but will think about it a bit more)

 

UserAuthenticationDao -- Member class of AuthenticationService, used to wrap UserAuthentication related SQL statements.

 

User

 

 

doLogin.php (the page which validates the login, or the object which does) would look something like this:

 

// this is dumbed down.
<?php
$user = $UserFactory::getUser($userName);// <-- could return an Admin User, Reg User, No User, and you're guaranteed that AuthenticationServiceImpl will accept all of them since they implement the same interface. (this is the fun, power of abstract factory)
$login = new AuthenticationServiceImpl($user);
$login->validate();

//this way if it's really inside client code
if ($login->status()) {
    //register session information
    //redirect to member page
}


//or this way if the logic is encapsulated in like Login.class.php

if(!$login->status()) {
    throw new InvalidLoginException("Could not be authenticated");
} else {
  return true;
}

?>

 

I hope that wasn't too scattered, I just woke up about 10 minutes ago

 

Thanks for the elaborate reply .  All this is confusing me, I still think the interfaces are pretty useless, but meh.  I have a method of doing it now that I'm not to keen on, but ill go with it.. the reason I'm not to keen on it is because I have a class called UserManagement that deals with registration, login,  but when they login, it returns a class.. so I call it a KIND of factory.. all the functions are called like $usermg::Register(); but I don't know if it's a factory..

[nloding]

From what I understand, a "factory pattern" returns objects, so that wouldn't really be a factory.  Ultimately, if it works for you, than do it.  From all I've learned in the last week, I'll be damned if I stick with a pattern 100%.  And sometimes, too many objects just gets stoooopid.  Too many objects, too many functions, what's the difference?  At some point you gotta sit back and say -- OK, it works, I understand it, my code is clean, I'm done.

[matthewhaworth]

From what I understand, a "factory pattern" returns objects, so that wouldn't really be a factory.  Ultimately, if it works for you, than do it.  From all I've learned in the last week, I'll be damned if I stick with a pattern 100%.  And sometimes, too many objects just gets stoooopid.  Too many objects, too many functions, what's the difference?  At some point you gotta sit back and say -- OK, it works, I understand it, my code is clean, I'm done.

 

Aye, check my diagram in my new thread