Q:

Design pattern for users

I'm starting to code my project and I have used, in some past unfinished project, two different patterns to manage the design of a user class that will need to manage the following things:

The creation of a user
The edits to a user
The deletion of a user
The reading of user data

Despite this, we have also to consider that this user class will be extended by the session class which will just set the focused user id as the id provided by the user who is viewing the pages.
We will also have this class users that will manage instead groups of users.
The 2 options I used are the following (simplified):
Different class for different purpose
- class UserMaker($username, $password, $email);
    function giveBirth(); // create the user

- class UserManager($id);
    function edit($field, $value); // edit a specific user field
    function save(); // save all the edits with a single query
    function setTrusted(); // set that user as trusted
    function setAdmin(); // set that user as admin
    function setBanned(); // ban the specific user

- class UserReader($id);
    function get($field); // Get the value of a single field
    function getAll(); // Get all fields from that user as associative array
    function isAdmin(); // self explanation
    function isRegistered(); // self explanation
    function isBanned(); // self explanation

Single class
- class User($id);
    function static giveBirth($username, $password, $email); // create the user, notice this is static

    function edit($field, $value); // edit a specific user field
    function save(); // save all the edits with a single query

    function setTrusted(); // set that user as trusted
    function setAdmin(); // set that user as admin
    function setBanned(); // ban the specific user

    function get($field); // Get the value of a single field
    function getAll(); // Get all fields from that user as associative array

    function isAdmin(); // self explanation
    function isRegistered(); // self explanation
    function isBanned(); // self explanation

Basically, since the only class that does not accept $id as argument for the __construct() is UserMaker we just set the function giveBirth() as static so we can create the user.
What is the best way to design this pattern? Have you got a third-option which you feel better than these?

A:

Well, the answer to this question relates specifically with The Single Responsibility Principle.  Basically, each and every class in your application should have exactly one responsibility.  That doesn't mean that it can't be used in more than one situation, but it shouldn't be responsible for more than one abstract concept.
So, from your examples, I would build a class structure similar to this:
class UserFactory() 
    getModel();
    getUser($id, $model = null);
    getACL($user);

class UserModel ()
    edit($id = 0);
    load($id = 0);
    reload($id = 0);
    save($id = 0);

class User ($data)
    getAll();
    getField($field);

class UserACL (User $user)
    isTrustedUser();
    isAdminUser();
    isBannedUser();

That way, everything is organized by responsibility and role, rather than by relation.  The benefit to this, is that if you want to swap out an individual component later (for example, the ACL system, or the Model storage layer), you don't need to worry about testing a huge class.  Just test that particular API and you're done.

