views:

201

answers:

2

Hi all,

I was just running one of my projects through NDepend and the report put my assembly right in the corner of the zone of pain. I was just wondering if it's something that I should be worried about.

What does the zone of pain really mean? Doesn't it mean that there is a lot of coupling and things can't change very easily.

I recently removed a lot of interfaces and sealed a lot of classes as I don't want the user extending the API(only in some places). It's a .NET Wrapper for a com object, so there isn't much need for the user to extend anything.

What are some good ways to get me out of the zone of pain?

Thanks

+3  A: 

I think Scott Hanselman had written a fairly lengthy post about NDepend and its zone implications

http://www.hanselman.com/blog/ExitingTheZoneOfPainStaticAnalysisWithNDepend.aspx

As he stated, and I agree, an assembly hovering in the zone of pain is not necessarily a bad thing. It is however, an indication of changes required on your part when the day of decision comes to use another component (COM or otherwise) to fulfill that same layer of functionality.

The question to ask is probably, "how likely are we going to swap out this layer for another framework/library?"

icelava
yeah I read that post, it's a good post. I just wan't to see what other peoples opinions where.
Nathan W
You shouldn't have to worry about components that provide permanent widespread blocks of functionality. Layers that may change in time, like a web service for a currency converter, may benefit from earlier abstraction to avoid the zone of pain later.
icelava
+8  A: 

The idea of Zone of Pain is to detect components that both: -Are concrete (i.e their users are binded with classes instead of interfaces) -Are popular (i.e they are used by a lot of other components).

Popular refers to the notion of stability. A component is stable if when changed, it breaks a lot of other components that are using it. In a word: Popular = Stable

Another idea is that interfaces are less subject to changes than classes. This is why it is commonly accepted that it is preferable to use an interface instead of a class, you have less chance to be 'statically' broken + you have less chance to be 'semantically' broken, since your code is not supposed to be bound with any implementations details (that are highly subject to changes).

As a consequence, being concrete + stable expose a component to some potential development pain: it is highly subject to changes + each changes will potentially break a lot of code.

In your case and some other cases, being in the Zone of Pain is not necessarily a bad thing. The important thing is to both be aware of this fact + if indeed your component provokes Pain, then roll back your code to interfaces.

Patrick Smacchia - NDepend dev
woot! the man himself has spoken!
icelava
In a Onion ( http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ ) or hexagon architecture ( http://c2.com/cgi/wiki?HexagonalArchitecture ), which seems to be a good idea to me, then surely the central domain model will always be highly concrete and highly popular? I.e. identified as a pain point, when I don't think that it really is one. I really don't think that a domain model should be hidden behind interfaces.
Anthony