Question

J'ai l'impression de connaître la réponse que les gens vont donner, mais voici quand même:

Disons que j'écris une nouvelle classe, appelons-la PooledQueue<T>, dans le constructeur pour lequel je souhaite accepter un argument qui implémente l'interface IResourcePool<T>. L'idée ici est que je peux utiliser n'importe quel objet pool sous-jacent, à condition qu'il me donne les propriétés / méthodes de <=> (vous savez, toute l'idée derrière les interfaces, non?).

Mais s'il existe déjà une , une classe fournissant toutes les fonctionnalités de <=>, à l'exception du fait qu'elle n'implémente pas <=> (et je ne peux pas modifier le code source), puis-je forcer la mise en oeuvre?

Ce que j'attends des gens, c'est que je devrais créer un wrapper pour la classe existante qui implémente l'interface nécessaire. Mais je préférerais simplement pouvoir faire ceci:

// GetDataPool returns an object of type Pool<Data> that I can't modify
var q = new PooledQueue<Data>(GetDataPool());

au lieu de ceci:

var q = new PooledQueue<Data>(new PoolWrapper<Data>(GetDataPool()));

Je suppose que ce qui me semble vraiment utile, c’est que la mise en oeuvre d’une interface par une classe puisse être définie séparément de la définition de la classe. Triez la structure d'une base de données bien conçue - avec des tables d'association reliant des entités avec des identifiants d'autres tables. Est-ce que cela a du sens?

Était-ce utile?

La solution

Dans l'immédiat, vous ne pouvez pas forcer une interface sur une classe sans en hériter.

Il existe des moyens, tels que l'utilisation d'un élément transparent RealProxy ou des bibliothèques tierces telles que LinFU , qui vous permettent simuler ce genre de choses, mais à un coût plus élevé que celui de la classe d'emballage.

En fait, vous pouvez créer un constructeur de surcharge qui crée le wrapper pour vous, afin que le code reste propre ...

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top