Factory Method Design Pattern

Ich konnte kürzlich das Factory Method Pattern schön im Kontext der Web/SharePoint Entwicklung einsetzen, als eine Klasse ihre SPWeb Abhängigkeit per Constructor Injection reingereicht bekommen sollte. Hier die zwei Samples dazu:

   1: public class Sample1

   2: {

   3:     private SPWeb _web;

   4:     public Sample1(SPWeb web)

   5:     {

   6:         _web = web;

   7:     }

   8: }

   9:  

  10: public class Sample2

  11: {

  12:     private Func<SPWeb> _web;

  13:     public Sample1(Func<SPWeb> webFactory)

  14:     {

  15:         _web = webFactory;

  16:     }

  17: }

Während in Sample1 immer das gleiche Objekt für Aufrufe auf dem SPWeb-Kontext verwendet wird, ist es bei Sample2 so, dass man jedes Mal ein neues SPWeb Objekt erhält und darauf seine Abfragen ausführt.

Das hat in diesem Szenario primär den Vorteil, dass ich in Sample 2 mit Using arbeiten könnte, sodass die Methode, die das SPWeb Objekt verwenden will, sich selbstständig um das disposen kümmern kann. Das ist gerade bei Web/SharePoint Anwendungen wichtig, da Microsoft hier kaum Interfaces anbietet, die man bei UnitTests verwenden kann. Dementsprechend muss man sich eigene Interfaces und Wrapper-Implementierungen bauen, die man mocken kann. Allerdings würde das bedeuten, dass das aufrufende Objekt des Fakes sich um den Lifecycle der Fake-Abhängigkeiten kümmern muss, was sehr lästig ist. Für die konkrete Implementierung sähe das natürlich nicht anders aus…

Auf folgender Seite findet ihr noch eine sinnvolle Anwendungsmöglichkeit: http://www.dofactory.com/Patterns/PatternFactory.aspx#_self2

Wikipedia kann euch weitere Details zu dem Pattern nennen.

Mit Tag(s) versehen: Clean Code, Mocking, UnitTest