"Merging" types, without using reflection or duplicating code?
<p>Couldn't seem to think of a good title, my apologies. Feel free to change it to something more appropriate; I'd appreciate it.</p>

<p>I'm in an unusual position here (or maybe not so unusual). I have a base type, from which will branch many types that extend its functionality but remain pretty consistent. Some of these will more or less be duplicates, but to present data in different ways. They can all be managed in much the same manner, so what I've decided to do is create a "merging" class that will take two or more of these objects and allow control over them all at once, but I've resorted to using reflection. If I were to redefine all the members of the base class and simply redirect all sets/gets/etc, it's just plain <em>wrong</em>, because if the base class to the types I'm "merging" were to ever change, so must the merging class.</p>

<p>But this leads to a performance cost I believe can be avoided. A performance hit not just from reflection but from the predictable boxing/unboxing <em>during</em> reflection.</p>

<p>Here's a pseudo-code example of what I'm doing:</p>

<pre><code>class SomeBase
{
    public virtual bool SomeBool { get; set; }
}

class SomeDerived : SomeBase
{
    // ... extends SomeBase
}

class SomeMerger
{
    private SomeBase[] collection;

    public SomeMerger(SomeBase[] collection)
    {
        this.collection = collection;
    }

    public void SetProperty(string propertyName, object value)
    {
        for (int i = 0; i &lt; this.collection.Length; i++)
        {
            PropertyInfo pi = collection[i].GetType().GetProperty(propertyName, BindingFlags.Public | BindingFlags.Instance);
            if (pi != null)
                pi.SetValue(collection[i], value, null);
        }
    }

    // .. etc
}
</code></pre>

<p>Now, what I'd <em>like</em> is to be able to do is access members as if they were a single entity inside the merger class (e.g. "SomeMergerObject.SomeBool = true" would set all the SomeBool properties in all the objects it merges to true, making the syntax more natural). However, the only way I can see of doing this would be to redefine all methods and properties of the base class and redirect calls to them (which I don't think would be considered right). Is there any cleaner/better way of achieving this?</p>

<p>Sorry if I did a poor job at explaining this. Yell if you're confused and I'll try to clarify. :)</p>

<p><strong>Edit:</strong></p>

<p>I guess I need to clarify a bit. I suppose I was misleading when I said "I have this base type etc" -- the implementation is as it stands, and isn't <em>mine</em>, all I'm attempting to do is make it easier to work with. Instead of setting basic properties for several objects that all share in areas like visibility state (as an example), I thought it would be a nice feature (albeit a trivial one, and more work than it's worth... but for curiosity's sake, why not explore the idea?) to make a collection of objects behave as one. This isn't even coming close to a problem, just an idea for improvement that I felt like flirting with.</p>

<p>I wasn't suggesting "a new language feature," and the tone of my question was <em>is there a way to do this</em>, a clean and right way. I guess I presented my inquiry badly, sorry about that.</p>
