Is the following an acceptable breach of the 'Nested types should not be visible' (Microsoft .NET code analysis CA1034) rule?

I have a have a class, let's call it 'TandAOLL', this is tree and an array of linked lists all in one, this is a QuadTree implementation which allows for grouping of points.

Inside this class I have another class, let's call this one 'TandAOLLGroup', this is the type that the iterator of 'TandAOLL' returns, this is therefore declared Public.

This class contains a reference to the tree from which it was created and also an integer representing the index of the group the object represents.

The iterator of 'TandAOLLGroup' returns Points by following a linked list trail using the leaf stored in the TandAOLL.Array(Index) as the head.

The reason I have nested the second class inside the first is because it needs priviliged access to the private members of the 'TLLOLL' class.

  • 2
    "The reason I have nested the second class inside the first is because it needs priviliged access to the private members of the 'TLLOLL' class." There's your problem right there. You have created such tight coupling between the clases, one even has to live inside the other to gain access to private members. Fix this coupling, move the class out and your problem will be solved. – David Arno Oct 14 '15 at 18:48
  • @David The issue I see here is that to decouple the classes the data will have to be passed (duplicated) to the Group object. However the Trees can contain in the region of 20 million points so finding and duplicating the right bits of data seems like a waste especially of memory. – o.comp Oct 14 '15 at 18:56
  • What's stopping you implementing internal methods that expose the data to the "group object"? – David Arno Oct 14 '15 at 19:07
  • @David Nothing, I just wanted a trustworthy opinion on which way to go. Could you write this as an answer so I can accept it? Thanks – o.comp Oct 14 '15 at 19:18

You can use a public interface (e.g. ITandAOLLGroup) which the iterator can return. The implementation TandAOLLGroup can remain a private nested class or whatever the is the best option for your design.

  • Now all you need to do is fix the circular reference issue which is a bigger problem than your original. – Dunk Oct 15 '15 at 14:22
  • @Dunk Could you elaborate? I'm not sure I follow. Thanks. – o.comp Oct 15 '15 at 16:29
  • 1
    From the description it seems like TandAOLLGroup has a dependency on TandAOLL. Likewise, TandAOLL has a dependency on TandAOLLGroup. IOW, a circular reference. Circular references are really bad because a change in either class can break everything that depends on the other class in addition to what depends on the class that changed. There's always a better way than to do circular references. – Dunk Oct 15 '15 at 17:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.