Laden...

[Design Patterns] Factory Method vs. Simple Factory

Erstellt von Repac3r vor 8 Jahren Letzter Beitrag vor 8 Jahren 1.733 Views
R
Repac3r Themenstarter:in
57 Beiträge seit 2014
vor 8 Jahren
[Design Patterns] Factory Method vs. Simple Factory

Schönen Mittag euch,

derzeit beschäftige ich mich intensiv mit Design Patterns.

Nun hat sich herausgestellt, dass viele Entwickler die "Simple Factory" mit der "Factory Method" verwechseln.

Hier mal kurz zwei Beispiele (Achtung, ich bin unkreativ 😛):

Meine "Entities"


public interface IFruit 
{
	Color Color { get; set; }
	double Weight { get; set; }
	void Eat();
}

public class Apple: IFruit 
{
	public Color Color { get; set; }
	public double Weight { get; set; }
	
	public Apple()
	{
		Color = Color.Red;
		Weigth = 125;
	}
	
	public void Eat()
	{
		//Implementation
	}
}

public class Banana: IFruit 
{
	public Color Color { get; set; }
	public double Weight { get; set; }
	
	public Apple()
	{
		Color = Color.Yellow;
		Weigth = 200;
	}
	
	public void Eat()
	{
		//Implementation
	}
}

Simple Factory


public class FruitFactory 
{
	public static IFruit Create(FruitType type)
	{
		switch(type)
		{
			case FruitType.Apple:
				return new Apple();
			case FruitType.Banana:
				return new Banana();
			default:
				return null;
		}
	}
}

Method Factory


public abstract class FruitFactory 
{
	public IFruit Create()
	{
		var fruit = CreateFruit();
		
		//Mache irgendwas mit dem Objekt, ist aber nicht zwingend...
		fruit.Eat();
		
		return fruit;
	}

	protected abstract IFruit CreateFruit();
}

public class AppleFactory: FruitFactory
{
	protected override IFruit CreateFruit()
	{
		return new Apple();
	}
}

public class BananaFactory: FruitFactory
{
	protected override IFruit CreateFruit()
	{
		return new Banana();
	}
}

So, nun zu meiner Frage:

Wo genau liegt denn der Vorteil bei der Factory Method. Laut meinen Recherchen wird die Factory Method ziemlich oft verwendet.
Für mich ist diese jedoch von der Benutzung her, aufwendiger als die Simple Factory.

Bei der Simple Factory übergebe ich einfach meinen Typ, habe mein konkretes Objekt, fertig.
Bei der Factory Method jedoch, muss ich erst eine konkrete Factory(Apple/Banana-Factory) einer Basis-Factory(Fruit Factory) zuweisen und kann nicht elegant mit einem Enum meine gewünschte konkrete Frucht bekommen.

Soweit ich das verstanden habe, gibt es folgende Vorteile der Factory Method:*Ich entkoppel die Klienten(Aufrufer der Factory) von einer konkreten Implementierung *Die Basis-Factory selbst kennt ebenfalls keine konkrete Typen *Ich kann neue Features hinzufügen, ohne bestehenden Quellcode zu verändern (Stichwort Open/Closed Principle, was meiner Meinung nach, die Simple Factory eben nicht kann)

6.911 Beiträge seit 2009
vor 8 Jahren

Hallo Repac3r,

Wo genau liegt denn der Vorteil bei der Factory Method.

Die Antwort(en) dazu hast du dir am Ende des Beitrags selbst gegeben. Das sind -- wenns um entkoppelte Systeme geht -- schon super Vorteile.

Hinzu kommt dass es u.U. leichter zu testen ist, da die konkrete Factory auch durch einen Mock ersetzt werden kann.

BTW: das fruit.Eat(); sollte nicht in Create stehen, wegen dem Single Responsibility Principle. D.h. Create soll das Objekt nur erstellen (und ggf. noch initialisieren) aber sonst nix.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

A
764 Beiträge seit 2007
vor 8 Jahren

Hallo Repac3r,

ein wirklicher Nutzen des Factory Method-Patterns ist bei so einem Minimalbeispiel natürlich schwer zu sehen. In der Praxis würde man sich für so einfache Fälle dann unter umständen tatsächlich für eine 'Simple Factory' entscheiden.

Wenn das ganze dann komplexer wird und eventuell sogar automatisch getestet werde soll, wird der Nutzen anschaulicher.

Gruß, Alf

2.207 Beiträge seit 2011
vor 8 Jahren

Hallo Repac3r,

mal ganz allgemein: Das Factory-Pattern ist manchmal auch so ein Kanonen-Spatzen-Ding. Es kann durchaus Sinn machen, absolut. Aber man sollte sich auch mal fragen, ob der Konstruktor für sowas nicht vielleicht ausreichend ist. Dafür ist er ja da. Da muss man halt immer schauen und abwägen.

Gruss

Coffeebean

P
1.090 Beiträge seit 2011
vor 8 Jahren

Die Abstrakte Factory, dient ja nicht dazu das Produkt auszutauschen, sondern die Herstellungsart (Factory selber). Bei deinen Beispiel könnte es z.B. noch eine OkoFruitFactory und ChemieFruitFactory geben. Die würden dann beide Äpfel und Bananen produzieren, nur auf andere Art.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

2.078 Beiträge seit 2012
vor 8 Jahren

Um ein Beispiel zu nennen, wo ich die Factory-Klasse (oder als Interface) sehr nützlich finde:

Das Dependency-Injection-Pattern bei z.B. Datenbanken.
Ich habe dann ein Interface, das eine Create-Methode enthält, die z.B. den Connection-String bekommt. Die Datenbank- oder Mock-Implementierung baut dann die Datenbank-Verbindung auf und gibt sie zurück.
Wie diese Verbindung aufgebaut wird, kann sich ändern, besonders beim Mocken ist es völlig verschieden. Aus dem Grund ist eine solche Factory in diesem Anwendungsfall notwendig.

R
Repac3r Themenstarter:in
57 Beiträge seit 2014
vor 8 Jahren

Schönen Morgen euch,

vielen Dank für die ganzen Anregungen. Eure Tipps werde ich das nächste mal beachten.
Doch wann eine Simple Factory und wann eine Factory Method angebracht ist, habe ich erst durch From No Factory to Factory Method richtig verstanden.

Grüße