Nu ik eindelijk serieus begonnen ben met het leren van enkele basispatronen (heel laat in de carrière, maar dat is een ander verhaal), probeer ik mijn kijk rond de verschillen tussen het fabriekspatroon en de abstracte fabriek.

Wat zijn de belangrijkste verschillen tussen deze twee patronen?

Ik begrijp dat de fabrieksmethode objecten creëert door middel van overerving en het door middel van objectcompositie, maar vanuit praktisch oogpunt “heb ik nog steeds moeite om precies te visualiseren hoe ze werken.

Opmerkingen

  • stackoverflow.com/questions/1001767/…
  • Ter verduidelijking: bedoel je " Fabriekspatroon " wanneer u zegt " Fabriekspatroon " Als je het hebt over de Gang of Four-patronen, is er geen fabriekspatroon, maar wel een abstracte factor y en Fabrieksmethode.
  • Ja – Fabrieksmethode.
  • Om eerlijk te zijn, de twee zinnen lijken vrij algemeen te worden verwisseld.
  • Ah, fabrieksmethode. Een oplossing voor het feit dat new geen ' een methode is (in sommige – weliswaar veel voorkomende – objectsystemen).

Antwoord

De Fabrieksmethode wordt meestal gecategoriseerd door een switch-instructie waarbij elk geval een andere klasse retourneert, met dezelfde root-interface, zodat de aanroepende code nooit beslissingen hoeft te nemen over de implementatie.

Denk aan een creditcardvalidatiefabriek die voor elk kaarttype een andere validator retourneert.

public ICardValidator GetCardValidator (string cardType) { switch (cardType.ToLower()) { case "visa": return new VisaCardValidator(); case "mastercard": case "ecmc": return new MastercardValidator(); default: throw new CreditCardTypeException("Do not recognise this type"); } } 

De Abstract Factory is waar je meerdere betonfabrieksklassen hebt (geen fabrieksmethoden) afgeleid van één interface die veel verschillende typen van verschillende methoden kan opleveren.

Denk aan een schaakspelmanager met een andere klasse voor elke set variantregels.

public class StandardChessRulesFactory : IChessRulesFactory { public IBoardMapper GetBoardMapper() { return new StandardChessBoardMapper(); } public IKingMover GetKingMover() { return new StandardChessKingMover(); } public IMoveClock GetMoveClock() { return new StandardMoveClock(); } } public class HexagonalChessRulesFactory : IChessRulesFactory { public IBoardMapper GetBoardMapper() { return new HexagonalChessBoardMapper(); } public IKingMover GetKingMover() { return new HexagonalChessKingMover(); } public IMoveClock GetMoveClock() { return new StandardMoveClock(); } } public class SpeedChessRulesFactory : IChessRulesFactory { public IBoardMapper GetBoardMapper() { return new StandardChessBoardMapper(); } public IKingMover GetKingMover() { return new StandardChessKingMover(); } public IMoveClock GetMoveClock() { return new SpeedChessMoveClock(); } } 

Een abstracte fabriek , net als een strategie, wordt vaak geselecteerd met behulp van een fabrieksmethode, maar het is niet nodig om ze te combineren, dus het is zijn eigen patroon.

Opmerkingen

  • Is die uitleg van de Factory-methode correct? Wat ' s over " Het patroon van de fabrieksmethode is afhankelijk van overerving, aangezien het maken van objecten wordt gedelegeerd naar subklassen die implementeer de fabrieksmethode om objecten te maken ". Dus het voorbeeld lijkt meer op Static Factory.
  • @SerG Nou, eerlijk gezegd heb je ' dat citaat uit Wikipedia gehaald op een pagina die erg anders drie jaar geleden. Ik zou zeggen dat de huidige Wikipedia-pagina zichzelf op verschillende plaatsen tegenspreekt, maar ik heb niet de wens om mee te doen om dat uit elkaar te halen. Wat ik achteraf wil toegeven, is dat het voorbeeld dat ik ' ve hier heb gegeven, een specifiek soort fabrieksmethode is, bekend als de geparameteriseerde fabrieksmethode. Maar het punt over het verschil tussen Factory Method en Abstract Factory geldt voor alle soorten Factory Method.
  • Dezelfde verklaring als mijn quote bestaat in GoF " Design Patterns ". En geparametriseerde FM wordt daar ook beschreven.
  • Het belangrijkste is dat de fabriek de beller een geschikt object geeft, afhankelijk van de specifieke situatie, en de beller niet ' t moet weten wat precies de klasse van dat object is, en ' t hoeft niet te weten hoe het specifieke object is gekozen, zolang het object een interface ondersteunt die de beller weet hiervan.
  • Je moet in je antwoord duidelijk aangeven dat je voorbeeld geen typisch fabrieksmethodepatroon is, maar een specialisatie genaamd geparametriseerde fabrieksmethode. En schrijf over de definitie van een typische fabrieksmethode, omdat deze momenteel misplaatst is. Ik was net aan het leren over het fabrieksmethode-patroon, ik begreep alles en toen las ik dat antwoord dat het fabrieks-methode-patroon als iets anders laat zien en ik was in de war. Er is geen informatie over dat voorbeeld dat geen typisch fabrieksmethodepatroon is. Met dank aan SerG voor het vermelden daarvan in de opmerking.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *