Exiting the Zone of Pain - NDepend

Question

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

Answer 1

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?"

Answer 2

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.