Subscribe: Atom or RSS

Russian Dolls and X-ray Specs

In an earlier entry titled ‘The Cache is a Shadow, Not a Box,’ I discussed how an incorrect mental image played havoc with Charlie. It may come as no surprise that another incorrect mental image has caused yet more problems.

The mental image I have of object-oriented inheritance is that of Russian Dolls. Here is a little bit of code to provide an example of how I see inheritance working:

public class MediumDoll
{
    private Object SmallDoll;
}

public class LargeDoll : MediumDoll
{
}

To put the code into words, I see the private SmallDoll as being inside its containing MediumDoll. If LargeDoll inherits MediumDoll, then I see the SmallDoll as being deep within LargeDoll. Because SmallDoll is of private scope, LargeDoll cannot access it directly. But even if LargeDoll cannot access the SmallDoll, the SmallDoll is still inside the LargeDoll—but with the MediumDoll separating the two.

If you know the basics of reflection in .NET, you will know that it allows us to both see and use members that are otherwise hidden from view. Without reflection, SmallDoll would be completely hidden from any code outside of MediumDoll. But with reflection, we can see and use SmallDoll even from outside of MediumDoll. A completely unrelated class, such as ToyMaker, could employ reflection to see and use the SmallDoll that is otherwise hidden inside MediumDoll.

Because reflection gives our code x-ray specs, I believed that if I pointed reflection at the LargeDoll, I could see through to the SmallDoll. This is not the case.

Putting the analogy aside for a moment, what I was trying to do was rectify a weakness in Charlie’s Entity System. In writing Charlie’s First Code, I gave each entity an ID value, and a public method that changed that ID value.

namespace Charlie.Framework.Business
{
    public class Entity
    {
  
        public Int32 Id
        {
            get
            {
                return this.id;
            }
        }
        private Int32 id = -1;

        //  
        //  While this method has the same scope (public) of the Id
        //  property, we'll use a separate method to set the Id, as
        //  the Id property is properly meant to be a read-only
        //  property from the point of view of all consuming code.
        //  While we could use reflection to "hide" this SetId method
        //  as private, that seems like needless complexity.
        //  
        public void SetID(Int32 id)
        {
            this.id = id;
        }
              
    }
}

After an entity is retrieved from the database, its ID value should not be changed, which is why its ID property is read-only. But as an entity is being retrieved from the database, there needs to be some way to set that ID value. For this reason, I kept the ID property as read-only, but gave the class a separate SetID method. In the notes I admitted that this was a hack to avoid the complexity of using reflection to set an otherwise read-only value.

Inspired by the success of using reflection to inspect Charlie’s Bucket Full of Plugins, I decided to finally get rid of that little SetID hack.

Here then is a concrete example of the Russian Doll analogy:

public class Entity
{
    private Int32 id;
}

public class Article : Entity
{
}

What I needed to do was update Charlie so that if it was given an Article that had been retrieved from the database, it could set the private id field. The id field is inside the Entity class, from which the Article class derives. To repeat, I believed that reflection would give Charlie the x-ray specs needed to see through the Article to the private id field hidden within. Here is a cut-down version of the code I tried:

FieldInfo field = article.GetType().GetField("id");
if (field != null)
    field.SetValue(entity, 3);

The code says, “For this article, grab the field named ‘id’, and set its value to 3.’ This did not work.

I firmly believed that if given an Article (or a LargeDoll), reflection should allow me to see through to the private id field (or a SmallDoll). My persistent mental image of reflection as x-ray specs meant that all of my debugging efforts were directed at the x-ray specs. There are many ways to fine-tune the GetField method shown above, including a promising-looking FlattenHierarchy option. Yet every attempt failed.

After failing continuously to set the private id field, I realized that my concept of reflection as x-ray specs must be wrong. (That seems obvious in retrospect, but we are typically unaware of the mental images that we are using.) So once I became aware that I was using a mental image of x-ray specs, I put it to one side and looked instead at the Russian dolls. Specifically, I changed the code to “open” the dolls until it got down to the tiny doll within, at which point the reflection would work to peek inside. Here is a simplified version of the code that did work.

Type type = article.GetType();
while (type != typeof(Entity))
{
    type = type.BaseType;
}
FieldInfo field = type.GetField("id");
if (field != null)
    field.SetValue(article, 3);

The emboldened code keeps opening a derived class until it gets down to the base Entity class (keeps opening dolls until it gets down to the MediumDoll), at which point the reflection can see inside and change a private member.

I am a little loathe to publish this weblog entry, as I feel sure that I am missing something. In reading about reflection, I have never before seen a discussion about unravelling derived classes in order to see and use private members. Still, this weblog represents an honest account of Charlie’s development, and this does represent another little step.

by Alister Jones |  

5 comments

----

Recent Posts

• A Bucket Full of Plugins
• Charlie’s Own Two Feet
• Implementing Raw Templating - Part 2
• Implementing Raw Templating - Part 1
• Recursion is not a Dirty Word
• The Raw Approach is Extensible
• The Raw Approach is Simple and Flexible
• A Raw Approach to Styling Webpages
• Olive, Teal, Peach, and Mauve
• Ready, Set, Go!