Is this Hybrid of Interface / Composition kosher?

Question

I'm working on a project in which I'm considering using a hybrid of interfaces and composition as a single thing.

What I mean by this is having a contain*ee* class be used as a front for functionality implemented in a contain*er* class, where the container exposes the containee as a public property.

Example (pseudocode):

class Visibility(lambda doShow, lambda doHide, lambda isVisible)
    public method Show() {...}
    public method Hide() {...}
    public property IsVisible
    public event Shown
    public event Hidden

class SomeClassWithVisibility
    private member visibility = new Visibility(doShow, doHide, isVisible)
    public property Visibility with get() = visibility
    private method doShow() {...}
    private method doHide() {...}
    private method isVisible() {...}

There are three reasons I'm considering this:

1. The language in which I'm working (F#) has some annoyances w.r.t. implementing interfaces the way I need to (unless I'm missing something) and this will help avoid a lot of boilerplate code.
2. The containee classes could really be considered properties of the container class(es); i.e. there seems to be a fairly strong has-a relationship.
3. The containee classes will likely implement code which would have been pretty much the same when implemented in all the container classes, so why not do it once in one place? In the above example, this would include managing and emitting the Shown/Hidden events.

Does anyone see any isseus with this Composiface/Intersition method, or know of a better way?

EDIT 2012.07.26 - It seems a little background information is warranted:

Where I work, we have a bunch of application front-ends that have limited access to system resources -- they need access to these resources to fully function. To remedy this we have a back-end application that can access the needed resources, with which the front-ends can communicate. (There is an API written for the front-ends for accessing back-end functionality as though it were part of the front-end.)

The back-end program is out of date and its functionality is incomplete. It has made the transition from company to company a couple of times and we can't even compile it anymore. So I'm trying to rewrite it in my spare time.

I'm trying to update things to make a nice(r) interface/API for the front-ends (while allowing for backwards compatibility with older front-ends), hopefully something full of OOPy goodness. The thing is, I don't want to write the front-end API after I've written pretty much the same code in F# for implementing the back-end; so, what I'm planning on doing is applying attributes to classes/methods/properties that I would like to have code for in the API then generate this code from the F# assembly using reflection.

The method outlined in this question is a possible alternative I'm considering instead of implementing straight interfaces on the classes in F# because they're kind of a bear: In order to access something of an interface that has been implemented in a class, you have to explicitly cast an instance of that class to the interface type. This would make things painful when getting calls from the front-ends. If you don't want to have to do this, you have to call out all of the interface's methods/properties again in the class, outside of the interface implementation (which is separate from regular class members), and call the implementation's members. This is basically repeating the same code, which is what I'm trying to avoid!

Answer 1

So, you're essentially using a decorator then?

Composition is about collections: eg, a grouping in a vector based app. If you can do the same thing with the group as you do with the single element (eg: resize, delete, etc), then you do composition in the sense of the composite pattern.

If you're just changing API, that's a decorator, or perhaps a Facade (albeit Facade usually hides a complex system of objects)