Interfacing common functionality between controls

Question

I'm not really sure how to ask this question. Suppose I have a class that needs to access certain properties of a Control (for example, Visible and Location). Perhaps I want to use the same class to access properties of another item that have the same name, but the class might not derive from Control. So I tried making an interface:

public interface IThumbnail {

    bool    Visible     { get; set; }
    int     Height      { get; set; }
    int     Width       { get; set; }
    Image   Image       { get; set; }
    Point   Location    { get; set; }

    event EventHandler Click;
}

Note that, for example, PictureBox happens to implement this interface. However, because the class definition does not say that it implements IThumbnail, I can't cast PictureBoxes to IThumbnails--I get an InvalidCastException at runtime. But why can't the CLR 'figure out' that PictureBox really does implement IThumbnail (it just doesn't explicitly say it does).

Also, what should I do to handle this situation? I want a way to access some of the PictureBox's properties without having my class know it's modifying a PictureBox.

Thx, Sam

PS- I'm a newbie to interface programming, so I apologize if this is a stupid q.

Thanks to all replies. I really wish I could mark more than one as an answer! — xofz, Apr 30 '09 at 18:29

score 5 · Accepted Answer · edited May 23 '17 at 10:33

It's not a stupid question, it's a good one. :)

What you're asking for on the interface is commonly referred to as "duck-typing." It isn't supported right now, but C#4.0 will support it via the new "dynamic" keyword.

You've really got three choices that I'm aware of at this point:

You can go up the tree until you find the common ancestor (probably Component) and then downcast to your supported types. If the downcast fails, you throw or handle appropriately.

Pro: Minimal code duplication.

Con: You're trading away compile-time type safety for runtime type safety. You have to add error checking/handling for invalid casts.

Code:
```
public void UseThumbnail(Component c) 
{
    PictureBox p = c as PictureBox;
    if(p != null) // do whatever
    // so forth
}
```
You can duplicate functionality as appropriate for everything that you need to implement this functionality for.

Pro: Maintain compile time type safety

Con: You're duplicating code for different types. This can grow into a significant maintenance burden, especially if you're handling more than two similar classes.

Code:
```
public void UsePictureBox(PictureBox p)
{
    // Some code X
}

public void UseOtherControl(OtherControl p)
{
    // Some code X
}
```
You can create your special interface and subclass the classes you want to support to expose that common functionality.

Pro: You get compile time safety and can program against your new interface.

Con: You have to add an empty subclass for everything you're dealing with, and you need to use them.

Code:
```
public class ThumbnailPictureBox : PictureBox, IThumbnail 
{ }
```

dub · Answer 2 · 2009-04-30T18:15:48.613

2

I guess you would have to make you own class that derives from PictureBox. That new class would also implement IThumbnail.

public class MyPictureBox : PictureBox, IThumbnail {

}

edited Apr 30 '09 at 18:15

answered Apr 30 '09 at 18:08

dub

1,396
12
22

score 2 · Answer 3 · answered Apr 30 '09 at 18:23

The CLR can't figure out that PictureBox implements the same method signature as IThumbnail because it's just not supported yet. The feature you are talking about here is often reffered to as Duck Typing, and it's a feature of dynamic languages such as Ruby - it should be available in .NET and C# with the next release (C# 4) and the DLR (dynamic language runtime).

To get the functionality you require right now, you can write a class that implements the IThumbnail interface and encapsulates an instance of a PictureBox.

public class ThumbnailPictureBox
{
  private PictureBox _pictureBox;

  public ThumbnailPictureBox(PictureBox pictureBox)
  {
    _pictureBox = pictureBox;
  }

  public bool Visible
  {
    get { return _pictureBox.Visible; }
    set { _pictureBox.Visible = value; }
  }

 // etc...
}

Joseph · Answer 4 · 2009-04-30T18:36:16.460

1

You could create your own class that implements the interface and has a PictureBox behind the scenes

class MyPictureBox: IThumbnail
{
    private PictureBox _pictureBox = new PictureBox();

    bool Visible     
    { 
        get 
        { 
            return _pictureBox.Visible; 
        } 
        set 
        { 
            _pictureBox.Visible = value; 
        }
    }

    //implement the rest, you get the idea
}

This pattern would also be useful in the event that you want to extend a 3rd party's "PictureBox" that is sealed, in which case you would not be abel to extend from it.

Actually Derik Whittaker just did a nice podcast on this pattern at dimecasts.net here

edited Apr 30 '09 at 18:36

answered Apr 30 '09 at 18:18

Joseph

25,330
8
76
125

Thanks, this is what I was thinking of doing. But what if I wish to use IThumbnails for other types? Would I have to create separate classes for each type to encapsulate them? – xofz Apr 30 '09 at 18:22
You would but if you're using 3rd party controls its usually a good idea to do that anyway, so you can decouple your code base away from the 3rd party controls. That way if you switch in the future it doesn't take as long to implement a new set of controls. – Joseph Apr 30 '09 at 18:38

score 1 · Answer 5 · answered Apr 30 '09 at 18:22

If the class you're interested in creating an interface for is not "sealed" then your could create a new class and inherit from the non-sealed class, implementing the interface.

If it were sealed (and I don't think PictureBox is) you'd probably want to build a wrapper class that implements the interface that you're interested in and contains a PictureBox control, exposing only the members that you're interested in.

score 0 · Answer 6 · answered Apr 30 '09 at 18:20

There are hundreds of interfaces in the .net runtime. If interfaces were left to be implicitly implemented, and the compiler were to go through and match up interfaces automatically to classes, every class you program could be matched to interfaces that you didn't even want it to.

As the other posters have suggested, your situation is exactly what OO is meant to solve ;) Try extending PictureBox to implement your interface.

score 0 · Answer 7 · edited May 23 '17 at 12:34

The situation you are describing is exactly what Interfaces are for

public interface IThumbnail
{
   bool Visible {get; set;}
   string FilePath {get; set;}
}

public class Bar : IFoo
{
   bool Visible {get; set;}
   int SomeNumber {get; set;}
   /* 
     rest of Bar functionality
   */
}

public class SomeClass
{
   public void DisplayThumbnail(IThumbnail thumb)
   {
      //Do Stuff to things.
   }
}

Once it is implemented that way, for any aspect of your program that shouldn't have access to any Bar functionality, but SHOULD have access to any IThumbnail functionality, just pass them an object of type IThumbnail

Bar bar = new Bar();

SomeClass someClass = new SomeClass();

someClass.DisplaySomething((IThumbnail) bar);

Now the DisplaySomething function cannot access any Bar exclusive functionality. It can only access the IThumbnail specific parts of it.

EDIT

This question deals with the same issue Will C#4.0 allow dynamic casting, If not, should it?

Interfacing common functionality between controls

7 Answers7