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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 7 of 7

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

Hybrid View

  1. #1
    Trey Hutcheson Guest

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


    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

  2. #2
    Mattias Sjögren Guest

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

    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/

  3. #3
    Trey Hutcheson Guest

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


    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.
    >



  4. #4
    Kunle Odutola Guest

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


    "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



  5. #5
    Trey Hutcheson Guest

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


    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
    >
    >



  6. #6
    Mattias Sjögren Guest

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

    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)

  7. #7
    Kunle Odutola Guest

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


    "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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center