Comment puis-je hériter d'une classe singleton dans d'autres classes nécessitant la même fonctionnalité? Est-ce que quelque chose comme ça a du sens?
4 Réponses :
Quelqu'un n'hésitez pas à me corriger, mais de la façon dont je comprends, et eu une erreur avec cela une fois:
public class BaseClass
{
protected static List<string> ListOfSomething { get; set; }
}
public class ChildClass
{
protected static List<int> ListOfSomethingElse { get; set; }
}
public class AnotherChildClass
{
protected static List<int> ListOfSomethingElse { get; set; }
}
Jon Skeet a écrit à propos de ce un moment de retour. Il est possible de réaliser certains des avantages de l'héritage avec le singleton, bien que l'utilisation de classes intérieures imbriquées ne laisse pas un peu à désirer. Il n'a pas d'extensibilité infinie, ce n'est qu'une technique d'avoir un singleton choisir sa propre implémentation au moment de l'exécution.
de manière réaliste, héritariting d'un singleton ne fait pas tout ce qui va de sens, car une partie du modèle singleton est une gestion des instances, et une fois que vous avez déjà une instance physique d'un type de base, il est trop tard pour remplacer l'un de là le type dérivé. Même si vous le pouviez, je soupçonne que cela pourrait conduire à une conception difficile à comprendre et encore plus difficile à tester / gérer.
Vous pouvez hériter de singleton et de "réutilisation" ou de réglage fin à l'aide de modèles (C ++) ou de génériques (C # .NET).
J'ai posté dans mon blog ( www.devartplus.com ) une série de postes à ce sujet:
1) Héritage de base singleton en C # .NET
2) Héritage Singleton Singleton de thread en C # .NET
3) Plusieurs implémentations singleton en C ++
Vous êtes invité à visiter ces liens et à partager avec toutes vos opinions. Bonne chance.
Il existe plusieurs solutions qui utilisent des classes et une réflexion intérieures (certaines d'entre elles sont mentionnées dans d'autres réponses). Cependant, je crois que toutes ces solutions impliquent un couplage étroit entre les clients et les classes dérivées.
Voici un moyen qui permet aux clients de ne dépendre que sur la classe de base et est ouvert à l'extension.
Le La classe de base est similaire à la mise en œuvre habituelle, sauf que nous le définis comme une classe abstraite (s'il est légitime d'instancier la classe de base, vous pouvez également le définir comme si vous voulez un singleton régulier) Un sous-type aurait sa propre méthode theinstance (vous ne pouvez pas remplacer une méthode statique). Par exemple: dans la classe principale que vous écririez chien.TheInstance () et tout client ultérieur appellerait animal.theinstance ( ) . De cette façon, les clients peuvent être totalement indépendants des classes dérivées et vous pouvez ajouter de nouvelles sous-classes sans avoir à recompiler les clients (principe fermé ouvert).