如何在C#中创建访问object属性的接口？

Question

I want to generalize limited access to certain fields of an object:

class Foo {
    public int Bar;
    public int Qux;
}

To do that, I've declared an interface:

interface IModifiableFoo {
    int Bar {get; set;}
}

Then to limit access to that object, I've made a class that wraps it:

class ModifiableFoo : IModifiableFoo {
    private readonly Foo ActualFoo;

    ModifiableFoo(ref Foo foo) {
        ActualFoo = foo;
    }

    public int Bar {
        get => ActualFoo.Bar;
        set { ActualFoo.Bar = value; }
    }
}

Finally, I'm using this wrapper to offer limited access to the Foo object:

Foo myFoo = new Foo();

IModifiableFoo ModifyFoo() {
    return (IModifiableFoo) new ModifiableFoo(ref MyFoo);
}

IModifiableFoo fooAccess = ModifyFoo();
fooAccess.Bar = 3;

Console.WriteLine(myFoo.Bar); // 3

As a result, the contract IModifiableFoo acts as a generalization over what fields you can change when you gain the right to modify the Foo .

However, as the interface only declares a getter and a setter their actual implementation is not restricted, and allows this to happen:

class ModifiableFoo : IModifiableFoo {
    ModifiableFoo(ref Foo foo) {}

    public int Bar {
        get => 42,
        set {
            Console.WriteLine("Not something you would expect");
        }
    }
}

How do I implement this functionality and ensure that the implementation will always get and set the corresponding field?

Answer 1

If you're looking to guarantee some portion of the implementation, then it seems to me the best way to control that would be to implement it. You know you want to expose a method, you know that it needs to wrap a Foo, and you know you want that method to cause things to happen to Foo in a consistent way, so perhaps an abstract class?

    public abstract class ModifiableFoo : IModifiableFoo
    {
        private Foo _foo;

        protected ModifiableFoo(Foo foo)
        {
            _foo = foo;
        }

        public int Bar
        {
            get => _foo.Bar; 
            set { _foo.Bar = value; }
        }
    }

    public class ExtendedModifiableFoo : ModifiableFoo
    {
        public ExtendedModifiableFoo(Foo foo) : base(foo)
        {

        }

        public int Bar // this doesn't work as shown because Bar is not overridable
        {
            get => _foo.Bar; // nor does this because _foo is inaccessible due to its protection level
        }
    }

Answer 2

A solution's shape fits a specific problem. From what I understand of your question, you want to control data read/write permissions at application runtime. A CvarRegistry comes to mind. Please refer to the original by id Software, as this is just an outline.

    public Cvar { }
    public Cvar<T>
    {
        public T Value { get; set; }
    }
    public CvarRegistry : Dictionary<string, Cvar> { }

You could dynamically control access by: 1) adding and removing Cvars to the accessible collection, (hoping the consumers don't hold onto references) 2) adding getter-only versions to the accessible collection, or 3) building a regulator which exclusively toggles the readonly state of each Cvar value, which forces branching at setter access-time.

Unfortunately, an object property can be a whole object with its own accessible properties, and so artificial control leaks. The real CvarRegistry is flat, as every Cvar points to a primitive. I have not found a way to constrain generics to primitives, but I do not believe it necessary.

OOP teaches you to conceptualize data as an object's personal property or state. Realize this assumption forces you to then MANUALLY deliver the "state" values between "objects." This results in a form of process known as distributed manufacturing . Each OOP module has a redundant (internal) representation of the (shared) memory locations they control and e-mail to one another. In contrast, reference properties (Cvars) allow different modules to simply share memory.

    public Cvar<int> x { get; set; }

    public void M()
    {
        x.Value += 3;
    }
    public void N() 
    {
        x.Value *= 4;
    }

    // N() could be a method in another class, another namespace
    // and you would have zero coupling

My manufacturing architecture is a whole alternative paradigm to OOP where modules interact with an end product, rather than artificially owning and controlling memory as if it's always internal state. So another way to look at the problem is to ask whether "object properties" are necessary. Sometimes they are, but not in a production context, which is most code.