Deviaries

• The Factory pattern
  • intention
  • Problem Solution
  • Structure of the Factory Pattern
  • Factory Pattern implementation in Spring
  • Factory Pattern implementation in Spring
  • Factory Pattern popular use kevään kehysriihet
• Rakentajakuvio
  • intentio
  • Ongelmaratkaisu
  • Rakentajakuvion rakenne
  • Rakentajakuvion toteutus keväällä
• Singletonin kuvio
  • Intent
  • Problem Solution
  • Structure of the Singleton Pattern
  • Singleton Pattern esimerkillinen toteutus keväällä
  • Singleton Pattern vs Spring Singletons
• Prototyyppikuvio
  • intentio
  • ongelmanratkaisu
  • Prototyyppikuvion rakenne
  • Prototyyppipatterin toteutus keväällä
• johtopäätös

Kreationaaliset suunnittelukuviot käsittelevät objektin luomismekanismeja, yrittäen luoda objekteja tilanteeseen sopivalla tavalla. Tässä artikkelissa kuvailen Tämän kategorian suosituimpia kuvioita ja miten kevät käyttää niitä!

Tehdaskuvio

kevät on jo itsessään esimerkki Tehdaskuvion toteuttamisesta. Kaavaa käytetään koko kehyksessä. Yksi sen ensisijaisista paikoista on BeanFactory – Luokka.

Intent

• Tehdaskuvio mahdollistaa samantyyppisten luokkien rakentamisen tehdasmenetelmällä
• Menetelmäkutsu luo objektin sinulle
• luodut objektit ovat instansseja luokista, jotka jakavat rajapinnan tai alaluokan

ongelmanratkaisu

• tehtaan suunnittelukuvion ansiosta sinun ei tarvitse huolehtia Luokkarakentamisesta useammassa kuin yhdessä paikassa.
• sen avulla voit hyödyntää rajapintaa toistuviin operaatioihin.
• Copy-paste-virheet ovat epätodennäköisempiä.

Tehdaskuvion rakenne

ensin on luotava yhteinen rajapinta, jota aiotaan käyttää objects Factoryssa. Sitten, sinun täytyy luoda luokka, joka luo esimerkkejä Oman inteface. Kyseisessä luokassa, sinun täytyy toteuttaa menetelmä, joka palvelee konkreettisia luokkia, jotka sitten toteuttaa käyttöliittymän itse. Niin, jälleen, meillä on luokka, joka on menetelmä, joka luo esiintymiä käyttöliittymän kun alle kattavuus, että se todella luo esiintymiä konkreettisen luokan.

Abstrakti Tehdaskuvio

Abstrakti Tehdaskuvio on hyvin samankaltainen kuvio kuin Tehdaskuvio. Voi sanoa, että se on tehtaiden tehdas. Pähkinänkuoressa Tehdaskuvion ja abstraktin tehtaan välillä on kaksi pääeroa:

• Abstrakti tehtaan suunnittelukuvio luo tehtaan
• tehtaan suunnittelukuvio luo tuotteita

 public abstract class AbstractFactory { public abstract Product1Base CreateProduct1(); public abstract Product2Base CreateProduct2(); } class ConcreteFactory1 extends AbstractFactory{ @Override public Product1Base CreateProduct1() { return new ConcreteProduct1(); } @Override public Product2Base CreateProduct2() { return new ConcreteProduct2(); } } class ConcreteFactory2 extends AbstractFactory{ @Override public Product1Base CreateProduct1() { return new ConcreteAnotherProduct1(); } @Override public Product2Base CreateProduct2() { return new ConcreteAnotherProduct2(); } } 

AbstractFactory – luokka on vastuussa useiden eri tyyppien luomisesta (Tehdaskuviosta poiketen). Kuten näet yllä olevassa esimerkissä, jokainen tehtaista voidaan liittää eri esineitä samassa ryhmässä (tässä tapauksessa – tuotteet).

Tehdaskuvion toteutus keväällä

Katsotaanpa yllä olevaa rajapintaa:

 public interface Animal { void setName(String name); String getName(); String getType(); void makeASound(); }

Animal interface on useita menetelmiä, jotka ovat yhteisiä kaikille eläimille (jokaisella eläimellä on tyyppi ja nimi). Joten, nyt sinun täytyy luoda uusi luokka: AnimalFactory

 @Component public class AnimalFactory { public Animal createAnimal(String type) { switch (type) { case "bird": return new Bird(); case "cat": return new Cat(); default: throw new UnsupportedOperationException("Unsupported animal type!"); } } }

lisäsin @Component huomautuksen, koska haluan kevään hallitsevan tätä tehdasta. On olemassa yksi menetelmä (tehdasmenetelmä), joka palauttaa eläimen – createAnimal. Se on hyvin yksinkertainen tehdas, joka tukee vain kahdenlaisia eläimiä (kissa, lintu). Jos tarjolla on toinen tyyppi, heitetään poikkeus.

Let ’ s create Spring controller – FactoryController:

 @RestController @RequestMapping("/") public class FactoryController { private AnimalFactory factory; @Autowired public FactoryController(AnimalFactory factory) { this.factory = factory; } @PostMapping("addAminal/{type}/{name}") public Animal addAnimal(@PathVariable String type, @PathVariable String name) { Animal animal = this.factory.createAnimal(type); animal.setName(name); animal.makeASound(); return animal; } }

lisäsin yhden @PostMapping – menetelmän, jonka käymme läpi @PathVariable – tyypin ja eläimen nimen. Vastaukseksi saamme tehtaan luoman uuden eläinesineen. Kokeillaan sitä postinkantajalla: sovelluslokit:

kuten näette, olemme juuri luoneet uuden esineen – linnun tehtaallamme.

Tehdaskuviot suosittuja käyttötapauksia Jousikehyksessä

Jousikehyksessä käytetään tehtaan suunnittelukuviota esineiden luomiseen kahdella tavalla:

• keväinen BeanFactory Container (e.g org.springframework.beans.factory.BeanFactory) – se on keväisen kehyksen yksinkertaisin kontti, joka tarjoaa perustuen DI
• Keväthakemuksen kontille (e.g )-t on toinen Spring containerissa oleva kontti, joka lisää yrityskohtaisia lisätoimintoja, kuten sovellustapahtumien julkaisemista tarkkaavaisille tapahtuman kuuntelijoille tai viestien lataamista ominaisuustiedostosta.

kuten huomaatte, koko kevät on jo Esimerkkitoteutus Tehdaskuviosta (minkä tahansa Kevätsovelluksen sovelluskonteksti on vain jättitehdas)

Rakentajakuvio

toinen yleinen luomistyökuvio on Rakentajakuvio. Suosittu käyttö rakentaja keväällä on ResultAction. Tämä luokka on osa verkkosovellusten testaukseen käytettävää MockMcv – luokkaa.

Intent

• jokainen menetelmä palauttaa objektiviittauksen, josta sitä kutsutaan.
• on olemassa build() menetelmä, joka palauttaa täysin rakennetun kohteen (perustuu kaikkiin välikutsuihin).

ongelmanratkaisu

• parantaa koodin luettavuutta, kun olioiden luomisessa on monia parametreja.
• hyödyllinen, kun jotkut tai kaikki paramitterit ovat valinnaisia.

Rakentajakuvion rakenne

ensin on määriteltävä perusluokka, jossa on kaikki args-rakentajat. Sitten, sinun täytyy luoda rakentaja Luokka attribuutteja ja setterit jokaiselle argumentti perusluokan. Jokaisen setterin pitäisi palauttaa rakentaja. Sitten on luotava build() methid, joka rakentaa ja palauttaa perusluokan objektin.

Rakentajakuvion toteutus keväällä

aloitin toteutuksen yksinkertaisella Java-luokalla – Employee.java:

 public class Employee { private String firstName; private String lastName; private String employeeId; private String email; public Employee(String firstName, String lastName, String employeeId, String email) { this.firstName = firstName; this.lastName = lastName; this.employeeId = employeeId; this.email = email; } public Employee() { } public String getFirstName() { return firstName; } public String getLastName() { return lastName; } public String getEmployeeId() { return employeeId; } public String getEmail() { return email; } }

on olemassa pari attribuutteja, contructor ja auto-generated getters. On aika toteuttaa rakentaja kuvio! Tätä varten luodaan EmployeeBuilder – luokka, jossa on samat kentät kuin Työntekijäluokassa. Luo setterit – yksi jokaiselle alallemme. Jos luot setters by IDE, sinun täytyy muistaa muuttaa tyyppi palautetaan setter (void) palkata Builder.

 public class EmployeeBuilder { private String firstName; private String lastName; private String employeeId; private String email; // Each setter returns EmployeBuilder object. public EmployeeBuilder setFirstName(String firstName) { this.firstName = firstName; return this; } public EmployeeBuilder setLastName(String lastName) { this.lastName = lastName; return this; } public EmployeeBuilder setEmployeeId(String employeeId) { this.employeeId = employeeId; return this; } public EmployeeBuilder setEmail(String email) { this.email = email; return this; } public Employee buildEmployee() { return new Employee(firstName,lastName, employeeId, email); } }

lopussa käytän public Employee buildEmployee() – menetelmää, joka luo työntekijän. Tämän ratkaisun etuna on se, että jos jokin kentistämme on nolla, nollista tulee asuttu. Ei tarvitse miettiä, mihin nullit menevät. Katsotaanpa toimintaa. Loin BuilderController Jousiohjaimen, jolla on kaksi päätepistettä. Ensimmäinen luo työntekijän kaikilla kentillä, toinen luo työntekijän ilman sähköpostia:

 @RestController @RequestMapping("/builder") public class BuilderController { @GetMapping("employee1") public Employee getEmployee1() { return new EmployeeBuilder() .setEmployeeId("1234") .setEmail("[email protected]") .setFirstName("John") .setLastName("smith") .buildEmployee(); } @GetMapping("employee2") public Employee getEmployee2() { return new EmployeeBuilder() .setEmployeeId("4321") .setFirstName("Jeff") .setLastName("Freeman") .buildEmployee(); } }

kuten arvata saattaa, ensimmäisen edpointin GET-pyyntö palauttaa:

toinen päätepiste palauttaa työntekijän nollilla sähköpostina:

Singleton-kuvio

Singleton on jokaisen jousta käyttävän Java-kehittäjän käyttämä kuvio. Jokainen papu on oletusarvoisesti singleton. Sen tarkoituksena on tarjota mahdollisuus luoda vain yksi tietyn luokan objekti ja tarjota maailmanlaajuinen pääsy siihen.

Intent

• on vain yksityinen rakentaja.
• Luokkavarastot viittaavat itse instanssiin.
• on olemassa getInstance () – menetelmä, jossa palautetaan viittaus singleton-luokan instanssiin tai konstruoidaan uusi objekti, jos sitä ei konstruoida.

Singleton-kuviossa Javaa new Class ei koskaan kutsuta luokkaan getInstance-tapausta lukuun ottamatta. Sinun pitäisi kääri tämä menetelmä joitakin lukitustoimintoja varmistaa multi-kierre turvallisuus.

Ongelmaratkaisu

Singletonia voidaan käyttää tapauksissa:

• esineiden luominen on kallista.
• sovelluskokoonpanon tallentava Luokka. Mistä tahansa järjestelmästä voimme muokata sitä ja haluamme, että muutokset näkyvät mistä tahansa. Samalla emme voi sallia eri kokoonpanojen versioiden ylläpitämistä järjestelmässä.
• sinun on tallennettava staattinen tila usealle sovelluksen osalle.
• sinun täytyy kontrolloida, kenellä on pääsy objektiin (samanaikainen kontrollointi).

Singletonin kuvion rakenne

on monia tapoja toteuttaa singleton, mutta kaikki voidaan pelkistää kolmeen pääkohtaan:

• ensin sinun täytyy luoda yksityinen rakentaja Singleton-luokassasi
• sitten Luo instanssikahva, joka on tallennettu luokkaan
• luo staattinen getInstance() menetelmä, joka käyttää synkronoitua lohkoa kohteeseen langaturvallisuusriskin vähentämiseksi.

Singleton Pattern esimerkillinen toteutus keväällä

seuraavassa esimerkissä toteutetaan oma Singleton. Sitten todistamme, että Jousikomponentit ovat oletusarvoisesti singletoneja. Aloitetaan luomalla pari luokkaa. Ensimmäinen, jonka aiomme luoda, on Singleton.java luokka, joka on perinteinen singleton (kuvattu edellisessä kohdassa):

public class Singleton { private static Singleton instance; private Singleton(){} public static Singleton getInstance() { if(null == instance){ synchronized (Singleton.class){ if(null==instance) { instance = new Singleton(); } } } return instance; } }

luo nyt yksinkertainen jousi @Component Luokka ilman logiikkaa:

@Component public class SpringSingleton { }

seuraavaksi testataan, varmistavatko singletonimme, että vain yksi esine syntyy. Käytin JUnit-testiä (syntyy automaattisesti luotaessa Spring Boot-projektia Spring Initializerissa):

@RunWith(SpringRunner.class) @SpringBootTest public class SpringDesignPatternsApplicationTests { @Autowired SpringSingleton springSingleton1; @Autowired SpringSingleton springSingleton2; @Test public void singletonObjectsShouldBeEquals() { Singleton singleton1 = Singleton.getInstance(); Singleton singleton2 = Singleton.getInstance(); // Checking if the Singleton objects are definitely one, the same object Assert.assertSame(singleton1, singleton2); // Checking if the spring components are definitely singletons Assert.assertSame(springSingleton1, springSingleton2); } }

assertSame() menetelmä tarkistaa, ovatko argumentit samoja objekteja. Testitulos: läpäissyt-kaikki oli sama. Näin keväällä voi kirjoittaa perinteisiä singletoneja tai singletoneja.

Singleton Pattern vs Spring Singletons

on vielä yksi asia, joka sinun pitäisi tietää. Kuten kirjoitin – kaikki Kevätpavut ovat oletuksena singletons. Nämä eivät kuitenkaan ole samoja singletoneja kuin perinteiset singletonit. Perinteinen Singleton-kuvio olettaa, että Java classloaderin hallinnoimassa tilassa on vain yksi tietyn luokan esiintymä. Keväällä papu-esiintymiä on vain yksi kutakin annettua kontekstia (_org.springframework.context.ApplicationContext) kohden. Niin, jos sinulla on enemmän kuin yksi konteksti, kaikki hallinnoi sama Java classloader, sinulla on todennäköisesti enemmän kuin yksi esimerkki papu.

Prototyyppikuvio

prototyyppi on kuvio, jonka tarkoituksena on kopioida esineitä emoobjektista. Prototyyppikuviossa uusi objekti luodaan kloonaamalla olemassa oleva objekti. Javassa clone() – menetelmä on tämän suunnittelukaavan toteutus.

Intent

• instanssi kloonataan ajettaessa antamaan uusia instansseja, joilla on sama tila
• Javassa se tehdään Cloneable – rajapinnalla/

ongelmanratkaisu

prototyyppiä voidaan käyttää tapauksissa:

• sinun täytyy luoda paljon esiintymiä samoja tai samankaltaisia esineitä, ja kloonaus on tehokkaampaa kuin luoda esiintymiä esineitä uudella Java-avainsanalla.
• hyödyllinen esineiden kanssa, joiden on oltava säiettä turvallisia ja jotka on tallennettava tilaan (e.g ostoskärryt – joissa haluat olla sama käyttäytyminen, mutta yksittäiset tavarat ostoskorissa ovat erilaisia)

Prototyyppikuvion rakenne

• luo Abstrakti perusluokka, joka toteuttaa Kloneerisen.
• Laajenna abstraktia luokkaa prototyyppiasteikoissa.
• Ohita clone() – menetelmä näissä prototyyppiasteikoissa-lisää luokkakohtainen käyttäytyminen.

Prototyyppipatterin toteutus keväällä

En toteuta perinteistä Javan prototyyppiä. Kuitenkin, näytän sinulle, miten luoda prototyyppi papu keväällä. Loin yhden typerän luokan.: SpringPrototype.java

 public class SpringPrototype { }

kevään pääsovellusluokassa määrittelin uuden prototyyppipavun asettamalla @Scope prototyyppiin:

 @Bean @Scope("prototype") public SpringPrototype prototype(){ return new SpringPrototype(); }

JUnit-testi:

 @Autowired SpringPrototype prototype1; @Autowired SpringPrototype prototype2; @Test public void prototypeObjectsShouldNotBeEquals() { Assert.assertNotSame(prototype1, prototype2); }

pistin kaksi instanssia SpringPrototype-luokasta @Autowired. Aivan kuten Singletonin esimerkissä – käytin Assertin staattista menetelmää tarkistaakseni, että luodut esiintymät eivät ole samat. Testini on vihreä. Se todistaa, että samasta esineestä on kaksi eri tapausta.

johtopäätös

toivottavasti pidit postauksesta. Kevään tärkeimmät luomiskuviot pitää tuntea. Seuraavassa viestissä kerromme kevään Rakennekuvioista!