Interface Inheritance for IDisposable - DOTNET

This is a discussion on Interface Inheritance for IDisposable - DOTNET ; All - This might be a purist question, but i want to convince my handler with a reasonable argument. Lets say i have an object *internal* to my assembly (InternalMyObject) and it implements an exposed interface (IMyObject). I want to ...

+ Reply to Thread
Results 1 to 6 of 6

Interface Inheritance for IDisposable

  1. Default Interface Inheritance for IDisposable

    All -
    This might be a purist question, but i want to convince my handler with a
    reasonable argument.

    Lets say i have an object *internal* to my assembly (InternalMyObject) and
    it implements an exposed interface (IMyObject). I want to specify that the
    object that implements IMyObject is a disposable object, so i derive
    IMyObject from IDisposable.
    interface IMyObject : IDisposable {}

    It is easy to say now
    IMyObject obj = SomehowCreate();
    obj.Dispose();

    If i *dont* inherit IMyObject from IDisposable, i must say
    if(obj is IDisposable)
    ((IDisposable)obj).Dispose();

    which sort of looks clumsy.
    The argument *against* the first approach is that, inheritance specifies a
    "IS A" relation-ship and my handler argues that IMyObject "IS NOT A"
    IDisposable.

    He says that it should be the concrete-object that shoudl implement
    IDisposable, and we shoudl always query for IDisposable(C# 'is') - but from
    a pragmatic perspective i feel the first approach is better.

    Whats the preferred way of saying that the interface an (internal) object
    points to is disposable? Should the interface derive from IDisposable or the
    client should do a QI for the same?

    Thanks for ur time.

    Regardz
    Grafix.


  2. Default Re: Interface Inheritance for IDisposable

    Grafix wrote:

    > All -
    > This might be a purist question, but i want to convince my handler
    > with a reasonable argument.
    >
    > Lets say i have an object internal to my assembly (InternalMyObject)
    > and it implements an exposed interface (IMyObject). I want to specify
    > that the object that implements IMyObject is a disposable object, so
    > i derive IMyObject from IDisposable.
    > interface IMyObject : IDisposable {}
    >
    > It is easy to say now
    > IMyObject obj = SomehowCreate();
    > obj.Dispose();
    >
    > If i dont inherit IMyObject from IDisposable, i must say
    > if(obj is IDisposable)
    > ((IDisposable)obj).Dispose();
    >
    > which sort of looks clumsy.
    > The argument against the first approach is that, inheritance
    > specifies a "IS A" relation-ship and my handler argues that IMyObject
    > "IS NOT A" IDisposable.
    >
    > He says that it should be the concrete-object that shoudl implement
    > IDisposable, and we shoudl always query for IDisposable(C# 'is') -
    > but from a pragmatic perspective i feel the first approach is better.
    >
    > Whats the preferred way of saying that the interface an (internal)
    > object points to is disposable? Should the interface derive from
    > IDisposable or the client should do a QI for the same?


    My take: Let the class implement it, and if your classes share an
    inheritance tree, let a base class implement IDisposable according to
    the usual pattern. Derived classes may then override void Dispose(bool)
    if required.

    Cheers,
    --
    http://www.joergjooss.de
    mailto:news-reply@joergjooss.de

  3. Default Re: Interface Inheritance for IDisposable

    > Lets say i have an object *internal* to my assembly (InternalMyObject) and

    The design issues aren't really affected by internal vs public: The
    same principle distinguish good design from bad design. A bad design
    will mislead someone maintaining your internal code in just the same
    way as a bad design will mislead someone consuming your public API.

    > it implements an exposed interface (IMyObject). I want to specify that the
    > object that implements IMyObject is a disposable object, so i derive
    > IMyObject from IDisposable.
    > interface IMyObject : IDisposable {}


    The thing is, people expect an interface to represent behavior, not
    accidents of implementation. By deriving IMyObject from IDisposable,
    you are not telling people that every implementation of IMyObject will
    have state data that needs to be disposed of, but that IMyObject
    represents state data that needs to be disposed of. The difference is
    subtle but real, and breaking the patterns can waste people's time,
    downstream.

    > If i *dont* inherit IMyObject from IDisposable, i must say
    > if(obj is IDisposable)
    > ((IDisposable)obj).Dispose();


    Fwiw, the idiom

    IDisposable Disposable = obj as IDisposable;
    if (Disposable != null)
    Disposable.Dispose();

    is smaller (at the object code level) and faster.

    > The argument *against* the first approach is that, inheritance specifies a
    > "IS A" relation-ship and my handler argues that IMyObject "IS NOT A"
    > IDisposable.


    He's right.

    > He says that it should be the concrete-object that shoudl implement
    > IDisposable, and we shoudl always query for IDisposable(C# 'is') - but from
    > a pragmatic perspective i feel the first approach is better.


    OK, let's be pragmatic. Your way saves a little time when you code it
    the first time, by letting you avoid an `as` cast and an `if != null`
    test - but your way also wastes a little time whenever anyone reads
    your code. They'll ask "Where does this Dispose() call come from?"
    Often they'll F12 to the definition of IMyObject to see what's going
    on. By contrast, anyone reading an as/if pair will know exactly what's
    going on.

    Bottom line: keeping your code semantically clean saves money over the
    life of the code.


    --
    <http://www.midnightbeach.com>

  4. Default Re: Interface Inheritance for IDisposable


    "Jon Shemitz" <jon@midnightbeach.com> wrote in message
    news:4394BF73.75B3AD94@midnightbeach.com...
    >> Lets say i have an object *internal* to my assembly (InternalMyObject)
    >> and

    >
    > The design issues aren't really affected by internal vs public: The
    > same principle distinguish good design from bad design. A bad design
    > will mislead someone maintaining your internal code in just the same
    > way as a bad design will mislead someone consuming your public API.
    >
    >> it implements an exposed interface (IMyObject). I want to specify that
    >> the
    >> object that implements IMyObject is a disposable object, so i derive
    >> IMyObject from IDisposable.
    >> interface IMyObject : IDisposable {}

    >
    > The thing is, people expect an interface to represent behavior, not
    > accidents of implementation. By deriving IMyObject from IDisposable,
    > you are not telling people that every implementation of IMyObject will
    > have state data that needs to be disposed of, but that IMyObject
    > represents state data that needs to be disposed of. The difference is
    > subtle but real, and breaking the patterns can waste people's time,
    > downstream.
    >
    >> If i *dont* inherit IMyObject from IDisposable, i must say
    >> if(obj is IDisposable)
    >> ((IDisposable)obj).Dispose();

    >
    > Fwiw, the idiom
    >
    > IDisposable Disposable = obj as IDisposable;
    > if (Disposable != null)
    > Disposable.Dispose();
    >
    > is smaller (at the object code level) and faster.
    >
    >> The argument *against* the first approach is that, inheritance specifies
    >> a
    >> "IS A" relation-ship and my handler argues that IMyObject "IS NOT A"
    >> IDisposable.

    >
    > He's right.
    >



    I have to disagree. Interface inheratence does not define an "IS A"
    relationship, but rather an "OPERATES LIKE" relationship. Inheriting from
    IDisposable simply indecates that implementing classes will likely have a
    Create, Use, Cleanup lifecycle.

    But more importantly, he's missing the most important thing about disposable
    types. With any disposable type the first-order concern is making sure that
    client code actually disposes the instances!

    If you are difining an interface it is likely that conusmer code will not
    know about the actual implementation. So if you hide the fact that the type
    is disposable in the concrete implementation then you increase the
    possibility that client code will use the type without disposing it. if
    IMyObject doesn't inherit from IDisposable then this code:

    void DoSomething()
    {
    IMyObject myObj = MyObjectFactory.GetMyObject();
    myObj.Flarg();
    }

    is wrong, but not obviously wrong. No static ****ysis of the code can reveal
    that a Disposable object is being used without being Disposed. A developer
    who wrote the above, incorrect code, would rightly ask,
    "Well how the hell was I supposed to know that IMyObject was disposable?".
    The only way would by to put that stupid little "is IDisposable" test on
    absulutely every use of an object through an interface or non-sealed type
    variable on the off chance that the concrete run-time type is disposable.


    David



  5. Default Re: Interface Inheritance for IDisposable

    I think in the OP's case he can do pretty much what he wants to since
    it's his object and his interface and judging by the names in his
    example there is a 1-to-1 match. Probably he has made the interface so
    that he can use the full range of methods on the class internally in the
    assembly and yet expose a set of those methods to other assemblies
    through an interface.

    In this case he can just as well specify that his interface also brings
    IDisposable into the game since it's his object.

    On a general basis, unless the interface contract (documentation) states
    that there is resources that needs to be disposed of in every
    implementation of that interface, I would not do it and instead document it.

    David Browne wrote:
    > "Jon Shemitz" <jon@midnightbeach.com> wrote in message
    > news:4394BF73.75B3AD94@midnightbeach.com...
    >

    <snip>
    >
    >
    > I have to disagree. Interface inheratence does not define an "IS A"
    > relationship, but rather an "OPERATES LIKE" relationship. Inheriting from
    > IDisposable simply indecates that implementing classes will likely have a
    > Create, Use, Cleanup lifecycle.


    Implementing classes *will have* a cleanup method, but it can of course
    be empty.

    >
    > But more importantly, he's missing the most important thing about disposable
    > types. With any disposable type the first-order concern is making sure that
    > client code actually disposes the instances!


    And you won't get the compiler to enforce that no matter what you do.
    The closest thing you'll get is to provide a finalizer that throws an
    exception because it obviously should never be executed.

    >
    > If you are difining an interface it is likely that conusmer code will not
    > know about the actual implementation. So if you hide the fact that the type
    > is disposable in the concrete implementation then you increase the
    > possibility that client code will use the type without disposing it. if
    > IMyObject doesn't inherit from IDisposable then this code:


    There could be many gotchas with an object that you don't know of. There
    is no way you will be able to talk the compiler into enforcing all of
    these. The only good way to make sure the object is used correctly is to
    provide a good set of documentation for it.

    >
    > void DoSomething()
    > {
    > IMyObject myObj = MyObjectFactory.GetMyObject();
    > myObj.Flarg();
    > }
    >
    > is wrong, but not obviously wrong. No static ****ysis of the code can reveal
    > that a Disposable object is being used without being Disposed. A developer
    > who wrote the above, incorrect code, would rightly ask,
    > "Well how the hell was I supposed to know that IMyObject was disposable?".


    He should've read the documentation. Not everything can be inferred from
    reading method names and class signatures.

    > The only way would by to put that stupid little "is IDisposable" test on
    > absulutely every use of an object through an interface or non-sealed type
    > variable on the off chance that the concrete run-time type is disposable.


    If you're going to be paranoid about IDisposable, then yes. There's also
    such a thing as future-proof. What if you use a class in your current
    project and it doesn't implement IDisposable, and tomorrow you upgrade
    to the latest version. The compiler won't tell you that you're now
    supposed to dispose of the object but you have introduced a problem anyway.

    Would I write code to make sure every such use would be future-proof? No.

    --
    Lasse Vågsæther Karlsen
    http://usinglvkblog.blogspot.com/
    mailto:lasse@vkarlsen.no
    PGP KeyID: 0x2A42A1C2

  6. Default Re: Interface Inheritance for IDisposable

    Grafix,

    There is no general rule regarding this. It depends on your specific
    situation. If you want all IMyObject objects to behave like
    IDisposable objects as well then IMyObject should implement
    IDisposable. It's really that simple.

    Be careful about your usage of the word inherits. There is a
    distinction between inheriting and implementing despite C#'s syntax
    being the same. VB.NET actually uses two keywords to make the
    distinction (Inherits and Implements).

    If you want examples from the BCL where interfaces specify IDisposable
    then take a look at IDbConnection, IDbCommand, IDbTransaction,
    IResourceWriter, IContainer, IComponent, and IDesigner just to name a
    few.

    If you want examples where a QI is performed to test for IDisposable
    then take a look at how the compiler expands the foreach construct.

    My point is that Microsoft does it both ways.

    Brian

    Grafix wrote:
    > All -
    > This might be a purist question, but i want to convince my handler with a
    > reasonable argument.
    >
    > Lets say i have an object *internal* to my assembly (InternalMyObject) and
    > it implements an exposed interface (IMyObject). I want to specify that the
    > object that implements IMyObject is a disposable object, so i derive
    > IMyObject from IDisposable.
    > interface IMyObject : IDisposable {}
    >
    > It is easy to say now
    > IMyObject obj = SomehowCreate();
    > obj.Dispose();
    >
    > If i *dont* inherit IMyObject from IDisposable, i must say
    > if(obj is IDisposable)
    > ((IDisposable)obj).Dispose();
    >
    > which sort of looks clumsy.
    > The argument *against* the first approach is that, inheritance specifies a
    > "IS A" relation-ship and my handler argues that IMyObject "IS NOT A"
    > IDisposable.
    >
    > He says that it should be the concrete-object that shoudl implement
    > IDisposable, and we shoudl always query for IDisposable(C# 'is') - but from
    > a pragmatic perspective i feel the first approach is better.
    >
    > Whats the preferred way of saying that the interface an (internal) object
    > points to is disposable? Should the interface derive from IDisposable or the
    > client should do a QI for the same?
    >
    > Thanks for ur time.
    >
    > Regardz
    > Grafix.



+ Reply to Thread

Similar Threads

  1. Re: ado.net GC IDisposable implementation
    By Application Development in forum CSharp
    Replies: 0
    Last Post: 11-05-2007, 12:31 PM
  2. Idea: GC and IDisposable
    By Application Development in forum Framework and Interface Programming
    Replies: 52
    Last Post: 09-27-2007, 03:25 AM
  3. Replies: 3
    Last Post: 07-03-2007, 04:54 AM
  4. Replies: 7
    Last Post: 07-03-2007, 04:01 AM
  5. Interface-inheritance with TlbExp
    By Application Development in forum DOTNET
    Replies: 0
    Last Post: 11-07-2006, 12:10 PM