Wenn ein Strategy auf ein Singelton trifft .....
Kategorie Allgemein Pattern
Was hat ein Strategy Pattern mit einem Singelton zu tun .....
Eigentlich nichts
...
Was hat ein Strategy Pattern mit einem Singelton zu tun .....
Eigentlich nichts
...
Aber es kann sein, dass in einem Projekt
ein Tech Lead auf die Idee kommt, dass die Anzahl der zu erzeugenden Projekte
reduziert werden soll.
OK, also schaut er im Code, ob irgendwo ein Strategy Pattern implementiert ist, welches durch Klassen die keinen State haben realisiert ist.
Warum, denn wenn ein Strategy Selector existiert, der ungefähr so implementiert ist ->
public static IMyStrategy GetStrategyFor(string classification)
{
if (classification.Equals(Thing1))
{
return new Strategy1();
}
else
{
return new GenericStrategy();
}
}
dann kann man die Erzeugung von Objekten sparen, durch folgende Implementation ->
// probably hidden and in the same package as the code which converts some input
// into the strategy object to use
internal class Strategy1 : IMyStrategy
{
// singleton instance - evaluated when first needed
private static Strategy1 instance = new Strategy1();
// hide the constructor to avoid people making spare ones
private Strategy1() {}
// provide instance getter for Singleton access
public Strategy1 Instance { get { return instance; } }
// implementation of IMyStrategy follows
}
public static IMyStrategy GetStrategyFor(string classification)
{
if (classification.Equals(Thing1))
{
return Strategy1.Instance;
}
else
{
return GenericStrategy.Instance;
}
}
Mein Hinweis, dass der Strategy Selector entscheiden sollte, ob er immer die selbe Instanz zurückreicht oder nicht, wurde philosophisch weg diskutiert ....
Meines Erachtens, sollte nach Seperation of Concerns oder evtl. auch Single Reponsibility die Entscheidung, wie die Strategy erzeugt und im Memory verwaltet wird näher am Selector.
Greetings JJR
OK, also schaut er im Code, ob irgendwo ein Strategy Pattern implementiert ist, welches durch Klassen die keinen State haben realisiert ist.
Warum, denn wenn ein Strategy Selector existiert, der ungefähr so implementiert ist ->
public static IMyStrategy GetStrategyFor(string classification)
{
if (classification.Equals(Thing1))
{
return new Strategy1();
}
else
{
return new GenericStrategy();
}
}
dann kann man die Erzeugung von Objekten sparen, durch folgende Implementation ->
// probably hidden and in the same package as the code which converts some input
// into the strategy object to use
internal class Strategy1 : IMyStrategy
{
// singleton instance - evaluated when first needed
private static Strategy1 instance = new Strategy1();
// hide the constructor to avoid people making spare ones
private Strategy1() {}
// provide instance getter for Singleton access
public Strategy1 Instance { get { return instance; } }
// implementation of IMyStrategy follows
}
public static IMyStrategy GetStrategyFor(string classification)
{
if (classification.Equals(Thing1))
{
return Strategy1.Instance;
}
else
{
return GenericStrategy.Instance;
}
}
Mein Hinweis, dass der Strategy Selector entscheiden sollte, ob er immer die selbe Instanz zurückreicht oder nicht, wurde philosophisch weg diskutiert ....
Meines Erachtens, sollte nach Seperation of Concerns oder evtl. auch Single Reponsibility die Entscheidung, wie die Strategy erzeugt und im Memory verwaltet wird näher am Selector.
Greetings JJR
| Permalink | 
