Question about using Interfaces

RangerGuy posted on Tuesday, September 05, 2006

I need to expose a few fields from a child object to a list of grandchildren. I was thinking that instead of each grandchild containing private members that hold the data needed from the parent. I could just use an interface to expose the data that the grandchild would like to reference OR would a reference back from grandchild to child be ok? Have I totally missed this concept of Interfaces :|

RockfordLhotka replied on Tuesday, September 05, 2006

From a pure design perspective, interfaces are to implement an "acts-as" behavior. If an object is one thing, but can "act as" something else, then an interface is the right answer.

Interfaces are also a programmer tool, that enable some technical scenarios where "acts-as" isn't really applicable. Decoupling is the primary one, where you can use an interface (often in a seperate assembly) to decouple a caller from a callee. Sometimes you'll even do this if the callee's native interface (public members) are the same as those of the interface. I suppose you could say the object "acts-as" itself, but that seems a bit silly...

Ideally though, the programmatic usage should fit within an "acts-as" relationship - thus satisfying the real goal behind the concept of interfaces.

The question you need to ask, is whether the parent "acts-as" something different from itself, or whether you want the child objects to be decoupled from the parent so they could talk to other parents that might implement that interface as well? Or, does the interface truly abstract an idea, so the parent really does "act as" something else (or a subset of itself) in a meaningful manner.

My guess is that you can create an interface that satisfies the "acts-as" requirement, and also provides decoupling so the child can be contained by any parent with that interface.

Your bigger issue will be safely providing the parent reference. The collection object will automate part of the process - in that each child automatically has a safe reference to its parent collection. But it is up to you to store and manage any reference to the object containing the collection itself. Personally what I'd recommend is having the collection maintain a reference to the parent (mark it as nonserialized and notundoable!), and then having a ParentObject property in your child class that uses the pre-existing collection reference to get to the collection, and then uses that to get to the real parent.

So in your child class:

Private ReadOnly Property ParentObject() As IFoo
  Get
    Return CType(CType(Parent, IHaveAParent).Parent, IFoo)
  End Get
End Property

You must define IFoo and IHaveAParent.

Your collection will implement IHaveAParent, which will require a read-only Parent property. It will also have a Friend/internal method, SetParent(), and it will store the parent reference in a nonserialized, notundoable field.

Your parent object will implement IFoo, which has whatever properties you want. It must also call SetParent() on the child collection as needed. At a minimum this means calling SetParent() any time you create an instance of the collection (like in DataPortal_Create()), and in an override of OnDeserialized to reset the value after deserialization.

RangerGuy replied on Wednesday, September 06, 2006

Thanks again for the awesome reply Rocky :) I'm going to try and implement this idea today.

nmkr replied on Friday, May 18, 2007

Hello RangerGuy,

Did you get a chance to implement this..?.

 

 

david.wendelken replied on Monday, May 21, 2007

Is there any good reason why interfaces do not allow properties or static methods?

RockfordLhotka replied on Monday, May 21, 2007

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/813 - Release Date: 5/20/2007 7:54 AM

RockfordLhotka replied on Monday, May 21, 2007

Don't get me wrong - a formalized interface concept for static/Shared methods would be awesome! But it makes sense to me why the current interface declaration concept can't be used for the purpose.

Regarding properties, you can see examples in Csla.Core.

Public Interface Foo
  Property X() As Integer
  ReadOnly Property Y() As String
End Interface

public interface Foo
{
  int X { get; set; }
  string Y { get; }
}