Fabrikkmetode



Internett er en uuttømmelig kilde til kunnskap, også når det gjelder Fabrikkmetode. Århundrer og århundrer med menneskelig kunnskap om Fabrikkmetode har blitt strømmet inn i nettverket, og fortsetter å bli strømmet ut, og det er nettopp derfor det er så vanskelig å få tilgang til det, siden vi kan finne steder hvor navigering kan være vanskelig eller direkte upraktisk. Vårt forslag er at du ikke blir forliste i et hav av data som refererer til Fabrikkmetode og at du kan nå alle visdomshavnene raskt og effektivt.

Med sikte på det målet har vi gjort noe som går utover det åpenbare, ved å samle inn den mest oppdaterte og best forklarte informasjonen om Fabrikkmetode. Vi har også ordnet den på en slik måte at lesingen er fornøyelig, med et minimalistisk og behagelig design, som sikrer den beste brukeropplevelsen og kortest lastetid.Vi gjør det enkelt for deg slik at du bare trenger å bekymre deg for å lære alt om Fabrikkmetode! Så hvis du tror vi har oppnådd formålet vårt og du allerede vet hva du ville vite om Fabrikkmetode, vil vi gjerne ha deg tilbake på disse rolige sjøene i sapientiano.com hver gang din hunger etter kunnskap vekkes igjen.

Begrepet fabrikkmetode ( engelsk fabrikkmetode ) refererer til et designmønster innen programvareutvikling . Mønsteret beskriver hvordan et objekt opprettes ved å kalle en metode i stedet for å ringe en konstruktør direkte . Det tilhører derfor kategorien generasjonsmønster (Engl. Creational mønstre ).

Imidlertid kan begrepet fabrikkmetode være misvisende ved at det refererer til to litt forskjellige designmønstre så vel som selve metoden, avhengig av høyttaleren.

Mønsteret er en av de såkalte GoF Design Patterns ( Gang of Four , se Gang of Four ).

Betydningen av begrepet i henhold til GoF

I følge GoF beskriver fabrikkmetoden et mønster der grensesnittet for å lage et objekt er en (abstrakt) metode for en superklasse. Imidlertid finner den konkrete implementeringen av opprettelsen av nye objekter ikke sted i superklassen, men i underklasser avledet fra den, som implementerer nevnte abstrakte metode.

Mønsteret beskriver altså opprettelsen av produktobjekter, hvis spesifikke type er en undertype av en abstrakt produktklasse, som bestemmes av underklasser av en produsentklasse. Det kalles noen ganger "virtuell konstruktør" ( virtuell konstruktør kalt).

Avgrensning

I praksis brukes ofte begrepet fabrikkmetode ganske enkelt for en statisk metode som skaper et nytt objekt, som kan sammenlignes med en konstruktør.

Eksempel: I stedet for

SomeObject o = new SomeObject();

er skrevet ved hjelp av den statiske metoden i daglig tale kjent som fabrikkmetoden:

SomeObject o = SomeObjectFactory.createNewInstance();

I dette tilfellet er ingen bruk av underklasser eller polymorfisme ment (for selve metoden) . Målet er imidlertid vanligvis at det genererte, returnerte objektet (avhengig av miljøet eller .createNewInstance(...)parametrene som er gitt) er fra en underklasse av SomeObject.

Imidlertid er denne bruken av begrepet fabrikkmetode feil i betydningen av Gang of Four .

UML-diagram

Følgende klassediagram viser de fire rollene som er involvert i designmønsteret. KonkreterErzeugerarver den abstrakte fabrikkmetoden fra Erzeugerog implementerer den for å KonkretesProduktgenerere, som igjen Produktimplementerer.

Klassediagram over rollene som er involvert i mønsteret.

skuespillere

Dette Produkter den grunnleggende typen (klasse eller grensesnitt) for produktet som skal opprettes. Den Erzeugererklærer fabrikkmetoden for å lage et slikt produkt og kan inneholde en standardimplementering. Noen ganger spesifiseres en implementering for fabrikkmetoden som skaper et standardprodukt.

KonkretesProduktimplementerer produktgrensesnittet. (Så det er en konkret undertype av produktet). KonkreterErzeugeroverskriver fabrikkmetoden for å generere de spesifikke produktene som tilsvarer den (f.eks. ved å ringe konstruktøren til en bestemt produktklasse).

fordeler

Fabrikkmetoder kobler fra innringere fra implementeringer av spesifikke produktklasser, noe som spesielt betyr at ingen newoperatører brukes i den anropende klassen for instantiering . Dette er spesielt verdifullt når programvarebiblioteker utvikler seg videre i løpet av applikasjonen - dette betyr at forekomster av andre klasser kan opprettes på et senere tidspunkt uten at applikasjonen må endres.

Mange objektorienterte programmeringsspråk dikterer navnet på konstruktøren. Derimot kan en fabrikkmetode (i bredere forstand av begrepet) ha et mer meningsfylt navn, og det kan være flere fabrikkmetoder med forskjellige navn og forskjellig semantikk. For eksempel kan en metode lage Color.createFromRGB()et fargeobjekt fra RGB-verdier , og en metode kan opprette Color.createFromHSV()et fargeobjekt fra HSV-verdier . Dette kunne ikke gjøres med bare to konstruktører fordi metodene har samme signatur .

ulempe

Bruken av dette generasjonsmønsteret utgjør en underklassering. Det må være en egen klasse som kan akseptere klassemetoden for generasjon.

eksempel

Følgende eksempel illustrerer bruken av GoF-mønsteret i et programvarebibliotek for restaurantprogramvare.

En restaurant (produsent) leverer måltider (produkter). Den grunnleggende prosedyren for å levere et måltid er alltid den samme: å bestille, lage et måltid, servere et måltid. Alt dette kan Restaurantimplementeres i klassen , bortsett fra å tilberede måltidet. Forberedelsen (produksjonen) avhenger av restauranttypen: En Pizzeria(spesifikk produsent) lager pizza (spesifikke produkter), en Rostwurstbudelager grillede pølser.

RestaurantFor å gjøre dette implementerer klassen en metode MahlzeitLiefern()som leverer måltidet, inkludert bestillings- og serveringsprosessen. Den bruker en abstrakt metode MahlzeitZubereiten()som forbereder (genererer) det spesifikke måltidet til den spesifikke restauranten. MahlzeitZubereiten()er fabrikkmetoden og må implementeres tilsvarende for hver spesifikke restaurant.

Dette programvarebiblioteket kan brukes til en ny restauranttype med en egen meny med måltider: En ny klasse må hentes fra Mahlzeitog fra Restaurant, hvorved Restaurantmetoden til MahlzeitZubereiten()den avledede klassen må tilberede (generere) måltidet som tilbys i denne restauranten.

#include <iostream>
#include <string>
#include <memory>

// Produkt
class Mahlzeit {
};

// konkretes Produkt
class Pizza : public Mahlzeit {
public:
    Pizza() {
        std::cout << "Pizza gebacken." << std::endl;
    }
};

// noch ein konkretes Produkt
class Rostwurst : public Mahlzeit {
public:
    Rostwurst(const std::string& beilage) {
        std::cout << "Rostwurst gebraten." << std::endl;
        if (!beilage.empty()) {
            std::cout << "Serviert mit " << beilage << std::endl;
        }
    }
};

// Erzeuger
class Restaurant {
protected:
    std::shared_ptr<Mahlzeit> mahlzeit;

    // Die abstrakte Factory-Methode, die von Erzeugern implementiert werden muss.
    virtual void MahlzeitZubereiten() = 0;

    virtual void BestellungAufnehmen() {
        std::cout << "Ihre Bestellung bitte!" << std::endl;
    }

    virtual void MahlzeitServieren() {
        std::cout << "Hier Ihre Mahlzeit. Guten Appetit!" << std::endl;
    }

public:
    // Diese Methode benutzt die Factory-Methode.
    void MahlzeitLiefern() {
        BestellungAufnehmen();
        MahlzeitZubereiten(); // Aufruf der Factory-Methode
        MahlzeitServieren();
    }
};

// konkreter Erzeuger für konkretes Produkt "Pizza"
class Pizzeria : public Restaurant {
protected:
    // Implementierung der abstrakten Methode der Basisklasse
    virtual void MahlzeitZubereiten() {
        mahlzeit = std::make_shared<Pizza>();
    }
};

// konkreter Erzeuger für konkretes Produkt "Rostwurst"
class Rostwurstbude : public Restaurant {
protected:
    // Implementierung der abstrakten Methode der Basisklasse
    virtual void MahlzeitZubereiten() {
        mahlzeit = std::make_shared<Rostwurst>("Pommes und Ketchup");
    }
};

int main() {
    Pizzeria daToni;
    daToni.MahlzeitLiefern();

    Rostwurstbude brunosImbiss;
    brunosImbiss.MahlzeitLiefern();
}

brukstilfeller

Fabrikkmetoden (i GoF-betydningen) brukes når en klasse ikke kan eller ikke skal vite gjenstandene som skal opprettes av den, eller hvis underklasser skal bestemme hvilke objekter som skal opprettes. Typiske brukssaker er rammer og klassebiblioteker . På GRASP representerer fabrikkmetoden en løsning på målene om lav kobling og høy kohesjon.

Virtuell metode i grensesnitt eller klasse

Den virtuelle metoden kan defineres både i grensesnittet eller i klassen (f.eks. Fasade) som ellers er ansvarlig for objekter av en type. Underklasser kan da lage spesifikke typer. Typiske scenarier:

Lag avhengige objekter

Eksempler:

  • Java: java.sql.Connection.createStatement()- den genererte utsagnet refererer til forbindelsen og "bor i den".
  • .NET: System.Data.IDbConnection.CreateCommand()- den genererte IDbCommandrefererer til tilkoblingen og "bor i den".

De avhengige objektene som opprettes har ofte fabrikkmetoder for avhengige objekter, f.eks. B. har IDbCommanden metode CreateParameter(). Derfor kan klasser med slike fabrikkmetoder ikke forstås som "fabrikkklasser" (med hovedansvar "objektoppretting") - i motsetning til den abstrakte fabrikken .

Generering av uavhengige objekter via sentraliserte "indekserte konstruktører"

En metode fra en familie av fabrikkmetoder kalles Dictionarygjennom en ved hjelp av en s Key. Kodebit (med C # delegater i stedet for underklasser - delegattypen representerer Erzeugerhver konkrete anonyme metode KonkretenErzeuger):

delegate IFoo CreateFoo(IContext creationParameter);

static IDictionary<Key, CreateFoo> fooFactory = new Dictionary<Key, CreateFoo>();

// Statische Initialisierung:
fooFactory[key1] = cp => new FooForKey1(cp);
fooFactory[key2] = cp => new FooForKey2Or3(new Key2Child(cp));
fooFactory[key3] = cp => new FooForKey2Or3(new Key3Child(cp));

Anrop:

IFoo newObject = fooFactory[key](someContext);

Tillater en kompakt, beskrivende utforming av gjenstanden. Fare (spesielt hvis - f.eks. I C # - direkte henvisning til funksjonsanrop i ordboken) at fabrikkobjektene tar større ansvar.

"Statisk fabrikkmetode"

Enkel staticmetode som returnerer et objekt av en type eller undertype. Ingen virtuell konstruktør - sans for saken: Sentralt, klassebasert tilgangspunkt for oppretting av objekter analogt med nytt. Noen ganger krever bare innføring av en enkelt klasse som en fabrikkmetodeholder . Eksempler:

  • Java: java.util.Collections.singletonMap()
  • Java: javax.xml.parsers.DocumentBuilderFactory.newInstance()

Relaterte designmønstre

En abstrakt fabrikk implementeres vanligvis ved bruk av fabrikkmetoder.

Fabriksmetoder kalles vanligvis fra malmetoder .

Fabriksmetoder finnes ofte i singler .

weblenker

Opiniones de nuestros usuarios

Steinar Sandnes

For de som meg som leter etter informasjon om Fabrikkmetode, er dette et veldig godt alternativ.

Marit Haugen

Det er en stund siden jeg har sett en artikkel om Fabrikkmetode skrevet på en så didaktisk måte. Jeg liker det.

Nils Skaar

Informasjonen om Fabrikkmetode er veldig interessant og pålitelig, som resten av artiklene jeg har lest så langt, som allerede er mange, fordi jeg har ventet på Tinder-datoen min i nesten en time og den vises ikke, så det gir meg som har reist meg opp. Jeg benytter anledningen til å legge igjen noen stjerner for selskapet og drite på livet mitt.