Tuesday, October 12, 2010

C# Curiously Nested Production Class

We tackled some code for refactoring, and I found an unusual construct. To wit:

public class Base: Many, Varied, Bases {
    private int x;
    
    // ...

    public class Derived: Base {
        public setX(int value) { 
            x = value;
        }
    }

    // ...
}

So here we have the derived class nested in its base class. I am quite comfortable with nested anythings in python or a few other languages, so that's not a problem. I nest 'testable' classes in tests all the time so I can override or stub a few methods. In python it's a normal way of life to nest functions and classes.

This one is odd because it is a production class, nested inside a production class, and deriving from its outer class. It makes me think of a pregnant female, having a child inside it whose dna derives from the mother.

So what powers does this odd nesting convey? My first thought is that it is some kind of closure, but this turns out to be false. There is no real closure involved. The whole closure that derives from the parent made my head swim just a bit, but it is a wild goose chase. Nothing to it.

What does happen is that the nesting bestows readability on the private variables inherited from the enclosing parent. The x in the setX is the Derived.x inherited from Base. It is referencing its own variable, even though that variable is private instead of protected in the parent. Indeed, resharper refused to move the class to an outer scope because its own variables would become unreachable to its own methods. To do that extraction, we made the variables protected in the parent.

The other thing that it did was hide the class from an automated test program. These classes are both code-behind for web pages. We have an automated tool that searches the namespace for all classes derived from our base web component class and ensures that they all have page generation tests. This one did not.

I am wondering if there is some interesting way to use this like a private interface class in C++ or Java. It was curious, but I'm wondering if it can't also be useful.

2 comments:

  1. This turns out to be a brilliantly perverse abuse of the rules. The author made some private flags, and behavior of various functions depended on the flags (if/else).

    Then they embedded a child class, whose only behavior is to set the PRIVATE flags on construction.

    Viola! You have inheritance to change behaviors, without having to give up munging and cyclomatic complexity! Genius!!!

    ReplyDelete
  2. This wasn't as obvious without its context, so I'm adding a new comment so you can see how messed up this idea is. I'm now calling it the "derivative setter" code smell:

    class Base {
    private int typeflag; // Defaults to zero.

    class Derived: Base{
    public Derived() {
    typeflag = 1;
    }
    }

    public void method() {
    if(typeflag == 0 ){
    // Do base class stuff.
    }
    else if (typeflag == 1) {
    // Do derived class stuff.
    }
    if (typeflag == 0) {
    // more base class stuff
    }
    }
    }

    ReplyDelete