On Nov 30, 2:50 am, Lev Danielyan <[EMAIL PROTECTED]> wrote: > But, coming back to ndepend, it claims the list is for "direct" > dependencies. > But, I don't think going up the inheritance tree makes sense in terms > of coupling. > After all, we need direct dependencies, and if, for example my type > inherits AccessViolationException, > I actually shouldn't care about anything higher in the tree than > AccessViolationException. > > What do you think?
Hmm. I have to think about it. Let's analyze what makes sense to regard as a direct dependency. I can think of two approaches: 1. "Logical" - Class C is directly dependent on class D if the programmer must know about it to fully use the class. 2. "Physical" - Class C is directly dependent on class D if the runtime must know about it to load the class and its methods. In both cases, I think *all* base types must be included, since both programmer and runtime must know what (public) fields and methods are inherited. Programmer needs to know the attributes from base types since they can be inherited. It's not so clear that the runtime needs it per se, but any code which reflects classes to find attributes will need them. (Are any inheritable attributes required by the runtime?) Given these approaches, in your example, System.Random must be regarded as a physical dependency (the runtime must have a reference to that class to create the body of test()), but it is not a logical dependency since it appears only in a method body, not in any signature. Therefore, my take is that NDepend finds physical dependencies. --~--~---------~--~----~------------~-------~--~----~ -- mono-cecil -~----------~----~----~----~------~----~------~--~---
