﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Peter Ritchie commented on Article Review: N Degrees of Separation</title><description>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.
</description><link>http://ayende.com/3096/article-review-n-degrees-of-separation#comment7</link><guid>http://ayende.com/3096/article-review-n-degrees-of-separation#comment7</guid><pubDate>Mon, 14 Jan 2008 16:30:52 GMT</pubDate></item><item><title>Ayende Rahien commented on Article Review: N Degrees of Separation</title><description>Max,
  
Thanks, I'll take a look at this.
</description><link>http://ayende.com/3096/article-review-n-degrees-of-separation#comment6</link><guid>http://ayende.com/3096/article-review-n-degrees-of-separation#comment6</guid><pubDate>Sun, 13 Jan 2008 11:45:49 GMT</pubDate></item><item><title>Ayende Rahien commented on Article Review: N Degrees of Separation</title><description>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.
  
</description><link>http://ayende.com/3096/article-review-n-degrees-of-separation#comment5</link><guid>http://ayende.com/3096/article-review-n-degrees-of-separation#comment5</guid><pubDate>Sun, 13 Jan 2008 11:45:34 GMT</pubDate></item><item><title>Max commented on Article Review: N Degrees of Separation</title><description>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).
</description><link>http://ayende.com/3096/article-review-n-degrees-of-separation#comment4</link><guid>http://ayende.com/3096/article-review-n-degrees-of-separation#comment4</guid><pubDate>Sun, 13 Jan 2008 11:18:31 GMT</pubDate></item><item><title>Frans Bouma commented on Article Review: N Degrees of Separation</title><description>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.
</description><link>http://ayende.com/3096/article-review-n-degrees-of-separation#comment3</link><guid>http://ayende.com/3096/article-review-n-degrees-of-separation#comment3</guid><pubDate>Sun, 13 Jan 2008 10:33:42 GMT</pubDate></item><item><title>Ayende Rahien commented on Article Review: N Degrees of Separation</title><description>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.
</description><link>http://ayende.com/3096/article-review-n-degrees-of-separation#comment2</link><guid>http://ayende.com/3096/article-review-n-degrees-of-separation#comment2</guid><pubDate>Sat, 12 Jan 2008 21:10:57 GMT</pubDate></item><item><title>Frans Bouma commented on Article Review: N Degrees of Separation</title><description>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. 
</description><link>http://ayende.com/3096/article-review-n-degrees-of-separation#comment1</link><guid>http://ayende.com/3096/article-review-n-degrees-of-separation#comment1</guid><pubDate>Sat, 12 Jan 2008 21:04:25 GMT</pubDate></item></channel></rss>