+972 52-548-6969
Article Review: N Degrees of Separation
Following Frans Bouma's recommendation, I just read N Degrees of Separation: Multi-Dimensional Separation of Concerns.
I came away decidedly unimpressed.
First things first, the article is boring. And SoC is a subject that is near & dear to my heart.
More importantly, I don't like the way they are approaching the solution, even if I agree with their overall premise. The idea that they present is that we should have a way to split functionality not based on a single parameter, but on multiplies of them. To that I agree, most certainly.
Except that the example that they gave was about as real as a three dollar bill. They give an example of an AST and needing to add functionality to it later on. The problem is that this is more or less a solved problem. AST + Visitor == very easily extensibility. I can solve the problem they present by using additive changes only.
They seem to think that major modification to the code is required, although I am not sure why. I'll admit that perhaps it was a poorly chosen example.
What bothers me even more is that their chosen solution is... Partial classes.
Now, I had some small experience in building complex systems, which I need to be able to change at low cost. Here is how I would implement this "N Degrees of Separation":
- Kernel domain
- IValidator<TEntity>
- IPersister<TEntity>
- IVisitor<TEntity>
- IUponWhichTheAnglesDance<TPin>
I think you get the idea by now.
Add this to the IoC and you have solved the issue of feature changes. You just define an interface for a specific feature, add a rule to the IoC and you are done.
Comments
the paper's point is that the way you separate things is in general decided by 1 way of separation. For example, what about an algorithm which has 6 steps. You could write 6 classes, which represent each step. Then you throw them in a statemachine and you setup the state transition tables etc., and you have a running algorithm. You separated the concerns differently than you would have in other ways.
It's not the example given, it's the idea that there's no 1 way of separating concerns.
As I said,
I agree that SoC is important.
I think the example is flawed, the proposed solution bad, and I honestly doesn't see where you have N Degrees of SoC.
SoC means one concern per class/method, that is all.
If you have 5 concerns, you have five classes/methods.
It's a scientific paper, it's been peer-reviewed and cited, so I don't think the example is flawed at all. the point is that you should stop thinking in 'one concern per class/method', as that's not all the concerns you can have, just 1 and the paper also proves that you then in general have 1 which forces the absence of other forms, which you would probably classify as 'bad design' because it clashes with your '1 concern per class/method'.
As I said on the mailinglist: if your method has its own guardclauses, you already have 2 concerns in your method.
I believe this article is trying to solve the so-called "Expression Problem". An article which attempts to outline the issues with a pure visitor based approach is at http://www.removingalldoubt.com/PermaLink.aspx/861feae8-2404-4044-b661-aa13d432b08d
There is a considerable amount of research into solutions to this problem, that make it an O(1) modification to add both new operations and new AST elements. You may be interested in looking these up, but I don't know how relevant they are to real-world software development (most solutions require esoteric language extensions).
Frans,
Being peer reviewed and cited doesn't mean that I don't think it is flawed.
Having several concerns per feature is very common, and I split each of them to its own class, I fail to see anything interesting here. This is simply the standard approach
A lot of my method actually do not have guard clauses. Those usually sit on the external edge of the system.
But no, in those cases, I threat them as pre/post conditions, and as long as they are dead simple, I am happy with that.
Max,
Thanks, I'll take a look at this.
I think what Frans is trying to say is that what a particular "concern" is subjective. One class's "concern" may be another's "concerns". In his algorithm example, one person may see the entire 6-step process to be a single concern where another may see each step as it's own concern. So, in the first case you may use DI with Strategy and end up with two classes (one class that uses another, strategy, class) where another may use DI and Strategy and end up with 7 classes, one class that uses 6 strategy classes). But, rather the execution of the 6 steps being 1 concern, it ends up being n concerns because the same "concern" can have varying granularity depending on context.
I believe his point is the paper (I haven't read it) details that the granularity of a "concern" depends on context and his original point of simply saying "use SoC" is too vague to be a very useful comment.
Comment preview