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!

  • Why re-provide the show/hide as private methods? Just let SomeClassWithVisibility use its member Visibility.
    – Telastyn
    Commented Jul 25, 2012 at 18:23
  • My hope was to provide better consistency across objects. The class itself wouldn't have the visibility properties, but an object it contained would.
    – paul
    Commented Jul 25, 2012 at 18:49
  • Also, I need to adorn the visibility properties (among others) with attributes, which I couldn't do if I just exposed the contained object since I don't have access to its definition.
    – paul
    Commented Jul 25, 2012 at 18:56

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

  • It seems like Facade is more along the lines of what I'm looking for but isn't completely there.
    – paul
    Commented Jul 25, 2012 at 20:59
  • OK, let's go back to the basics: what are design patterns? Design patterns are problem-patterns which have a corresponding solution-pattern. (This definition comes from the original APL book, not from the DP one) Patterns are like constellations: it doesn't matter what stars do participate in Ursula Major, it only matters what are their relationships. What is the problem you're facing? How well does the problem (not the solution) match the context / forces of one of your patterns? To what are you trying to expose visibility? Why do you need to wrap them? Monads perhaps?
    – Aadaam
    Commented Jul 25, 2012 at 21:59
  • I think the design-patterns tag might have been a bit misleading. I've updated my question with some background info.
    – paul
    Commented Jul 26, 2012 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.