Dijkstra’s Separation of Concerns – Intent for Code Modularization

designdijkstramodularizationseparation-of-concernssource code

First, I read an excerpt Edsger W. Dijkstra's 1974 paper "On the role of scientific thought":

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. We know that a program must be
correct and we can study it from that viewpoint only; we also know
that it should be efficient and we can study its efficiency on another
day, so to speak. In another mood we may ask ourselves whether, and if
so: why, the program is desirable. But nothing is gained —on the
contrary!— by tackling these various aspects simultaneously. It is
what I sometimes have called "the separation of concerns", which, even
if not perfectly possible, is yet the only available technique for
effective ordering of one's thoughts, that I know of. This is what I
mean by "focusing one's attention upon some aspect": it does not mean
ignoring the other aspects, it is just doing justice to the fact that
from this aspect's point of view, the other is irrelevant. It is being
one- and multiple-track minded simultaneously.

I see modern separation of concerns talk about modularizing your code. However, reading the quote above, I understand this as focusing your mind onto one particular task at a time, while not focusing on other aspects. This does not mean to me necessarily that code needs to be separated into modular chunks.

That is, say there is a code in front of you that in one file has the concepts of view, repository, controller, event handling, factory, etc. all in one file.

For a brief example, here's some code that has data access, and view (output):

$sql = "SELECT * FROM product WHERE id = " . db_input($id);
$row = db_fetch_array(db_query($sql)); 
<option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? '  selected="selected"' : '' ?>>Version <?=$row['ver']?></option>

Using modern OO I could place data access in its own file using Repository pattern, the View code can go into its own file template, and I can wire those up together to communicate via a controller (or Action or Request Handler), and I can add a factory to create and wire up various dependencies. And I can have a configuration file that defines those factories. Surely it's a step away from single-file-everything.

My question on separation of concerns is like so: reading Dijkstra's quote, I got an idea that perhaps he did not necessarily mean for separation of concerns to be "modular separation of code (into files or their own functions/methods/etc)", and that he meant more so to focus one's mind upon an aspect of the program, without burdening yourself focusing on other important yet not-currently-to-be-considered aspects, regardless of whether they are physically separated in code, or not.

Why then are we burdening ourselves with physical modular code separation and design patterns? Will it be not enough to just focus oneself onto an aspect, regardless of how your code is structured?

I am not talking about writing up the most horrible spaghetti code and then only considering an aspect of it, that would likely be a burden.
But in the end, what I am going towards, is, why perform the physical code separation, why split the code up into separated files or chunks (methods), when it is not necessary for mentally focusing yourself on an aspect?

Should separation of concerns remain a mental exercise, rather than physical?
In other words, should there be a disconnect between the mental (focus on) and the physical (code on paper) aspects of programming?

Best Answer

Dijkstra is making an explicit statement about how to think. Program (and process) modularization - and it's desirability - is perhaps a result of that thinking, but the key point he is making is how to assess a problem. The program is typically the solution to a problem, and by advocating a "separation of concerns", he is offering wise advice. The best example of this is perhaps "optimization". The joke was: "When planning to optimize a program, your first strategy should be: Don't." In other words, you want to focus on first making the program correct. Making it fast and fancy is a concern that should be separated - but also not completely removed either.

Related Topic