A community in which webmasters can ask for help with topics such as PHP coding , MySQL , IT jobs, web design, IT security.
Current location:homephp forumphp talk in 2009 yearWhat is a better design? - page 1
User InfoPosts
What is a better design?#1
I have the following class:

class User {

public function setName($value) { ... }
public function setEmailAddress($value) { ... }
public function setUsername($value) { ... }
public function getName() { ... }
public function getEmailAddress() { ... }
public function getUsername() { ... }

public function isGroupAdministrator($groupId) { ... }
public function isMemberOfGroup($groupId) { ... }
public function isSiteAdministrator() { ... }
public function isRoot() { ... }
public function hasModulePermission($moduleId, $recordId, $permissionCode) { ... }
public function hasGroupPermission($groupId, $permissionCode) { ... }
public function hasContentPermission($recordId, $permissionCode) { ... }
public function hasModulePermission($moduleId, $recordId, $permissionCode) { ... }
public function canLogIn() { ... }
public function isLoggedIn() { ... }
public function setCanLogIn($canLogIn) { ... }


Is this becoming a "God Class?"

I am unsure whether I should split this class up. The problem in doing so is that this class(s methods are used by its domain to determine whether to show given UI elements on web pages, so there is not any behavior in the class.

I suppose I could put the permission-related methods in some Permission class, making those methods static (eg. ::userIsGroupAdministrator(...), ::userIsMemberOfGroup(...) ::userHasGroupPermission(...), ::userHasContentPermission(...))

Any suggestions on how this class could be better?

posted date: 2009-04-08 08:47:00

Re: What is a better design?#2
I had made out the solution of this problem. click to view my topic...

hope that hepls.

posted date: 2009-04-08 08:47:01

Re: What is a better design?#3
Its hard to tell from method names alone. One heuristic I use to break a class up is to look at the state variables. Are there pieces of state that tend to be used together? Can they be broken out into a separate class?

posted date: 2009-04-08 08:50:00

Re: What is a better design?#4
I would consider creating a Permissions class and making that a member of the User class.

posted date: 2009-04-08 08:51:00

Re: What is a better design?#5
You seem to need separate ACL and Role objects from the User object.http://en.wikipedia.org/wiki/Role-based_access_controlYou can also see how it(s done in ZF. For readability you might consider using __get() and __set() instead of: public function setName($value) { ... } public function setEmailAddress($value) { ... } public function setUsername($value) { ... } public function getName() { ... } public function getEmailAddress() { ... } public function getUsername() { ... }

posted date: 2009-04-08 08:52:00

Re: What is a better design?#6
As long as the methods on the class return instance data or only modify internal state, there is nothing wrong with the class.But, for e.g. if canLogIn() method looks for some external service (repository, membership service etc.), there is a problem of simplicity and testability. If this is the case, you must have some service class and have those methods on it. Likenew SomeFactory().GetUserService().canLogIn(user);

posted date: 2009-04-08 08:53:00

Re: What is a better design?#7
Delegation and information-hiding. I like it.

posted date: 2009-04-08 08:56:00

Re: What is a better design?#8
The reason I have this method is because I store a boolean flag for whether the user can log in.

posted date: 2009-04-08 08:57:00

Re: What is a better design?#9
I suggest tagging as 'php' or 'language-agnostic' to improve visibility.

posted date: 2009-04-08 09:08:00

Re: What is a better design?#10
If you already have running code, then refactor in small pieces. If not I would look at the following:class User { String username String name String emailAddress Boolean active Integer permission # A bitmask of the statics in the Permission class}class Group { String name}class UserGroupMapping { User user Group group Boolean administrator}class Permission { static IS_ROOT = 1 static IS_SITE_ADMIN = 2}class Session { User user Boolean logged_in}The rest of this really belongs in a service class:class SecurityService { static public function hasModulePermission($user, $module, $record, $permission) { ... } static public function hasGroupPermission($user, $group, $permission) { ... } static public function hasContentPermission($user, $record, $permission) { ... } static public function hasModulePermission($user, $module, $record, $permission) { ... }}

posted date: 2009-04-08 09:10:00

Re: What is a better design?#11
How difficult is it now to add new functionality or maintain existing functionality in your application? If you(re not having problems in that respect, then you(re probably OK keeping things as they are (at least for awhile).Yes, your User class has some overlapping responsibilities that could potentially be refactored into a Role-based access control system.The bottom line is: are you really gonna need it?

posted date: 2009-04-08 09:14:00

Re: What is a better design?#12
It(s not too bad, but I think your permissions mechanics could use factoring. That(s a case that clearly calls for aggregation, not inheritance, as well. If there(s a chance of non-trivial contact information being associated with the user, you might want to factor out email address as well, maybe into an Identity that can have other contact info loaded on if needed.In general, I could recommend thinking of your User as a central point for aggregating and composing (not inheriting) subunits of functionality -- an approach that(s achieving buzzword status in game development under the rubric of (entity system(.

posted date: 2009-04-08 09:16:00

select page: « 1 2 »
Copyright ©2008-2017 www.momige.com, all rights reserved.