Devdiaries

• a gyári minta
  • szándék
  • Probléma Megoldás
  • a gyári minta szerkezete
  • absztrakt gyári Minta
  • gyári minta végrehajtása tavasszal
  • gyári Minta népszerű használata esetek a tavaszi keretben
• az építő minta
  • szándék
  • problémamegoldás
  • az építő minta felépítése
  • az építő minta végrehajtása tavasszal
• a szingulett minta
  • szándék
  • problémamegoldás
  • a szingulett minta felépítése
  • szingulett Minta példaértékű megvalósítás tavasszal
  • szingulett Minta vs tavaszi Szingulettek
• a prototípus minta
  • szándék
  • Probléma Megoldás
  • a prototípus minta szerkezete
  • Prototípuspattern végrehajtása tavasszal
• következtetés

a kreatív tervezési minták objektum-létrehozási mechanizmusokkal foglalkoznak, megpróbálva objektumokat létrehozni a helyzetnek megfelelő módon. Ebben a cikkben leírom a kategória legnépszerűbb mintáit és azt, hogy a tavasz hogyan használja őket!

a gyári minta

a tavasz önmagában már a gyári minta megvalósításának példája. A mintát az egész keretben használják. Az egyik elsődleges hely, amelyet használnak, a BeanFactory osztály.

Intent

• gyári minta lehetővé teszi a különböző típusú hasonló osztályok felépítését gyári módszerrel
• Módszerhívás létrehozza az objektumot az Ön számára
• a létrehozott objektumok olyan osztályok példányai, amelyek interfészt vagy alosztályt osztanak meg

problémamegoldás

• a gyári tervezési mintának köszönhetően nem kell aggódnia az Osztályépítés miatt egynél több helyen.
• lehetővé teszi az interfész kihasználását az ismétlődő műveletekhez.
• a Copy-paste hibák kevésbé valószínűek.

a gyári minta felépítése

először is létre kell hoznia egy közös felületet, amelyet az objektumok gyárában fog használni. Ezután létre kell hoznia egy osztályt, amely létrehozza az inteface példányait. Ebben az osztályban olyan módszert kell megvalósítania, amely konkrét osztályokat szolgál fel, amelyeket aztán maga a felület fog végrehajtani. Tehát ismét van egy osztályunk, amelynek van egy módszere, amely létrehozza az interfész példányait, amikor a lefedettség alatt valójában példányokat hoz létre a konkrét osztályban.

absztrakt gyári Minta

az absztrakt gyári minta nagyon hasonló a gyári mintához. Azt lehet mondani, hogy ez a gyár a gyárak. Dióhéjban két fő különbség van a gyári minta és az absztrakt gyár között:

• absztrakt gyári tervezési minta gyárat hoz létre
• gyári tervezési minta termékeket hoz létre

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

a AbstractFactory osztály felelős több különböző típus létrehozásáért (ellentétben a gyári mintával). Amint a fenti példában látható, az egyes gyárak ugyanazon csoporton belüli különböző objektumokhoz (ebben az esetben – termékekhez) társíthatók.

gyári minta végrehajtása tavasszal

vessünk egy pillantást a fenti interfészre:

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

Animal interface számos módszer, amelyek közösek az összes állat (minden állatnak van egy típusa és neve). Tehát most létre kell hoznia egy új osztályt: 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!"); } } }

hozzáadtam a @Component megjegyzést, mert azt akarom, hogy a tavasz kezelje ezt a gyárat. Van egy módszer (gyári módszer), amely visszaadja az állatot – createAnimal. Ez egy nagyon egyszerű gyár, amely csak kétféle állatot támogat (macska, madár). Ha egy másik típus van megadva, kivétel kerül dobásra.

hozzunk létre rugós vezérlőt – 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; } }

hozzáadtam egy @PostMapping módszert, amelyet az állat @PathVariable típusán és nevén fogunk átmenni. Válaszul megkapjuk a gyár által létrehozott új állatobjektumot. Teszteljük postás segítségével: alkalmazás naplók:

mint látható, most hoztunk létre egy új objektum – egy madár segítségével a gyár.

gyári Minta népszerű felhasználási esetek a tavaszi keretben

a tavaszi keret a gyári tervezési mintát használja az objektumok létrehozásához két megközelítés alkalmazásával:

• Spring BeanFactory Container (pl org.springframework.beans.factory.BeanFactory) – ez a legegyszerűbb konténer a tavaszi keretben, amely alapvető támogatást nyújt a DI
• Spring ApplicationContext Container (e.g ) – a t egy másik tároló, amely a spring containerben található, amely további vállalati specifikus funkciókat ad hozzá, például alkalmazásesemények közzététele a figyelmes eseményfigyelőknek vagy üzenetek betöltése egy tulajdonságfájlból.

mint látható, a teljes tavasz már a gyári minta megvalósításának példája (bármely tavaszi alkalmazás alkalmazási környezete csak egy óriási gyár)

az építő minta

egy másik általános alkotási minta az építő minta. Ennek eredményeként az építő népszerű használata tavasszal Történikakció. Ez az osztály része a MockMcv – tesztelésére használt webes alkalmazások.

Intent

• minden metódus visszaadja az objektum hivatkozást, ahonnan hívják.
• van build() módszer, amely egy teljesen felépített objektumot ad vissza (az összes közbenső hívás alapján).

problémamegoldás

• javítja a kód olvashatóságát, ha az objektum létrehozása sok paraméterrel rendelkezik.
• hasznos, ha néhány vagy az összes paraméter opcionális.

a Builder minta felépítése

először meg kell határoznia egy alaposztályt az összes args konstruktorral. Ezután létre kell hoznia egy Builder osztályt attribútumokkal és beállítókkal az alaposztály minden argumentumához. Minden szetternek vissza kell adnia az építőt. Ezután létre kell hozni egy build() metidet, amely felépíti és visszaadja az alaposztály objektumát.

Builder Pattern implementáció tavasszal

a implementációmat egy egyszerű Java osztály segítségével kezdtem – 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; } }

van egy pár attribútumok, contructor és automatikusan generált getter. Itt az ideje a builder pattern megvalósításának! Ehhez hozza létre a EmployeeBuilder osztályt ugyanazokkal a mezőkkel, mint az alkalmazott osztály. Létrehoz szetterek-egy minden a mi területeken. Ha létrehoz szetterek IDE, meg kell emlékezni, hogy módosítsa a típus által visszaadott szetter (void) A 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); } }

a végén a public Employee buildEmployee() módszert használom, amely létrehozza az alkalmazottat. Ennek a megoldásnak az az előnye, hogy ha bármelyik mezőnk null, akkor null lesz kitöltve. Nem igazán kell gondolkodnunk azon, hogy hova kerülnek a nullák. Vessünk egy pillantást a cselekvésre. Létrehoztam a BuilderController rugós vezérlőt, amelynek két végpontja van. Az első létrehoz egy alkalmazottat minden mezővel, a második létrehoz egy alkalmazottat e-mail nélkül:

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

ahogy valószínűleg várható, a GET kérés az első edpoint visszatér:

a második végpont visszaadja az alkalmazott egy null, mint egy e-mail:

a Singleton minta

Singleton egy minta által használt minden Java fejlesztő, aki használja Spring. Minden bab alapértelmezés szerint szingulett. Célja, hogy lehetőséget biztosítson egy adott osztály egyetlen objektumának létrehozására, és globális hozzáférést biztosítson hozzá.

szándék

• csak egy privát konstruktor van.
• osztály tárolja a hivatkozást a példányára.
• van getInstance () metódus, amely visszaadja a hivatkozás singleton osztály például vagy konstrukciók új objektum, ha nem konstruált.

a Singleton pattern, Java new Class soha nem hívják az osztály, kivéve getInstance esetben. A többszálú biztonság biztosítása érdekében ezt a módszert néhány reteszelő funkcióval be kell csomagolni.

problémamegoldás

a Singleton az alábbi esetekben használható:

• az objektum létrehozása drága.
• az osztály, amely tárolja az alkalmazás konfigurációját. A rendszer bármely pontjáról módosíthatjuk, és azt akarjuk, hogy a változások bárhonnan láthatóak legyenek. Ugyanakkor nem engedhetjük meg a konfigurációk különböző verzióinak fenntartását a rendszerben.
• az alkalmazás több részének statikus állapotát kell tárolnia.
• szabályoznia kell, hogy ki férhet hozzá egy objektumhoz (konkurencia vezérlés).

a szingulett minta felépítése

a szingulett megvalósításának számos módja van, de mindegyik három fő pontra csökkenthető:

• először létre kell hoznia egy privát konstruktort a
• Singleton osztályban, majd hozzon létre egy példányfogantyút, amely a
• create static getInstance() metódusban van tárolva, amely szinkronizált blokkot használ az objektumon a szálbiztonsági kockázat csökkentése érdekében.

Singleton Minta példaértékű megvalósítás tavasszal

a következő példában saját Singletont hajtunk végre. Ezután bebizonyítjuk, hogy a Rugóelemek alapértelmezés szerint szingulettek. Kezdjük egy pár osztály létrehozásával. Az első, amelyet létrehozunk, a Singleton.java osztály, amely hagyományos szingulett lesz (az előző pontban leírtak szerint):

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

most hozzon létre Egyszerű Tavaszi @Component osztályt logika nélkül:

@Component public class SpringSingleton { }

következő, teszteljük, hogy a szinglik biztosítják-e, hogy csak egy objektum jöjjön létre. Régebben a JUnit teszt (automatikusan generált létrehozásakor tavaszi Boot projekt 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() a módszer ellenőrzi, hogy az argumentumok ugyanazok-e. Teszt eredmény: telt el-minden ugyanaz volt. Így írhat hagyományos szinguletteket vagy szinguletteket tavasszal.

Singleton Pattern vs Spring Singletons

van még egy dolog, amit tudnod kell. Mint írtam-az összes tavaszi bab alapértelmezés szerint szingulett. Ezek azonban nem ugyanazok a szingulettek, mint a hagyományos szingulettek. A hagyományos Singleton minta feltételezi, hogy egy adott osztálynak csak egy példánya van a Java classloader által kezelt térben. Tavasszal minden adott kontextushoz csak egy Bean példány van (_org.springframework.context.ApplicationContext) példány. Tehát, ha több mint egy kontextusod van, mindegyiket ugyanaz a Java classloader kezeli, akkor valószínűleg egynél több példánya lesz egy babnak.

a prototípus minta

a prototípus olyan minta, amelynek célja objektumok másolása a szülőobjektumból. A prototípus mintában egy új objektum jön létre egy meglévő objektum klónozásával. A Java-ban a clone() módszer ennek a tervezési mintának a megvalósítása.

Intent

• a példány futásidőben klónozódik, hogy új példányokat kapjon, amelyek ugyanolyan állapotban vannak
• a Java-ban ez a Cloneable interfésszel történik/

Probléma Megoldás

a prototípus az alábbi esetekben használható:

• sok példányt kell létrehozni azonos vagy hasonló objektumokból, és a klónozás hatékonyabb, mint az objektumok példányainak létrehozása az új Java kulcsszóval.
• hasznos olyan objektumoknál, amelyeknek menetes biztonságosnak kell lenniük, és tárolniuk kell az állapotot (pl.g bevásárlókocsik – ahol ugyanazt a viselkedést szeretné, de a kosárban lévő egyes elemek eltérőek)

a prototípus minta felépítése

• hozzon létre egy absztrakt alaposztályt, amely végrehajtja a klónozható.
• absztrakt osztály kiterjesztése prototípus példányokban.
• felülbírálja a clone() módszert azokban a prototípus példányokban – adja hozzá az osztályspecifikus viselkedést.

Prototípuspattern implementáció tavasszal

nem fogom végrehajtani a hagyományos Java prototípust. Megmutatom azonban, hogyan lehet tavasszal létrehozni egy prototípus babot. Létrehoztam egy buta osztályt: SpringPrototype.java

 public class SpringPrototype { }

a tavaszi fő alkalmazási osztályban definiáltam egy új prototípus babot a @Scope beállításával a prototípushoz:

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

JUnit teszt:

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

a SpringPrototype osztály két példányát injektáltam @Autowired – vel. Csakúgy, mint a Singleton példában – az Assert statikus módszerét használtam annak ellenőrzésére, hogy a létrehozott példányok nem azonosak-e. A tesztem zöld. Ez bizonyítja, hogy ugyanannak az objektumnak két különböző példánya van.

következtetés

remélem tetszett a bejegyzés. Ismernünk kell a tavasszal használt legfontosabb alkotási mintákat. A következő bejegyzésben megismerjük a tavaszi keret szerkezeti mintáit!