Question

I’m making a simple PHP application with Twitter/Facebook integration to practice OOP concepts and patterns, and I need help with how it should be designed.

What my app will do

Basically, once the user logs in, he’s show a form with title and body field. When he clicks on “Post”, this content will be appropriately transformed and posted to Facebook and Twitter. Of course, he’ll also get an option to authenticate my FB/Twitter app if he hasn’t already done so. That’s what I’m trying to achieve.

The structure I’ve come up with till now

Since database access will have to be shared amongst multiple files, I’m using a Singleton pattern. Essentially, I have a DB class with a static mysqli link and a static method to get this database link. The models will use mysqli functions with this single link. (I don’t want to abstract the database type just yet.)

I have a User class which holds a user’s data, like it’s id, username and hashed password. It has methods to retrieve user based on id, credentials and even save the current user to the db.

An Auth class manages session and returns a User object for a valid user. So, it manages logging in, and keeping the user logged in between page visits.

The structure I’m having problem with

I now need access to the Twitter and Facebook information of the user. Of course, they’ll be in separate tables, and have separate classes to interact with them. But each of this class is associated with a User.

So, when I’m fetching user information from the database, I’ll also use JOINs to fetch corresponding data from the Twitter and Facebook table. Then, my plan is to have a Twitter and Facebook object instantiated within my User object. So, these two classes can be accessed as say $user->twitter->post(“Something”);.

Is this a good structure, or is there a better way to organize classes? This is a simple app, and coding is not my concern. My concern is the structure, since I should be able to add new social networks to the application.

Answer 1

It is preferable to keep persistence functions out of domain objects. Instead of having the User class load and save itself, I would have a UserRepository interface, for example:

interface UserRepository {
  public function findUser($username);
  public function save(User $user);
}

and a MysqlUserRepository class that implements this interface. That way you keep database-specific code out of the User class.

Similarly, I would pull social networking functions into their own interface, say:

interface SocialNetworkService {
  public function post($status);
}

and separate implementations for FacebookService and TwitterService. This allows you to add support for new social networks without having to modify the User class.

These services can then simply wrap around a user object and provide their services for that user:

$fb = new FacebookService($user);
$fb->post("blah");

A common principle behind all of these decisions is the single responsibility principle: your User class should have only one reason to change, and that is when you need to change the model of a user. Any other changes, such as dealing with databases or social networks, shouldn’t affect the User class.