1.1 Bevezetés a mintákba

Amint azt korábban említettük, a programozó a programon való munkát úgy kezdi meg, hogy megtervezi annak modelljét: összeállítja azon entitások listáját, amelyeken a program működni fog. És minél több entitás van a programban, annál összetettebb a program.

Ezért a program bonyolultságának csökkentése érdekében igyekeznek szabványosítani az objektumok interakcióit. És itt a tervezési minták vagy tervezési minták sokat segítenek a programozónak . Angol design mintából .

Fontos! Oroszul a design szó általában grafikai tervezést jelent, angolul ez nem így van. Az angol design szó jelentése közelebb áll a „design” és/vagy „device” szóhoz. Például egy motor kialakítása nem a megjelenése, hanem a belső szerkezete.

Ezért a tervezési minta pontosan egy tervezési minta/minta. Azt javaslom, hogy hagyja abba a design szó „megjelenés” jelentését. Ön a leendő szoftvermérnök, és az Ön számára a tervezés pontosan tervezés.

Tehát mi ez a tervezési minta? Először is, a tervezési minta egy szabványos probléma szabványos megoldása . Jó, hatékony és jól bevált megoldás.

Tegyük fel, hogy felkérték, hogy tervezzen egy kerékpárt, elkészítheti két, három vagy akár ötkerekes is. Így egyébként a tervezés hajnalán az volt. De a jól bevált megközelítés két kerék. De a jelenlegi nyilvánvaló megközelítés fájdalmakon és hibákon ment keresztül:

Jellemzően a sablon nem egy teljes, közvetlenül kóddá alakítható megoldás, csak egy példa egy jó megoldásra egy-egy problémára, amely különféle helyzetekben használható.

Az objektumorientált minták az osztályok vagy objektumok közötti kapcsolatokat és interakciókat mutatják meg anélkül, hogy meghatároznák, mely végső osztályokat vagy alkalmazásobjektumokat használják fel.

1.2 A tervezési minták története

A 70-es években a programozók szembesültek azzal, hogy nagy programokat kell kidolgozniuk, amelyeken egész fejlesztőcsapatoknak kellett dolgozniuk. Különféle munkaszervezési módszereket próbáltak ki, de leginkább az építőipar befolyásolta a fejlődést.

Nagy létszámú embercsoport munkájának megszervezéséhez az építőipar gyakorlatait és megközelítéseit alkalmazták. Egyébként innen kerültek a programozásba olyan kifejezések, mint assembly (build), Software Developer (builder), és az architektúra fogalma.

És ahogy sejthető, a tervezési minta ötletet is az építőiparból vették. A minták fogalmát először Christopher Alexander írta le A mintanyelvben. Városok. Épület. Építkezés". Ebben a könyvben egy speciális nyelvet, mintákat használtak a várostervezés folyamatainak leírására.

Az építési minták tipikus, időtálló döntéseket írnak le: milyen magasak legyenek az ablakok, hány emelet legyen az épületben, mekkora területet kell elkülöníteni a mikrokörzetben a fák és pázsitok számára.

Ezért nem meglepő, hogy 1994-ben „Az objektum-orientált tervezés technikái. Tervezési minták”, amely 23 mintát tartalmaz, amelyek megoldják az objektum-orientált tervezés különféle problémáit.

A könyvet 4 szerző írta: Erich Gamma, Richard Helm, Ralph Johnson és John Vlissides. A könyv címe túl hosszú volt ahhoz, hogy bárki is emlékezzen rá. Ezért hamarosan mindenki „a négytagú banda könyvének”, azaz „négytagú banda könyvének” , majd még „GoF könyvnek” is nevezte .

És azóta más tervezési mintákat fedeztek fel. A „mintázat” megközelítés a programozás minden területén népszerűvé vált, így ma már az objektumtervezésen kívül is mindenféle mintával találkozhatunk.

Fontos! A minták nem valami szuper-eredeti megoldások, hanem éppen ellenkezőleg, gyakran előforduló, tipikus megoldások ugyanarra a problémára. Jó bevált megoldások.

1.3 A minták listája

Sok programozó egész élete során egyetlen mintát sem tanult meg, ami azonban nem akadályozza meg a használatában. Ahogy korábban is mondtuk, a minták jól bevált megoldások, és ha a programozó nem bolond, akkor tapasztalattal ő maga is talál ilyen megoldásokat.

De miért jutunk több tucat próbálkozás és tévedés során az optimális megoldásokhoz, amikor vannak emberek, akik már megjárták ezt az utat, és tapasztalataik és életbölcsességük kvintesszenciájával könyveket írtak?

Kulccsal is lehet szöget verni, de miért? Még fúrót is használhat, ha keményen próbálkozik. De a hangszer jó tudatos birtoklása az, ami megkülönbözteti a profit az amatőrtől. A szakember pedig tudja, hogy a fúrógép fő tulajdonsága egyáltalán nem ebben rejlik. Szóval, miért kell ismerned a mintákat?

  • Bevált megoldások. Kevesebb időt tölt a kész megoldásokkal, ahelyett, hogy újra feltalálná a kereket. Néhány döntésre gondolhatna magad, de sok lehet felfedezés számodra.
  • Kód szabványosítás. Kevesebb tévedést követ el tervezéskor, tipikus egységes megoldásokat használva, hiszen az összes rejtett problémát már rég megtaláltuk.
  • Általános programozási szótár. Kimondod a minta nevét ahelyett, hogy egy órát elmagyaráznál a többi programozónak, milyen klassz dizájnt találtál ki, és milyen osztályokra van szükség ehhez.

Mik a minták?

A minták különböznek a tervezett rendszer bonyolultságától, részletességétől és lefedettségétől. Ha az építkezéssel analógiát vonunk le, egy kereszteződés biztonságát növelhetjük jelzőlámpa kihelyezésével, vagy kicserélhetjük a kereszteződést egy egész autós csomópontra, aluljárókkal.

A legalacsonyabb szintű és legegyszerűbb minták idiómák. Nem univerzálisak, mivel csak egy programozási nyelv keretein belül alkalmazhatók.

A legsokoldalúbbak azok az építészeti minták, amelyek szinte bármilyen nyelven megvalósíthatók. Az egész program megtervezéséhez szükségesek, nem pedig annak egyes elemei.

De a lényeg az, hogy a minták céljukban különböznek. A minták, amelyekkel megismerkedünk, három fő csoportra oszthatók:

  • A létrehozási minták gondoskodnak az objektumok rugalmas létrehozásáról anélkül, hogy szükségtelen függőségeket vezetnének be a programba.
  • A szerkezeti minták különböző módokat mutatnak az objektumok közötti kapcsolatok kialakítására.
  • A viselkedésminták gondoskodnak az objektumok közötti hatékony kommunikációról.

1.4 Bevezetés az UML-be

Kezdjük azzal, hogy megnézzük ugyanazt a 23 mintát, amelyeket a Négyek bandája című könyvben leírtak. Maguk a minták és a nevük is ismerős dolog még egy kezdő programozó számára is. Bemutatom őket, de erősen ajánlom, hogy olvassa el ezt a könyvet a mintákról.

A tervezési minták nincsenek egy adott programozási nyelvhez kötve, ezért általában az UML-t használják leírásukra. 20 éve nagyon népszerű volt, de még most is néha használják. És mellesleg a minták leírása csak az a hely, ahol az UML használata a szabvány.

Az UML segítségével leírhatja a különböző entitások közötti kapcsolatokat. Esetünkben ezek objektumok és osztályok.

Az osztályok közötti kapcsolatokat négyféle nyíl írja le:

összetétel (összetétel) - az aggregáció alfaja, amelyben a "részek" nem létezhetnek külön az "egésztől".
aggregáció - a "rész" - "egész" viszonyt írja le, amelyben a "rész" az "egésztől" elkülönítve létezhet. A rombusz az „egész” oldalról látható.
függőség – az egyik (független) entitás változása hatással lehet egy másik entitás (függő) állapotára vagy viselkedésére. A nyíl oldalán egy független entitás látható.
általánosítás - egy interfész öröklődésének vagy megvalósításának kapcsolata. A nyíl oldalán található a szuperosztály vagy interfész.

Valójában itt minden nagyon egyszerű. Az utolsó nyíl valójában azt jelenti, hogy az egyik osztály egy másik osztálytól öröklődik. Az első és a második nyíl pedig azt jelenti, hogy az egyik objektum a második objektumra mutató hivatkozást tárol. És ez minden.

Ha a link gyémánt fekete, akkor a link gyenge: az objektumok egymás nélkül is létezhetnek. Ha a gyémánt fehér, akkor az objektumok szorosan kapcsolódnak egymáshoz, például egy osztály HttpRequestés annak gyermekosztálya HttpRequest.Builder.

1.5 A minták listája

A minták típusait különböző színekkel és betűkkel jelöljük:

B- viselkedési (viselkedési);

C- generáló (alkotó);

S- szerkezeti (szerkezeti).

És végül egy 23 tervezési mintát tartalmazó lista:

C- Absztrakt gyár

S- Adapter

S— Híd

C- Építő

B- Felelősségi lánc

B- Csapat

S- Linker

S- Lakberendező

S– Homlokzat

C- gyári módszer

S- opportunista

B- Tolmács

B- Iterátor

B- Közvetítő

B- Az őr

C- Prototípus

S- Proxy

B— Figyelő

C— Magányos

B- Állapot

B— Stratégia

B— Sablon módszer

B— Látogató