Take the 2-minute tour ×

Let's assume the modeling of User model in a context of a social network.

User concept is composed of two notions:

  • Authentication elements like userName/Password/Email etc...
  • Extra data information sometimes called "User profile" like firstName, birthday, pictures etc..

At first glance, this analysis involves separation of tasks/responsibilities if we want to keep SRP.

However, typically in the case of a social network, userName may be seen as a pure information belonging to a user's profile rather than a pure element of authentication.

Thus, there is three ways, according to me, to model the User concept.

First, the whole in one class:
User (userName, password, email, firstName, birthday, picture etc...)

Second, a one-to-one relationship between User and UserProfile:
User(userName, password, email) UserProfile(firstName, birthday, picture etc...)

Third, a one-to-one but with a redundancy of the common fields (being as focused on authentication as a visible user information on the website):
User(userName, password, email)
UserProfile(userName, firstName, birthday, picture etc...)

Why repetition here? Of course for consitency and at the same time to avoid joins in cases of relational database when one want to retrieve each Use's profile data.

What is a good practice to model these both concepts? Where should I place userName field?

Dilemma being: keeping KISS (Keep it simple stupid!) or SRP ;)

share|improve this question
"to avoid joins" -- Why on earth would that be a worthy goal? This question has nothing to do with SRP, by the way. Each option gives the object(s) one responsibility: holding data. To take your example to the extreme would be to suggest that SRP requires an object for each field. –  pdr May 17 '13 at 15:59
@pdr Totally agree... :) –  Mik378 May 17 '13 at 16:07
@pdr My real question was about the good place of the userName field, that's the only thing I still wonder (see my comment just below) on @Allan post. –  Mik378 May 17 '13 at 16:08
add comment

2 Answers

up vote 4 down vote accepted

IMO this is a false dichotomy. If you follow SRP, you keep your system simple overall. Multiple small classes tend to be more "simple" (in many cases) rather than fewer large classes. Plus it seems like you are conflating two issues: how you design your classes vs. how you design your database. The two do not need to be related.

In your given case, it sounds like you probably have 3 classes: User (username, password, email), UserProfile (name, birthday, etc.), and UserPictures (the pictures, because why would they be part of the "profile"?). Then you can create your User class to include (via composition) the other two.

Of course, this is just a rough attempt at design without any broader overall picture of requirements. There are plenty of different valid, simple, and SRP ways to do break down your classes based on the actual need. The main point is just that KISS and SRP aren't inherently at odds.

share|improve this answer
Understood. I was thinking also about the three classes. But, what if later, I implement a second type of authentication, like for instance, Facebook with OAuth authentication. UserName being at first associated to User class (renaming to BasicUser to make the difference) would be unreachable from the composition: FacebookUser -> UserProfile. Should userNamebe part of UserProfile directly? which would lead to a BasicUserclass with only one field: password and maybe other types dealing with the user/password mechanism. –  Mik378 May 17 '13 at 16:04
"What if later" makes me think YAGNI. If you know that this is a likely upcoming feature, go ahead and account for it now in your design. But you should always be wary of overdesigning up front. It's usually better to keep your design simple up-front, then refactor once you understand what is needed later. "What if later" being deferred until you know it's going to be used. –  Allan May 17 '13 at 16:14
@Mik378: I think you're missing the obvious solution of having an identifier that isn't the username. Profile isn't a part of the user, but it is necessary to associate it with the User. So have an int identifier that the user never sees, but which links the profile back to the user. Usernames exist only to give your User a memorable identifier, rather than 1736533, thus they exist in User. –  pdr May 17 '13 at 16:21
@pdr That's what I already have: an UUID generated by my application that identify uniquely my Userand a second for its UserProfile. However, the fact is that userName serves especially for Chat service (messenger) for instance, to allow users to identify themselves. If you place it on User, you confirm that it deals only with Authentication, whereas actually, it's a pure public information visible by other members of website. –  Mik378 May 17 '13 at 16:27
@Mik378: Well, honestly, I think it's a mistake not to separate the login username from the visible username. They're two very different things and not allowing the user to separate them is a bit poor (I've had that situation and it's stopped my posting on a message board, because I'd rather not be identified if I do). Now we're not talking about replication, we're talking about separation. Copy the username to the default profile and let the user control it. –  pdr May 17 '13 at 16:37
show 1 more comment

You're confusing KISS; simple isn't referring to simple to implement for the developer, it refers to simple design, simple to understand and use. Following SRP makes your code simpler to understand and use because it's simpler to use a purpose built class for a single purpose than a multipurpose class, it's also simpler to maintain.

SRP supports Simplicity, even if it's more work for the developer to implement, the result is a simpler system.

share|improve this answer
Yes I agree with you, the word "simple" may be abused. But I still believe that for some people, breaking in two classes would be considered as a "useless effort" for a tiny case like this. –  Mik378 May 17 '13 at 15:59
@Mik378 This is a very narrow case you're referring to, so either choice is really not going to be a huge deal; as such I chose to answer the general question you asked about SRP vs KISS. That said; a multipurpose class does have a tendancy of growth in a bad way over time.. what seems trivial now may not down the road; SRP may be extra work up front but it keeps you honest down the road a lot of time. Though in this case again, it's so narrow I can't tell you which choice is better. –  Jimmy Hoffa May 17 '13 at 16:02
Hoffra Ok Jimmy :) Understood :) –  Mik378 May 17 '13 at 16:06
add comment

Your Answer


