Devdiaries

• De Fabriek van patroon
  • Intentie
  • Oplossing
  • Structuur van het Factory Pattern
  • Abstract Factory Pattern
  • Factory Patroon uitvoering in het Voorjaar
  • Factory Patroon populaire use cases in het Spring Framework
• De Bouwer patroon
  • Intentie
  • Oplossing
  • Structuur van de Bouwer Patroon
  • Builder Patroon uitvoering in het Voorjaar
• Het Singleton pattern
  • Intentie
  • Oplossing
  • Structuur van het Singleton Pattern
  • Singleton Patroon voorbeeldige uitvoering in het Voorjaar
  • Singleton Patroon vs Lente Singletons
• Het Prototype patroon
  • Intentie
  • Oplossing
  • Structuur van het Prototype Patroon
  • PrototypePattern uitvoering in het Voorjaar
• Conclusie

Creatieve design patterns gaan met het maken van een object mechanismen, in een poging om objecten aan te maken op een wijze die geschikt is voor de situatie. In dit artikel zal ik de meest populaire patronen in deze categorie beschrijven en hoe de lente ze gebruikt!

het Fabriekspatroon

Spring is op zichzelf al een voorbeeld van de implementatie van het Fabriekspatroon. Het patroon wordt gebruikt in het hele kader. Een van de belangrijkste plaatsen die het gebruikt is de BeanFactory klasse.

Intent

• Factory pattern maakt de bouw van soortgelijke klassen van verschillende typen mogelijk met behulp van een factory method
• Method call maakt het object voor u aan
• gecreëerde objecten zijn instanties van klassen die een interface of subklasse

probleemoplossing

• dankzij Factory Design Pattern hoeft u zich geen zorgen te maken over class construction op meer dan één plaats.
• Hiermee kunt u de interface gebruiken voor herhaalde bewerkingen.
• copy-paste-bugs zijn minder waarschijnlijk.

structuur van het Fabriekspatroon

Ten eerste moet u een gemeenschappelijke interface maken die u gaat gebruiken in objects factory. Dan, je nodig hebt om een klasse die instanties van uw inteface creëert creëren. In die klasse, je moet een methode die servers concrete klassen die u vervolgens uit te voeren vanuit de interface zelf implementeren implementeren. Dus, nogmaals, we hebben een klasse die een methode heeft die instanties van de interface creëert wanneer onder de dekking dat het daadwerkelijk instanties creëert in de concrete klasse.

Abstract Fabriekspatroon

Abstract Fabriekspatroon is een patroon dat sterk lijkt op het Fabriekspatroon. Je kunt zeggen dat het Fabriek van fabrieken. In een notendop zijn er twee belangrijke verschillen tussen het Fabriekspatroon en de abstracte fabriek:

• Abstract Factory design pattern creates Factory
• Factory design pattern creates Products

 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(); } } 

de AbstractFactory klasse is verantwoordelijk voor het maken van verschillende types (in tegenstelling tot het Fabriekspatroon). Zoals u kunt zien in het bovenstaande voorbeeld, kan elk van de fabrieken worden geassocieerd met verschillende objecten binnen dezelfde groep (in dit geval – producten).

Factory Pattern implementation in Spring

laten we eens kijken naar bovenstaande interface:

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

Animal interface heeft verschillende methoden die gemeenschappelijk zijn voor alle dieren (elk dier heeft een type en naam). Dus, nu moet je een nieuwe klasse maken: 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!"); } } }

ik heb @Component annotatie toegevoegd omdat Ik wil dat de lente deze fabriek beheert. Er is één methode (fabrieksmethode) die een dier – createAnimalgeeft. Het is een zeer eenvoudige fabriek die slechts twee soorten dieren (kat, vogel) ondersteunt. Als een ander type wordt verstrekt, zal een uitzondering worden gegooid.

laten we Spring controller maken- 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; } }

ik heb een @PostMapping methode toegevoegd, die we door het @PathVariable type en de naam van het dier zullen gaan. Als antwoord krijgen we het nieuwe dierlijke object gemaakt door de fabriek. Laten we het testen met een postbode: toepassingslogboeken:

zoals u kunt zien, hebben we zojuist een nieuw object gemaakt – een vogel met behulp van onze fabriek.

Factory Pattern populaire use cases in Spring Framework

het Spring framework gebruikt het factory design pattern voor het maken van de objecten door gebruik te maken van twee benaderingen:

• Veer BeanFactory Container (bijv. org.springframework.beans.factory.BeanFactory) – het is de eenvoudigste container in het veer kader dat de basisondersteuning biedt voor DI
• Veer Application context Container (e.g ) – t is een andere container aanwezig in voorjaar container die extra enterprise-specifieke functionaliteit toevoegt, zoals het publiceren van applicatiegebeurtenissen aan de attente event listeners of het laden van berichten uit een eigenschappen bestand.

zoals u kunt zien, is de gehele lente al een voorbeeld implementatie van het Fabriekspatroon (de toepassingscontext van elke toepassing in de lente is slechts een gigantische fabriek)

het Builder-patroon

een ander veel voorkomend creatiepatroon is het Builder-patroon. Het populaire gebruik van bouwer in het voorjaar Resultaatactie. Deze klasse maakt deel uit van de MockMcv – gebruikt voor het testen van webapplicaties.

Intent

• elke methode retourneert de objectreferentie waarvan het wordt aangeroepen.
• er is build() methode die een volledig geconstrueerd object retourneert (gebaseerd op alle tussenliggende aanroepen).

probleemoplossing

• verbetert de leesbaarheid van de code wanneer objectcreatie veel parameters heeft.
• nuttig als sommige of alle paramaters optioneel zijn.

structuur van het Builder-patroon

Ten eerste moet u een basisklasse definiëren met alle args-constructor. Vervolgens moet je een Builder class maken met attributen en setters voor elk argument van de base class. Elke setter moet de bouwer terugbrengen. Vervolgens moet een build() methid worden aangemaakt die het object van de basisklasse construeert en retourneert.

Builder Pattern implementation in het voorjaar

ik begon mijn implementatie met een eenvoudige Java-klasse – 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; } }

er zijn een paar attributen, contructor en automatisch gegenereerde getters. Het is tijd voor de uitvoering van builder patroon! Maak hiervoor de EmployeeBuilder klasse aan met dezelfde velden als de Employee class. Genereer setters – één voor elk van onze velden. Als je setters genereert door IDE, moet je onthouden om het type dat door setter (void) wordt geretourneerd te veranderen naar EmployeeBuilder.

 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); } }

aan het einde gebruik ik de public Employee buildEmployee() methode die de werknemer aanmaakt. Het voordeel van deze oplossing is dat als een van onze velden null Is, null zal worden ingevuld. We hoeven niet echt na te denken over waar de nulls heen gaan. Laten we eens kijken naar de actie. Ik heb BuilderController Spring controller gemaakt die twee eindpunten heeft. De eerste creëert een werknemer met alle velden, de tweede creëert een werknemer zonder e-mail:

 @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(); } }

zoals u waarschijnlijk verwacht, geeft het GET-verzoek op het eerste edpoint:

het tweede eindpunt geeft de werknemer met een null als e-mail:

het Singleton-patroon

Singleton is een patroon dat wordt gebruikt door elke Java-ontwikkelaar die Spring gebruikt. Elke boon is standaard een singleton. Het doel is om de mogelijkheid te bieden om slechts één object van een bepaalde klasse te creëren en er wereldwijde toegang toe te bieden.

Intent

• er is alleen een particuliere constructeur.
• Class stores verwijzing naar de instantie van zichzelf.
• er is getInstance() methode die een referentie van singleton class instance retourneert of een nieuw object construeert indien niet geconstrueerd.

in Singleton patroon wordt Java new Class nooit aangeroepen in de klasse, behalve het geval getInstance. U moet deze methode wikkelen met een aantal vergrendelingsfunctionaliteit om multi-thread veiligheid te garanderen.

probleemoplossing

Singleton kan worden gebruikt in gevallen:

• het maken van objecten is duur.
• de klasse waarin de toepassingsconfiguratie wordt opgeslagen. Vanaf elke locatie in het systeem kunnen we het wijzigen en we willen dat de wijzigingen zichtbaar zijn vanaf elke locatie. Tegelijkertijd kunnen we niet toestaan dat verschillende versies van configuraties in het systeem worden gehandhaafd.
• u moet statische status opslaan voor meerdere delen van de toepassing.
• u moet bepalen wie toegang heeft tot een object (concurrency controlling).

structuur van het Singleton patroon

er zijn vele manieren om een singleton te implementeren, maar ze kunnen allemaal worden teruggebracht tot drie hoofdpunten:

• eerst moet u een privé-constructor maken in uw Singleton-klasse
• vervolgens moet u een instance-handle maken die is opgeslagen in de class
• maak statische getInstance() methode die een gesynchroniseerd blok op het object gebruikt om het veiligheidsrisico van de thread te verminderen.

Singleton patroon voorbeeldige implementatie in het voorjaar

in het volgende voorbeeld zullen we onze eigen Singleton implementeren. Dan zullen we bewijzen dat de veercomponenten standaard singletons zijn. Laten we beginnen met het maken van een paar klassen. De eerste die we gaan maken is Singleton.java klasse die een traditionele singleton zal zijn (beschreven in het vorige punt):

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; } }

Maak nu eenvoudige Spring @Component klasse zonder enige logica:

@Component public class SpringSingleton { }

laten we vervolgens testen of onze singletons ervoor zorgen dat er maar één object wordt gemaakt. Ik gebruikte de JUnit-test (automatisch gegenereerd bij het maken van een Spring Boot project in Spring Initializer):

@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() methode controleert of argumenten dezelfde objecten zijn. Testresultaat: geslaagd-alles was hetzelfde. Zo kun je traditionele singletons of singletons schrijven in het voorjaar.

Singleton patroon vs Spring Singletons

er is nog een ding dat u moet weten. Zoals ik schreef-alle Lentebonen zijn standaard singletons. Dit zijn echter niet dezelfde singletons als de traditionele singletons. Het traditionele Singleton patroon gaat ervan uit dat er slechts één instantie van een bepaalde klasse op de ruimte beheerd door Java classloader. In het voorjaar is er slechts één instantie van Bean voor elke gegeven context (_org.springframework.context.ApplicationContext) instantie. Dus, als je meer dan één context hebt, allemaal beheerd door dezelfde Java classloader, zul je waarschijnlijk meer dan één exemplaar van een boon hebben.

het Prototype patroon

het prototype is een patroon waarvan het doel is om objecten van het bovenliggende object te kopiëren. In het prototype-patroon wordt een nieuw object gecreëerd door een bestaand object te klonen. In Java is de clone() methode een implementatie van dit ontwerppatroon.

Intent

• instantie wordt gekloond tijdens runtime om nieuwe instanties te geven die dezelfde status hebben
• in Java het wordt gedaan met de Cloneable interface/

probleemoplossing

het prototype kan worden gebruikt in gevallen:

• je moet veel instanties van dezelfde of soortgelijke objecten maken, en klonen is efficiënter dan het maken van instanties van objecten met het nieuwe java-trefwoord.
• nuttig voor objecten die thread veilig moeten zijn en de status moeten opslaan (e.g winkelwagentjes-waar u hetzelfde gedrag wilt hebben, maar de afzonderlijke items in de winkelwagen zijn verschillend)

structuur van het Prototype patroon

• Maak een abstracte basisklasse die Cloneable implementeert.
• breid abstracte klasse uit in prototypes.
• overschrijf de clone() methode in die prototypes-voeg het class specific gedrag toe.

Prototypepatternimplementatie in het voorjaar

Ik zal het traditionele Java-prototype niet implementeren. Echter, Ik zal je laten zien hoe je een prototype boon te maken in het voorjaar. Ik creëerde een domme klas: SpringPrototype.java

 public class SpringPrototype { }

In de hoofdtoepasklasse in het voorjaar definieerde ik een nieuw prototype Boon door @Scope op prototype te zetten:

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

JUnit-test:

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

ik injecteerde twee exemplaren van de SpringPrototype klasse met @Autowired. Net als in de Singleton voorbeeld-Ik gebruikte de statische methode van Assert om te controleren of de gemaakte instanties zijn niet hetzelfde. Mijn test is groen. Het is het bewijs dat er twee verschillende instanties van hetzelfde object zijn.

conclusie

ik hoop dat u de post leuk vond. We moeten de belangrijkste creatiepatronen kennen die in de lente worden gebruikt. In de volgende post, zullen we leren over structurele patronen in de lente kader!