The term "separation of concerns" is something I've been thinking a lot about lately as it relates to programming. I was reminded of how important it is when I had to troubleshoot an method with over 300 lines of code that performed about 8-10 tasks. This would have been so much better if it were modularized into 8-10 methods, thus separating each concern (or task); this means I probably would have only had to deal maybe 15-20 lines of code. As it was, I ended up breaking up into about 4 methods, just so I could get my head around it.
As the Wikipedia definition in suggests in the link above, as well in this post, separation of concerns can also apply to your life. Instead of dealing with life's challenges all at once, it's always good to separate them by your roles or goals. Whether it's programming or life, doing this helps to ensure that a failure in one area doesn't lead to the entire thing failing. For example, if you're not very productive at work because you have personal problems, you have done a poor job at separating your concerns. If you're playing poor defense because you can't make a shot offensively, same thing. The inability to perform one task should not prevent the other pieces of an application from working. Right?
What I'm wondering is if you can ever have too much separation of concerns. Or maybe a better question is if there's ever a point where further separation won't hurt, but is also pointless. I have four children; if one of them has a problem with lying, it would not be fair to assume that all of them lie. That's a good separation, right. But what concerns do I draw from the one child being a liar? In fact, a parent would probably ask the child in anger, "Why did you lie to me?" And what's the answer we always get .... "I dunno." It makes us more angry; but sooner or later we realize that he/she is probably right. It doesn't matter why, we just need to find a way to make sure they think twice before he/she does it again.
I could have spent the time breaking that 300 lines of code into 8-10 methods (maybe even more.) But I think we need to ask ourselves the reason for doing so; and if the only reason is for the sake of separating concerns, I don't think that's a good enough. Sometimes, perhaps we should ask if there's a good reason to keep lines of code together; if you can think of one, it's time to re-factor it. I think separating with purpose is a much more responsible approach than blinding separating every chance we get. However, what is even more irresponsible is not to separate them at all.