I've written a user class based on other supposedly high quality, secure classes I found online (although mixing some of them since, from what I've learned, none was actually that secure). The thing is, inside my script that initializes the different objects, I've got a too long snippet for the $User object. Other objects require as little as $Browser = new Browser(); or $_ = new Translate ($DB, $User->get('Language'));. So, it feels kind of ugly to have all this code suddenly here:
/* USER. Handles user data and login/logout/register. */
$User=new User($DB, Configuration::get('SiteKey'));
if (isset($_POST['logout']))
$User->logout();
else if (isset($_POST['login']) && !$User->login($_POST['email'], $_POST['password'])) // If user tries to login
$Error->set ('Banner', 'Username or password incorrect. Please try again.');
else if (isset($_SESSION['email']) && isset($_SESSION['session']))
$User->loginSession ($_SESSION['email'], $_SESSION['session']);
else if (isset($_POST['register']))
$User->add ($_POST);
/* Language */
if (!empty ($_POST['lang']) && in_array($_POST['lang'],Configuration::get('SupportedLanguages')))
{
$User->set('language', $_POST['lang']);
$_SESSION['language'] = $_POST['lang'];
}
if (!$User->get('language'))
$User->set('language', Configuration::get('DefaultLanguage'));
I'm not sure where all this code is supposed to be, should I put this inside the User's class __constructor() or this is it supposed to be outside as it is now?
It's better to pass the $_POST than using it directly inside, which might affect the answer (a __constructor() with too many variables passed isn't also really good).
I don't think the code within the class is so relevant as to append it here, but if you want to see it I just made it publicly available in my github.
I'm not sure where all this code is supposed to be, should I put this
inside the User's class __constructor() or this is it supposed to be
outside as it is now?
I wouldn't put it in the constructor. Whatever script or class you have this code in looks to perform a number of responsibilities. You could consider following the single responsibility principle and separate out this code into other classes such as an authentication class, a session class and a user factory that can build the user object. A brief and by no means carefully architectured example:
class User
{
}
class Session
{
}
class UserFactory
{
public function create($vars, ...)
{
//build user...
return $user;
}
}
class Authenticate
{
public function __construct($userFactory)
{
//...
}
public function Login($username, $passwd)
{
//do stuff...
return $userFactory->create($vars, ...);
}
public function AuthenticateSession($session)
{
//...
return $userFactory->create($vars, ...);
}
}
a __constructor() with too many variables passed isn't also really
good
Well you can always group variables into a collection object and pass that in the constructor. For example language and time settings could be grouped into a culture object.
Related
I saw this code on a different question - 2nd answer link and the first comment was that it is a static factory anti-pattern and that it violates SRP:
class User {
public static function create($userid) {
// get user from the database
// set $isPartner to true or false
// set $isClient to true or false
// set $isModerator to true or false
if ($isPartner) {
return new Partner($userid);
} elseif ($isClient) {
return new Client($userid);
} elseif ($isModerator) {
return new Moderator($userid);
} else {
return new User($userid);
}
}
}
$person = User::create($userid);
Now I can understand why it violates SRP - because it deals with connecting to the database as well as building the new class, but besides that I'm not sure if I understand why it is an anti-pattern.
I wanted to write a bit of code that seemed quite similar to this so I am now wondering whether to avoid it, this is my code (in pseudo-code):
class DatabaseClass()
{
...deals with getting a result from the database...
}
abstract class User()
{
...base class for all users...
}
class AdminUser extends User(){}
class StaffUser extends User(){}
class BasicUser extends User(){}
class UserFactory()
{
function createUser($privilege)
{
if($privilege=="high")
return new AdminUser($privilege);
else if($privilege=="med")
return new StaffUser($privilege);
else
return new BasicUser($privilege);
}
$db=new DatabaseClass($username,$password);
$result=$db->getUser();
$userfactory=new UserFactory();
$user=$userfactory->createUser($result);
Now at the moment I am not using a static method but would my oop still be considered an anti-pattern?
Especially since I don't really see any difference in then doing something like this instead and it being pretty much the same thing:
$result=DatabaseClass::getUser($username,$password);
$user=UserFactory::createUser($result);
No, it's not an anti-pattern. Personally, I take the term "anti-pattern" with a grain of salt whenever I see it. It's far too easily tossed around by people who don't like your code but can't really articulate why.
The problem with a static factory is that any class which uses the factory must explicitly depend on it. That violates the principle that we should depend on abstractions rather than concretions (the 'D' in SOLID). This makes code using the factory harder to re-use and unit test. But keep in mind that the approach has benefits too. It's easier to write and easier to understand.
Your code is equivalent to a static factory method. The problem in both cases is that the caller must know the concrete class of the factory.
Your factory is not the issue, is the conection to the db i guess.
Other than that, you're using the factory method well.
Upon seen the edit, its for the best that you separate the data access from the factory.
It's not so much an "anti-pattern" as a bad idea from the maintenance perspective.
I would still be ok (not so good but still ok) if you had your data access code inside the factory as long as that code was in a separate class (that is reused across the application for data access) and you just call it to get something you need. In that case it'd be a combination of two patterns, a factory and a facade.
What i'd really pay attenntion to is to find out if the data isn't going to change during the session, if so just go one time to the db an keep the results. If you only create the User (or derived classes) once, make damm sure you only do it once.
That i think is more important that respecting patterns blindly.
PHP has functionality of dynamical class instantiation where class name that should be instantiated could be a variable. The following code works fine:
$classname='User';
$Object=new $classname; //instantiates new User()
This code instantiates that class whose name is stored in $classname variable.
I'm not so well with the Factory Pattern, however, if you want to have some benefit, it could abstract the creation based on persistence variation, e.g. if it's adapting the database for users or not.
class DatabaseUserFactory implements UserFactory
{
private $dbClass;
function __construct(DatabaseClass $dbClass)
{
$this->dbClass = $dbClass;
}
/**
* #return user
*/
function createUser()
{
$result = $db->getUser();
return $this->createUserByPrivilege($result->getPrivilege());
}
private function createUserByPrivilege($privilege)
{
if ($privilege == "high")
return new AdminUser($privilege);
else if ($privilege == "med")
return new StaffUser($privilege);
else
return new BasicUser($privilege);
}
}
$db = new DatabaseClass($username, $password);
$userfactory = new DatabaseUserFactory($db);
// ...
$user = $userfactory->createUser();
The following is an excerpt from some code I wrote to assign the $user->privilege based on a method from that same class. It seems excessively repetitive, and I am wondering if there is something I can do to make it more readable -- given that I haven't seen this kind of repetition too much in codes I have looked at.
$user -> privileges = $user -> get_privileges ( $user -> username );
It doesn't look particularly repetitious to me, but it is a little unusual to be assigning an object's property based on a method outside the class. Instead, this might be better handled inside the object constructor, eliminating the need for you to remember to set the property when coding:
class User {
public $username;
public $privileges;
public function __construct() {
// setup the user however that's done...
// And assign privileges in the constructor
$this->privileges = $this->get_privileges();
}
// In get_privilegs, rather than passing the username property,
// just access it via $this->username.
// Unless you need to use this method from time to time outside the class, it can be private
private function get_privileges() {
// Get privs for $this->username
}
}
And as an alternative to $this->privileges = $this->get_privileges(); called in the constructor, you might just set $this->privileges inside the get_privileges() method. Then you can just call it as $this->get_privileges() in the constructor, no assignment necessary. Either way works.
I use this pattern a lot when a method is expensive and I can just store the result for the remainder of the request:
class User {
protected $_privileges = null;
public function getPrivileges() {
if ($this->_privileges == null) {
// code to populate privileges array
$this->_privileges = $privileges;
}
return $this->_privileges;
}
}
That way getPrivileges() will only do the hard work once and afterward it uses its own locally cached copy for the remainder of the request for that object instance.
I have this User class
class User{
private $logged = false;
private $id;
public function User() {
//> Check if the user is logged in with a cookie-database and set $logged=true;
}
public function isLogged() {}
public function editPerms() {}
//> other methods
}
Well now considering I can't have more than 1 user logged (of course because we are talking for a single http request) in Where should i store the ref of my istance?
This is the case where singleton would be useful but these days everyone say singleton is evil (like static methods).
http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/
I could do a $GLOBALS['currentUser'] = new User(); and having it accesible everywhere but I think this is worse than a singleton.
So what Can I do?
Please note I don't need to save this instance between requests. I just need a way to access this instance in my framework within the same request.
If you want to know what i do now for all of my Helper Objects is a Service Container (that's considered as well bad):
function app($class) { //> Sample
static $refs = array();
if (!isset($refs[$class]))
$refs[$class] = new $class();
return $refs[$class];
}
//> usage app('User')->methods();
(IE what symfony does)
Patterns are supposed to be a helpful guide, like a library of previously successful software abstractions. Too often these days people view patterns as being some kind of religion where things are either "right" or "wrong" regardless of the context of the program.
Think about what you want to achieve and map in out in a way that makes sense to you. Fuggering about with minute distinctions between this pattern and that pattern misses the point, and it won't get your program written. Learn by doing!
HTH.
Singletons are not evil. Bad usages of singletons are evil. The reason people have come to dislike this pattern so much (even going to the extent of calling it an anti-pattern, whatever that is), is due to improper use:
Too many inexperienced people make a class a singleton when they find they don't need more than one instance of a class. But the question isn't if you need only a single instance of the class, but whether more than one instance would break your code. So ask yourself this question: would your code break if there were more User instances? If not, then maybe you shouldn't bother. :)
There are legitimate uses of singletons. There are those people who fear this pattern like the plague and consider it always to be bad, without realizing that sometimes it can be very helpful. In the words of a much more experinced programmer than me, "singletons are like morphine: they can give you a real boost, but use them the wrong way and they an become a problem themselves". If you want me to go into some details as to when singletons could be a good choice, leave a comment to this answer. :)
It is always hard to answer architectural questions without the context. In this case it is pretty important how the User objects are persisted (where do they come from?) and how is the client code organized. I will assume a MVC architecture because it's trendy this days. Also I suppose your user objects will have more responsibility as only authentication (you mention some permission control here, but it's still not clear enough).
I would push the authentication responsibility to a service and just pass it around as needed. Here is some sample code.
class AuthenticationService {
/**
* #var User
*/
private $currentUser;
public function __construct(Request $request) {
// check if the request has an user identity
// create a user object or do nothing otherwise
}
public function getCurrentUser() {
return $this->currentUser;
}
}
class User {
public function editPerms(){}
}
// the client code
class Controller {
private $auth;
public function __construct(AuthenticationService $auth) {
$this->auth = $auth;
}
public function handleRequest() {
$currentUser = $this->auth->getCurrentUser();
if ($currentUser === null) { // of course you could use Null Object Pattern
// no user is logged in
}
// do something with the user object
}
}
So the answer to your question is: you need proper dependency injection through out your whole application. The only object you get from the server is a request. The dependency injection container injects it into the AuthenticationService and the latter gets injected into your controller. No singletons, no static methods, no global variables. The dependencies are tracked in the DI container and are injected as needed. Also the DI container makes sure your service is instantiated only once.
The article "Container-Managed Application Design, Prelude: Where does the Container Belong?" may clarify some DI concepts.
Not sure why all the arguing up top. Seems like a perfectly reasonable question to me.
The key here is to use static members of the User class. Static methods are your friends, regardless of what some may say:
class User
{
private $logged = false;
private $id;
private static $_currentUser;
public static function currentUser()
{
if (empty(self::$_currentUser))
{
#session_start();
if (array_key_exists('current_user', $_SESSION))
{
self::$_currentUser = $_SESSION['current_user'];
}
else
{
// force login in or whatever else.
// if you log in, make sure to call User::_setCurrentUser();
return null; //or some special 'empty' user.
}
}
return self::$_currentUser;
}
// you may consider making this public, but it is private because it is a bit
// more secure that way.
private static function _setCurrentUser(User $user)
{
self::$_currentUser = $user;
$_SESSION['current_user'] = $user;
}
public function User() {
//> Check if the user is logged in with a cookie-database and set $logged=true;
}
public function isLogged() {}
public function editPerms() {}
//> other methods
}
// Usage
$pUser = User::currentUser();
The influence of Misko Hevery is pretty strong on me. So is his newable - injectable distinction. A user is not an injectable but a newable. What are the responsibilities of a user: should he be able to tell of himself whether he is logged in or not? There's a post of him where he talks about a similar problem: a credit card and charging it(self?). It happens to be a post about singletons, what you would like to make it:
http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
That would leave it to an service to check whether the user is logged in or not, what rights he has on the site.
It also means your architecture would change, your problem will become different (passing around the user?, where is it needed?, how will you have access to the 'checking user is logged in' service, ...).
since everyone else is weighing in on this, singletons are not evil.
i even read the "liars" article, and he's using a contrived example of non-modular design and poor dependency inheritance.
i think you should consider a singleton factory pattern, where a singleton factory (Auth) provides a login() method which returns a User class, as well as methods for saving state between HTTP requests on that User.
This will have the benefits of separating the security and session functionality from the User functionality. Additionally using the factory, you can have multiple types of users without the rest of the system needing to understand which object to request before the db is examined
class auth {
private static $auth = null;
private $user = null;
// must use getAuth();
private __construct(){};
public getAuth() {
if (is_null($this->auth) {
$this->auth = new auth();
}
return $this->auth;
}
public function login($user,$pass) {
... // check db for user,
if ($dbrow->user_type == 'admin') {
$this->user = new admin_user($dbrow);
} else {
$this->user = new normal_user($dbrow);
}
$this->user->setSession($db->getsession());
}
public function getUser() {
return $this->user;
}
public function saveSession() {
// store $this->user session in db
}
public function saveUser() {
// store $this->user changes in db
}
...
}
the user class itself become a data structure, simply enforcing security and business rules, and maybe formatting some data for output purposes.
class normal_user extends user {
... getters and setters
public function getName() {}
public function setEmail() {}
public function setprofile() {}
}
all db, state and security concerns are centralized in the auth.
the only way to create a user object (legally) is to run auth->login().
you are still allowed to do
$me = new normal_user();
$me->setName();
echo $me->getName();
but there is no way for a new coder to save this in the db since it's not referenced in $auth->user;
you can then create a function in auth to consume user objects to create new users (on signup)
...
public function create(user $user) {
// validate $user
$this->user = $user;
$this->saveUser();
}
...
you just need to make sure you run the save functions at the end of execution...
possibly in a destructor()
simple
I have some code that often looks like this:
private $user;
public function __construct()
{
$this->user = User::getInstance(); //singleton
}
public function methodOne()
{
return $this->user->foo();
}
public function methodTwo()
{
return $this->user->foo2();
}
public function methodThree()
{
return $this->user->foo3();
}
I figure if I set user property to the instance I can reuse a shorter name in my methods (well in this case it's not that much shorter). I also thought doing it this way might save a little resources (beginning to doubt it), but when I look at other people's code I rarely see people do this. They would usually just call:
User::getInstance()->foo();
User::getInstance()->foo2();
User::getInstance()->foo3();
Is there any sort of best practice for this? Maybe if it's not a singleton class you might do it this way? Or maybe you should never do it this way? Hope to get some clarification, thanks.
Edit:
Incase there is any misunderstanding I'm just wondering if I should the first example with creating a property to store the instance vs this:
public function methodOne()
{
return User::getInstance()->foo();
}
public function methodTwo()
{
return User::getInstance()->foo2();
}
public function methodThree()
{
return User::getInstance()->foo3();
}
Actually now that I think about it this may be less code as I don't need the constructor...
There are indeed some problems with your approach.
It is not clear that your class depends on the User class. You can solve this with adding User as a constructor parameter.
Singletons are often bad practice. Your code demonstrates why: it is globally accessible and hence difficult to track dependencies using it (this points to the above problem).
Static methods are too often used as global access points (in response to what you see people usually do User::method()). Global access points give the same problem as singletons. They are also a tad more difficult to test.
I also don't see the point in repeating the User object with your new object, unless you would use eg the adapter pattern. Maybe if you could clarify this I would be able to come up with a better alternative than the generic:
class Foo {
public function __construct(User $user) {
$this->user = $user;
}
public function doXsimplified() {
$this->user->doXbutMoreComplex($arg1,$arg2, $arg20);
}
}
My personal preference in PHP is to use classes with just static methods for singletons, so you have
User::foo();
User::bar();
I would not create a new class just to wrap around a singleton like that. But if your new class adds some extra logic then your example makes sense. Remember, if you're worried that you're too verbose you can always use a temporary variable for successive function calls.
$user = User::getInstance();
$user->foo();
$user->bar();
But personally, I don't use Singletons anymore. Instead, I use Dependency Injection. I like the sfServiceContainer, but there are others. Have a look at this series of articles: http://fabien.potencier.org/article/11/what-is-dependency-injection
UPDATE
Based on the additional comments, this is how I would do it:
class UserWrapper
{
private $user = null;
public function __construct($user)
{
$this->user = $user;
}
public function foo()
{
return $this->user->foo();
}
...
}
Then use it like this:
$user = new UserWrapper(User::getInstance());
Why? So I can pass in a fake User object if I want to test the UserWrapper class. E.g:
class UserMock { ... } // A fake object that looks like a User
$userTest = new UserWrapper(new UserMock());
I usually go like this, if you have already included the class in a bootstrap of some sort or a config file. I would usually declear the $user variable in a bootstrap that will get called on every page load, then just reference it as a global variable on other php files, this is what I would have in the bootstrap file.
$user = new User();
Then this is what I would have in the calling php file
global $user;
$user->foo();
I have a session class that basicly just sets and retrieves session variables,
the reason I made it was so I could easily change it to use sessions or something
like memcache to set the items and have them accessible on multiple pages without hitting the database
I then have this user class which uses the session object to get session variables in it.
I am wanting to add to this user class though, to make it more encapsulated I would like to be able to set the variables that I am retrieving in this class
so right now I can display the userid with $user->userid; I would like to first have a method or something that sets its value from the session object I guess
Does this sound lke a good idea or possibly a lot of overhead?
And if what I am trying to do is a good idea maybe you could suggest/show example of how I should do it? I am thinking that if I add that method in that possibly I should move the code in the __construct method into it's own method
Basicly, I have the variables listed in the top part of the class that are used in the construct method, if I have multiple methods in the class though would I need to set them all at the top like that?
<?PHP
//user.class.php file
class User
{
public $userid;
public $name;
public $pic_url;
public $gender;
public $user_role;
public $location_lat;
public $location_long;
public $newuser;
function __construct()
{
global $session;
if($session->get('auto_id') != ''){
//set user vars on every page load
$this->userid = $session->get('auto_id'); //user id number
$this->name = $session->get('disp_name');
$this->pic_url = $session->get('pic_url');
$this->gender = $session->get('gender');
$this->user_role = $session->get('user_role');
$this->location_lat = $session->get('lat');
$this->location_long = $session->get('long');
$this->newuser = $session->get('newregister');
}else{
return false;
}
}
}
//with the class above I can easily show some user variables I have saved into a session like this below
$user = new user();
$user->userid;
?>
In general your idea is a good one
3 things I would do differently:
1) In your implementation doesn't seem to consider having several users. ie Several instances of the same class.
2) I would use factories instead of using IF in the constructor.
So for a user you have saved in the session you would call:
$savedUser = User::fromSession($userId);
for a new user
$user = new User()
3) Use the serialize and unserialze functions to save that data to the session
Then your class could could be implemented as
public static function fromSession($userId) {
return unserialize($session->get('users_'.$userId));
}
public function save() {
return $session->set('users_'.$this->id , serialize($this));
}
I guess this is vaguely an answer to the "is this a good idea" question. In my understanding, locating variables in the session versus refreshing them from the database is a question of the trade off between complex queries and deserializing data. The session data isn't a free magic cache that escapes database calls, it is just a convenient wrapper around a database call that you don't have to deal with. Any variable that you place in the session must be serializable. The whole collection of serialized data is then managed; the server fetches the data using the session key, deserializes it all, and hands it to the php script. Then when it closes the session for that request-response cycle it serializes it all and puts it back in the db.
So the mess in dealing with all that can, in some cases, be worse than the mess of just opening a connection and asking the db for the same stuff (or a subset of stuff) directly.
I would say that putting one or two key values in the session is a good stopping place, and relying on it too heavily for statefulness is a less-optimal plan.
I would set a new session with a name like "ValuesInSession" to true or false depending on whether or not you have session values for the fields in your user class. Then, in the sessions\users class you can check whether this session is true or false and set your values accordingly (IE from the existing sessions or to empty strings\0)
EDIT: You could, alternatively to putting that code in the user or sessions class, write a new class which could work with your users class to set the values properly (perhaps it could extend the sessions class?)
I'm not sure I understand the question, however, if you are using php 5, you can use the __set magic method to help with this.
Modifying your current class:
class User
{
private $id;
private $data = array();
public function __construct()
{
global $session;
$this->id = $session->get('auto_id');
$this->data = array(
'disp_name'=>$session->get('disp_name'),
'pic_url'=>$session->get('pic_url'),
'gender'=>$session->get('gender'),
'user_role'=>$session->get('user_role'),
'lat'=>$session->get('lat'),
'long'=>$session->get('long'),
'newregister'=>$session->get('newregister')
);
}
// return the user id
public function id()
{
return $this->id;
}
// the __get magic method is called when trying to retrieve a value of a
// property that has not been defined.
public function __get($name)
{
if(array_key_exists($name, $this->data))
{
return $this->data[$name];
}
return null;
}
// the __set magic method is called when trying to store a value in a property
// that has not been defined.
public function __set($name, $value)
{
global $session;
// check if the key exists in the 'data' array.
// if so, set the value in the array as well as the session
if(array_key_exists($name, $this->data))
{
$this->data[$name] = $value;
$session->set($name, $value);
}
}
}
This way you can still get and set values the same as you were, but will also store the set the value in your session class.
To test this:
$user = new User;
if($user->id())
{
echo $user->disp_name;
$user->disp_name = 'new name';
echo $session->get('disp_name');
}
I would not suggest you that because:
It is not a good practice to select an architecture "in case of future need" ('the reason I made it was so I could easily change'). Check http://www.startuplessonslearned.com (Eric Ries) or http://highscalability.com articles
Your code is hard/impossible to test (See Misko Hevery's blog (A google evangelist) http://misko.hevery.com for further information).
You are using "global" (never a good idea if you want to keep track of the dependencies).
It is better to seperate "the business logic" (a User class) and the wiring/building (a factory class for example). (See http://en.wikipedia.org/wiki/Single_responsibility_principle and "separation of concerns")
For really good code examples (and to understand which OO laws should not be broken), I can advice you Misko's blog (Also do not miss his technical talks at google that you can find on youtube). I am sure you will love them.
Hope this helps.