Questo ibrido di Interface / Composition kosher?

Sto lavorando a un progetto in cui sto considerando l'utilizzo di un ibrido di interfacce e composizione come una singola cosa .

Ciò che intendo per questo è avere una classe contain * ee * da utilizzare come front per funzionalità implementate in una classe contain * er *, in cui il contenitore espone il contenuto come una proprietà pubblica.

Esempio (pseudocodice):

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() {...}

Ci sono tre ragioni per cui sto considerando questo:

1. La lingua in cui sto lavorando (F #) ha qualche fastidio w.r.t. implementare le interfacce nel modo in cui ho bisogno (a meno che mi manchi qualcosa) e questo aiuterà a evitare un sacco di codice boilerplate.
2. Le classi containee potrebbero davvero essere considerate proprietà delle classi di contenitori; ad esempio, sembra esserci una relazione abbastanza strong con una relazione.
3. Le classi containee probabilmente implementeranno un codice che sarebbe stato più o meno lo stesso se implementato in tutte le classi del contenitore, quindi perché non farlo una volta in un posto? Nell'esempio precedente, ciò include la gestione e l'emissione degli eventi Mostrato / Nascosto.

Qualcuno vede qualche isseus con questo metodo di Composiface / Intersition, o conosce un modo migliore?

EDIT 2012.07.26 - Sembra che un po 'di informazioni di base siano giustificate:

Dove lavoro, abbiamo un sacco di front-end delle applicazioni che hanno un accesso limitato alle risorse di sistema: hanno bisogno di accedere a queste risorse per funzionare pienamente. Per ovviare a questo abbiamo un'applicazione di back-end che può accedere alle risorse necessarie, con le quali i front-end possono comunicare. (Esiste un'API scritta per i front-end per l'accesso alla funzionalità di back-end come se fosse parte del front-end.)

Il programma di back-end non è aggiornato e la sua funzionalità è incompleta. Ha fatto il passaggio da una compagnia all'altra un paio di volte e non riusciamo nemmeno a compilarlo più. Quindi sto cercando di riscriverlo nel mio tempo libero.

Sto cercando di aggiornare le cose per creare un'interfaccia / API (r) per i front-end (pur consentendo la retrocompatibilità con i front-end meno recenti), sperando che qualcosa sia pieno di OOPy. Il fatto è che non voglio scrivere l'API front-end dopo aver scritto più o meno lo stesso codice in F # per implementare il back-end; quindi, quello che sto pensando di fare è applicare gli attributi alle classi / metodi / proprietà che vorrei avere il codice per l'API, quindi generare questo codice dall'assembly F # usando reflection.

Il metodo descritto in questa domanda è una possibile alternativa che sto considerando invece di implementare interfacce diritte sulle classi in F # perché sono una specie di orso: per accedere a qualcosa di un'interfaccia che è stata implementata in un classe, devi lanciare esplicitamente un'istanza di quella classe al tipo di interfaccia. Ciò renderebbe le cose dolorose quando si ricevono chiamate dai front-end. Se non vuoi farlo devi chiamare tutti i metodi dell'interfaccia / proprietà di nuovo nella classe, al di fuori dell'implementazione dell'interfaccia (che è separata dai normali membri della classe) e chiama i membri dell'implementazione. In pratica si sta ripetendo lo stesso codice, che è quello che sto cercando di evitare!