interface protection boundaries.. internal/friend.. OOD advice

[Trey Hutcheson]

Hey guys,
Here's a tricky one. I've got a Management class that has methods that
return references to an interface called, for this case, IComp. Internally,
the Management class scans its own internal registration information to figure
out which assembly and class to actually instantiate that implements the
IComp interface. Upon instantiation, it returns a reference to this new instance.
Ok.. everything's good so far.
Each class that implements IComp has its own configuration that is maintained
by the Management class. At runtime, and consumer of IComp needs the ability
to query that interface for its configuration (likely some Xml DOM doc),
however it needs readonly access. That's simple enough to enforce through
the interface declaration. However, the Management class needs to be able
to update the configuration for a given instance of IComp at runtime, therefor
the Management class needs write access to the "configuration" member of
the IComp interface. It doesn't have to be a property; it can be any type
of accessor. BUT, when designing an interface, one cannot declare an interface
to be public and to contain any private, protected, or internal/friend members.
That makes sense. But, the problem is, how do I enfore read-only access to
members of an interface, but allow write access to that same member from
1 designated source? I can change the interface to be an abstract base class,
but that won't work because having everything descend from IComp is just
not possible for this project.
Any ideas?

thx
trey

[Mattias Sjögren]

Trey,

>But, the problem is, how do I enfore read-only access to
>members of an interface, but allow write access to that same member from
>1 designated source? I can change the interface to be an abstract base class,
>but that won't work because having everything descend from IComp is just
>not possible for this project.
> Any ideas?

Can't you just use two interfaces? IComp gives read-only access to the
configuration, and some other interface that is only accessible to the
Management class provides write access.


Mattias

===
Mattias Sjögren (VB MVP)
mattias @ mvps.org
http://www.msjogren.net/dotnet/

[Trey Hutcheson]

Mattias,
You know, I was thinking something long those lines, but pardon me for
ignorance, how would I go about doing something like that? If anything that
implements IComp implements another interface, like ICompWriter (or something
like that) which provides write access, then what prevents a consumer of
IComp from simply type-casting the interface reference to ICompWriter? I
can make ICompWriter internal to the project that contains the Management
class, but then that implies that every implementation of ICompWriter needs
to be located in the same project as the Management class, does it not?

trey

>Can't you just use two interfaces? IComp gives read-only access to the
>configuration, and some other interface that is only accessible to the
>Management class provides write access.
>

[Kunle Odutola]

"Trey Hutcheson" <inturn@hotmail.com> wrote in message
news:3ca1e4f6$1@10.1.10.29...
>
> Hey guys,

> However, the Management class needs to be able
> to update the configuration for a given instance of IComp at runtime,
therefor
> the Management class needs write access to the "configuration" member of
> the IComp interface. It doesn't have to be a property; it can be any type
> of accessor. BUT, when designing an interface, one cannot declare an
interface
> to be public and to contain any private, protected, or internal/friend
members.
> That makes sense. But, the problem is, how do I enfore read-only access to
> members of an interface, but allow write access to that same member from
> 1 designated source? I can change the interface to be an abstract base
class,
> but that won't work because having everything descend from IComp is just
> not possible for this project.

Trey,

It helps to think of an interface as [the basic part of] the contract for a
"role" than a class/object plays in a system. For instance by implementing
IComp, a class is playing the role of an entity that is managed by the
Management class, and whose configuration can be read by anyone(?) [at the
very least plus whatever else IComp designates].

By implementing additional interfaces, the same class can also play the role
of an entity whose configuration can be changed (by the Management class)
etc. What this means basically is that you should define another interface
that allows the IComp object's config to be changed. You might want to
consider creating an "ICompManager" interface too. Especially if there can
be many types of Managers....

Kunle

[Trey Hutcheson]

Kunle,
I appreciate the explanation, but unfortunately that is the perspective
from which I am writing this system. See my previous response to Mattias.
I know how to work around my problem logically, I'm just afraid that I can't
ENFORCE the protection of this configuration information. What I really need
is C++-like "Friend" functionality... cooperation between two named objects.

trey

"Kunle Odutola" <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:
>
>"Trey Hutcheson" <inturn@hotmail.com> wrote in message
>news:3ca1e4f6$1@10.1.10.29...
>>
>> Hey guys,
>
>> However, the Management class needs to be able
>> to update the configuration for a given instance of IComp at runtime,
>therefor
>> the Management class needs write access to the "configuration" member
of
>> the IComp interface. It doesn't have to be a property; it can be any type
>> of accessor. BUT, when designing an interface, one cannot declare an
>interface
>> to be public and to contain any private, protected, or internal/friend
>members.
>> That makes sense. But, the problem is, how do I enfore read-only access
to
>> members of an interface, but allow write access to that same member from
>> 1 designated source? I can change the interface to be an abstract base
>class,
>> but that won't work because having everything descend from IComp is just
>> not possible for this project.
>
>Trey,
>
>It helps to think of an interface as [the basic part of] the contract for
a
>"role" than a class/object plays in a system. For instance by implementing
>IComp, a class is playing the role of an entity that is managed by the
>Management class, and whose configuration can be read by anyone(?) [at the
>very least plus whatever else IComp designates].
>
>By implementing additional interfaces, the same class can also play the
role
>of an entity whose configuration can be changed (by the Management class)
>etc. What this means basically is that you should define another interface
>that allows the IComp object's config to be changed. You might want to
>consider creating an "ICompManager" interface too. Especially if there can
>be many types of Managers....
>
>Kunle
>
>

[Mattias Sjögren]

Trey,

>I can make ICompWriter internal to the project that contains the Management
>class, but then that implies that every implementation of ICompWriter needs
>to be located in the same project as the Management class, does it not?

Right. If that doesn't fit your system, another option is perhaps to
use .NET's code access security features to control who may call the
writing methods. I know way too little about CAS myself, so I can't
give you any details on how this is done (or if it's even a possible
and good solution). But I suggest you start by reading the Identity
Permissions topic in the docs.


Mattias

===
Mattias Sjögren (VB MVP)

[Kunle Odutola]

"Trey Hutcheson" <inturn@hotmail.com> wrote in message
news:3ca20fc0$1@10.1.10.29...
>
> Kunle,
> I appreciate the explanation, but unfortunately that is the perspective
> from which I am writing this system. See my previous response to Mattias.
> I know how to work around my problem logically, I'm just afraid that I
can't
> ENFORCE the protection of this configuration information. What I really
need
> is C++-like "Friend" functionality... cooperation between two named
objects.

Trey,

This is an orthogonal issue (to the roles your interface and classes play).
There are facilities for enforcing this kind of restriction in .NET, look up
StrongNameIdentityPermission for instance. Don't think C++'s friend modifier
is sufficient.

Kunle