How to name my classes? [closed] - php

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a base user class which is responsible for manipulating the basic user information: name, age, location, etc. I want to extend my system with the groups functionality and later with projects and meetings. For example:
class User
{
public function getName() {
...
}
public function getAge() {
...
}
}
And then extend it with groups functionality:
class GroupableUser extends User
{
public function join($groupId) {
...
}
public function leave($groupId) {
}
public function requestGroupInvitation($groupId) {
...
}
public function acceptGroupInvitation($groupId) {
...
}
}
The name GroupableUser seems weird to me, however it does't make sense to add join and leave methods to Group class, because its user that joins and leaves a group, not the other way around.
And later I would have classes like UserThatCanHaveProjects and UserThatCanParticipateInMeetings.
How to name these classes?
And how do you typically deal with these situations?

Answer 1

You can't seem to be able to find a way to name the classes because the hierarchy is not very natural. In reality a user may participate in more than one group and each group may have more than one user. But a user may exist without a group, while there can't be a group without a user. I would say this means users should be a member of a group and addUser and removeUser should be placed in Group. Why? Because a user may not even "know" that he may join or leave a group and be perfectly happy, while there can not be a group that does not "know" that a user may join it.

Answer 2

The capability to participate in groups/meetings and have projects is something that a user might be able to do, but it's not something that defines what a user is. This is a pretty clear sign that modelling these options with additional classes is not a good design choice.
Static approach #1: interfaces
In a statically typed language a simplistic implementation would look something like
interface IGrouppableUser {
public function join(...);
}
class GroupableUser implements IGrouppableUser {
public function join(...) { /* implementation */ }
}
And the consumers of grouppable users would accept IGrouppableUser, allowing you to craft as many classes as necessary. You can also do this in PHP, but as mentioned earlier it's probably not a good design no matter what the language.
As a footnote, I should add that with the addition of traits to the language starting from PHP 5.4 the above scenario can be implemented a bit more conveniently (classes can use a trait instead of implementing an interface, which means you don't need to copy/paste the implementation of join all around the code base). But conceptually it's the exact same approach.
The main disadvantage of this approach is that it does not scale. It might be OK if you only need two or three types of users.
Static approach #2: "not supported" exceptions
If most of the users are grouppable and can have projects then it doesn't make much sense to create a hellish hierarchy of classes; you can just add the necessary members to class User, making it a fat interface:
class GroupableUser implements IGrouppableUser {
private $isGrouppable = true; // default, can be changed at runtime
public function join(...) {
if (!$this->isGrouppable) throw new Exception("User is not grouppable!");
// real implementation
}
}
The main disadvantage of this approach is that it makes the class User appear to unconditionally support a wide range of operations when in fact it does not and as a result can make coding tedious and error-prone (lots of try/catch). It might be OK if the vast majority of users support the vast majority of operations.
Dynamic approach #1: behaviors
It would be much better to conditionally allow User instances to participate in these operations. This means that you need to be able to dynamically attach "behaviors" to User objects, which is fortunately quite easy to do in a dynamically typed language.
I suggest looking up a "behaviors" implementation from an established open-source project, but here's a quick and dirty example:
Behavior base class and sample implementation
abstract class Behavior {
public function provides($name) {
return method_exists($this, $name);
}
public function invoke($target, $name, $arguments) {
array_unshift($arguments, $target);
return call_user_func_array(array($this, $name), $arguments);
}
}
class GrouppableBehavior extends Behavior {
public function join(User $user, $groupName) {
echo "The user has joined group $groupName.";
}
}
Composable (can use behaviors) base class and User implementation
class Composable {
private $behaviors = array();
public function __call($name, $arguments) {
foreach ($this->behaviors as $behavior) {
if ($behavior->provides($name)) {
return $behavior->invoke($this, $name, $arguments);
}
}
throw new Exception("No method $name and no behavior that implements it");
}
public function attach($behavior) {
$this->behaviors[] = $behavior;
}
}
class User extends Composable {}
Test driver
$user1 = new User;
$user2 = new User;
$user1->attach(new GrouppableBehavior);
$user1->join('Test Group'); // works
$user2->join('Test Group'); // throws
See it in action.
The main disadvantages of this approach are that it consumes more runtime resources and that behaviors can only access public members of the classes they are attaching to. In some cases you may find yourself forced to expose an implementation detail that should be private to enable a behavior to work.
Dynamic approach #2: decorators
A variation on behaviors is the decorator pattern:
interface IUser {}
interface IGrouppableUser extends IUser {
public function join(...);
}
class User implements IUser {}
class UserGroupingDecorator implements IGrouppableUser {
private $realUser;
public function __construct(IUser $realUser) {
$this->realUser = $realUser;
}
public function join(...) { /* implementation */ }
/* now you need to implement all IUser methods
and forward the calls to $this->realUser */
/* if IUser exposes bare properties we have a problem! */
}
Using this pattern you can create a UserGroupingDecorator that wraps an IUser at will and pass the decorator to anything that accepts either an IUser or an IGrouppableUser.
The main disadvantage of this approach is that it also does not provide access to the non-public members of User. In addition it rules out exposing bare properties from IUser as there is no way to "forward" bare property accesses from UserGroupingDecorator to $realUser if the properties are also defined on the former -- and you cannot implement IGrouppableUser unless they are indeed defined. This state of affairs can be sidestepped by exposing properties as distinct getter/setter methods, but that means still more code to write.

Answer 3

Thinking in terms of a database-driven web app, I might do this with 5 classes:
1) User
2) Group
3) GroupAssignment
4) GroupInvitation
5) GroupInvitationRequest
Class 3 just maps one User to one Group. Classes 4 and 5 are even more obvious. This setup pretty much matches what you would have in a database anyway. This allows for a good amount of flexibility, as a User could be a member of many groups (or one, or none).
EDIT: Added additional classes based on new information in question.

Answer 4

Groupable would be a good name for interface, Interface should describe an aspect of class, that might be required by instance of some different class. Interfaces are contract between classes.
Just don't stick the "I" in front of it, unless you use hungarian notation for everything. Simply use nouns for class names and adjectives for interfaces.
As for the name of class, I would go with:
class Participant extends User implements Groupable
{
// methods that will be expected by from instance of this class
// by any class that requires an object to have Groupable interfrace
}