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 ;)

  • 5
    "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
    Commented May 17, 2013 at 15:59
  • @pdr Totally agree... :)
    – Mik378
    Commented May 17, 2013 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
    Commented May 17, 2013 at 16:08

2 Answers 2


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.

Edited much later after learning more:

Back when I wrote this answer, I was thinking about SRP in terms of "a class should only have one responsibility" which has a lot to do with cohesion and coupling. This is good, but I have since learned more about what SRP really is.

The book Clean Architecture has a good description about SRP (and all of SOLID and more). Originally the definition was "a module should have one, and only one, reason to change." But Uncle Bob revised it to be "a module should be responsible to one, and only one, actor." So it's more about the use-cases of why a particular persona might want things to change.

To tie this back to the OP, classes that control behaviors for things like passwords, birthday, and pictures might all be responsible to different actors. Your security team cares about passwords and may cause you to change those behaviors separately from product managers who want to edit how birthdays are handled. So then, to follow SRP it would be wise to understand who those stakeholders are and create separations (e.g. separate classes) based on those stakeholders. Thus, you might have a UserCredential class for managing passwords instead of putting it in another class along with data that changes because of other stakeholders' reasons.

Following SRP keeps things simple in many of the same ways I mentioned originally, but it also makes things simple when you don't mix changes made for different reasons in the same class. So even with this revision, SRP and KISS can still live happily together.

  • 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
    Commented May 17, 2013 at 16:04
  • 3
    "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
    Commented May 17, 2013 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
    Commented May 17, 2013 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
    Commented May 17, 2013 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
    Commented May 17, 2013 at 16:37

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.

  • 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
    Commented May 17, 2013 at 15:59
  • 2
    @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. Commented May 17, 2013 at 16:02
  • Hoffra Ok Jimmy :) Understood :)
    – Mik378
    Commented May 17, 2013 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.