Separation of Concerns

[haacked]

The book goes off on a discussion that states that the definition of the idea of separation of concerns isn't well understood.

I think the definition is actually fairly well understood as it applies to how parts of a system are coupled together or not. I think the many arguments that surround separation of concerns isn't about the definition, but about the value of doing it in certain places.

For example, when folks want to break some code into multiple files citing "separation of concerns," a lot of arguments may ensue. Sometimes folks will say "that's not separation of concerns." I think that's arguing the wrong thing. Yes, it is a separation of concerns, but it's perhaps separating concerns that really don't matter much. These may be low value concerns. You have to balance the cost of separating concerns with the value the separation provides.

Separation into files is often low value when compared to separating UI concerns with database concerns, which tend to be higher value.

[robconery]

I think the term has been watered down, co-opted and abused, to be honest. If we agree that Djikstra is the one who coined the term, then maybe you can understand what it is that I was driving for.

First, a snippet (emphasis mine):

Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects

... It is what I sometimes have called “the separation of concerns”, which, even if not perfectly possible, is yet the only available technique for the effective ordering of one’s thoughts, that I know of.

It seems rather clear to me, in this remark, that Djikstra is referring to the thing your code represents, more than the structure of the code itself. I could be wrong, of course, and this could simply be me appealing to authority. It is his quote/term, however.

I do understand that people can apply the notion of SOC wherever they like. Thinking about the UI vs. database (to use your example) could be lumped in there, as could "coffee vs. tea" if I wanted. Thus my quip:

The term “Separation of Concerns” honestly doesn’t mean anything anymore.

Reading over your post above, I think you're sort of making my point. You start off with suggesting that it applies to coupling, then move over to file separation (which has nothing to do with coupling) and finally to UI/database, which has nothing to do with coupling or file separation.

[haacked]

I think you're sort of making my point. You start off with suggesting that it applies to coupling, then move over to file separation (which has nothing to do with coupling) and finally to UI/database, which has nothing to do with coupling or file separation.

I'm making the point that these could be considered "degrees" of separation of concerns. They all to some degree meet Djikstra's definition, some more than others. Also, the value in implementing some separation of concerns are much more than others.

You start off with suggesting that it applies to coupling

This doesn't invalidate my point. Going back to Djikstra's definition:

study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects

The ability to study one aspect of a subject matter in isolation is made possible by loose coupling. If that aspect is highly coupled to another aspect, then you can't easily study it in isolation. That's why the concept of coupling is intrinsically tied to separation of concerns. And this is why I believe SOC still has meaning, even if others try to water it down.

I do understand that people can apply the notion of SOC wherever they like.

Sure, people can do anything. But I don't think this is as widespread as you make it out to be. A lot of people misunderstand monads and functional programming, but "monads" and "functional programming" still mean something.

[robconery]

We could argue about Djikstra all day I suppose :) but I will sidestep that and say that, for the most part, I do agree with you.

Let's come back to the issue as raised (which I don't agree with):

The book goes off on a discussion that states that the definition of the idea of separation of concerns isn't well understood... I think the definition is actually fairly well understood as it applies to how parts of a system are coupled together or not.

I disagree with your assertion that it's fairly well understood. As I mention in the book, Rails pushes SOC as part of its platform offering, which is sort of silly as models are sprinkled throughout controllers and views. SQL and data access, library projects vs. files etc. I don't think any of these fit what you and I have been talking about, and I think this kind of thinking is rampant. In fact, I think people throw SOC around as justification for organizing things in arbitrary ways, regardless of coupling/cohesion.

Here's an assertion I read on StackOverflow regarding Angular and the DOM:

In jQuery, the DOM is kind of like the model. But in AngularJS, we have a separate model layer that we can manage in any way we want, completely independently from the view. This helps for the above data binding, maintains separation of concerns, and introduces far greater testability.

In fact, read through this search and I think you'll see what I mean. If you're really bored, read this answer and maybe chime in :).

A final thing: I know that a lot of this is subjective given that we're talking about how people use the term vs. what Djikstra originally meant by it. This is exactly why it's under the heading Some Opinion :).

[haacked]

I disagree with your assertion that it's fairly well understood.

Ok, you've convinced me that it's not fairly well understood by a lot of people. I meant that I think there are plenty of people who do understand it. We can quibble over "fairly" but let's save that.

What I really meant to object to is this:

The term “Separation of Concerns” honestly doesn’t mean anything anymore.

I'd suggest that despite it not being understood by a lot of people, it still mean something. After all, you pointed to the Djikstra definition which has a clear meaning. I think it's important not to conflate the fact that it has meaning with the fact that a lot of people are confused by that meaning.

Here's one way to clarify that distinction that I believe speaks to your point and mine...

The term "Separation of Concerns" has become muddied over the years. It's original intent is to describe an approach to systems design that reduces coupling and increases cohesion. However, many people and frameworks tend to bandy the term as a justification to organize things in arbitrary ways. This leads to a lot of confusion over what separation of concerns actually means. When you read someone state that their approach "maintains separation of concerns" always ask yourself "what concerns are separated?" If the answer is unclear or seems unimportant, then perhaps the author is unclear about the definition. This approach will help you separate the hogwash from the real stuff. And it's a good question to ask yourself when designing your own software. What concerns should be separated? What's the value of that separation? Is the value worth more than the cost inherent in maintaining the separation? Despite all the muddied confusion over SOC, it's still a valuable concept to apply to software.

[robconery]

I've been thinking about this (almost) non-stop for the last few hours and I think I might have something we can both grasp on this.

Separation of Concerns is a Programming-focused Getting Things Done

One of the premises of GTD is "mind like water", where you lob "well-formed tasks" into an inbox and then organize them, allowing complete focus later on. It's the "complete focus" part that I think Djikstra was hitting on. Your ability to fully isolate an aspect of your application so that you can focus on it, 100%. This could be a business concern or maybe a system concern like efficiency (to use Djikstra's example).

To me, this is a bit more abstract than a principle of programming - yet it bleeds into everything you do as a programmer. If this is your focus then you're naturally led down the path of focusing on coupling/cohesion etc.

Thoughts?