'
Bine ați venit la prima postare din seria „Design Patterns Exposed”. În această serie vom descoperi fiecare model de design de la zero.
Simpla cunoaștere a unui limbaj de programare și a construcțiilor acestuia nu vă va face un programator sau un dezvoltator mai bun. Necesită cunoașterea modelelor de proiectare pentru a crea software care să funcționeze astăzi și, de asemenea, în viitor.
Mulți dezvoltatori au întâmpinat deja acele probleme de proiectare cu care vă confruntați chiar acum sau cu care vă veți confrunta în viitor. Au specificat un mod standard de a face față acestei probleme. Prin urmare, folosind Design Patterns obțineți avantajul utilizării tehnicilor dovedite.
Fiecare model de proiectare este destinat rezolvării unui anumit tip de situație, ar putea exista situații în care pot fi utilizate mai multe tipare de design.
Majoritatea programatorilor încearcă doar să rezolve problema cu care se confruntă, fără să se deranjeze cu privire la tiparele de proiectare, codul redundant sau chiar cuplarea strânsă. Dar programatorii buni încep diferit. Se gândesc la cerințele de astăzi, la cerințele viitoare, la întreținerea codului și la reutilizarea acestuia.
Programatorii buni nu se grăbesc să înceapă codarea după ce obțin cerințele. Ei stau și se gândesc la problema dacă designul lor va funcționa. Dacă da, dacă va funcționa după 6 luni, când cerințele se vor schimba.
Programatorii buni își iau stiloul și hârtia și încep să-și proiecteze cursurile și relația dintre clase. Încearcă să obțină o cuplare slabă și o coeziune ridicată în proiectarea lor, în timp ce fac toate acestea, au în minte principii orientate spre obiecte. Nu intră imediat în codul de nivel scăzut. Pentru a proiecta software flexibil și reutilizabil, ar trebui să urmați această abordare, altfel vă veți găsi întotdeauna modificând codul pe care l-ați scris anterior.
Există doar un singur lucru care este constant în industria software-ului și că este Schimbare. Cerințele se vor schimba cu siguranță. Deci, cum proiectăm software-ul pentru ca codul dvs. să se poată adapta cu ușurință la cerințele viitoare? Pentru aceasta, trebuie să începeți devreme și să-l proiectați astfel încât cerințele viitoare să nu vă încalce codul anterior.
Cum pot face acest lucru?
Ei bine, se poate face urmând principiile de proiectare și modelele de proiectare bazate pe aceste principii.
găsiți cel mai mare element în matricea java
Acum, să ne scufundăm în codificare și să începem călătoria pentru a deveni un programator mai bun. În această postare, vom descoperi unul dintre cele mai importante tipare - Model de strategie .
Când spun cel mai important, se reflectă asupra problemei comune care este rezolvată de Patternul Strategiei.
Ce este modelul de strategie?
Iată definiția directă din cartea „Gang of Four”: „Modelul de strategie este utilizat pentru a crea o familie interschimbabilă de algoritmi din care este ales procesul necesar în timpul rulării”.
În caz că eștinu sunt capabili să înțelegeți, nu vă faceți griji, o vom explica într-unmai simplucalepentru tine saa intelege.
Să înțelegem mai întâi problema și apoi vom vedea cum modelul de strategie poate rezolva problema.
În diagrama UML de mai sus, avem clasa Animal abstract și două clase concrete, Dog și Bird, care se extind de la super clasa Animal.
Așadar, să definim o clasă abstractă Animal și două clase concrete, Câine și Pasăre.
Ce părere aveți despre designul de mai sus? Există o mare greșeală în designul nostru.
Toate animalele nu pot zbura, ca în cazul de mai sus, un câine nu poate zbura. Dar totuși are un comportament „de zbor”.
Am făcut o greșeală scriind metoda abstract fly () în clasa Animal. Acest design va forța fiecare sub-clasă câine, pasăre, pinguin, crocodil, gâscă etc. să implementeze metoda fly ().
Ar fi trebuit să înțelegem că zborul este o abilitate pe care nu o vor avea toate animalele. Furnizând metoda fly () în clasa Animal abstract, am stabilit capacitatea de zbor în toate sub-clasele, ceea ce nu este corect pentru toate sub-clasele de animale.
S-ar putea să vă gândiți care este problema în implementarea metodei fly în sub-clase. Deși puteți implementa metoda fly () în subclasele de animale care nu zboară pentru a tipări „Nu pot zbura”. Dar problema este că încă oferiți musca comportament animalelor care nu zboară. Acest lucru nu este corect.
Cum te simți când apelezi dog.fly () sau crocodile.fly ().
Deci, acum am înțeles că proiectarea noastră nu este corectă și ar trebui să eliminăm metoda fly () din subclasa Animal.
Care este cealaltă modalitate de a proiecta clasele noastre într-un mod în care proiectarea noastră nu impune tuturor sub-claselor animale să aibă un comportament de zbor.
cum se tipărește în java
O soluție care ne vine imediat în minte este că putem crea o interfață de zbor cu metodă de zbor și numai animalele care pot zbura vor implementa acea interfață de zbor. În acest fel, nu vom aplica toate subclasele de animale pentru a defini un comportament de zbor. Deci, să codificăm această abordare de proiectare.
Acum, clasa noastră Animal va arăta ca codul de mai jos după ce a eliminat metoda fly din clasa Animal.
Acum să definim interfața Flying
Acum, clasa de câine va fi schimbatăla fel decodul de mai jos și nu trebuie să aibă un comportament de zbor.
Să vedem câteva dintre subclasele noastre de animale care vor avea un comportament de zbor.
Am rezolvat problema noastră anterioară, dar ne-am confruntat cu o nouă problemă și aceasta este „Duplicarea codului”.
Spuneți, vom avea 100 de sub-clase diferite de animale zburătoare. Trebuie să duplicăm codul pentru comportamentul de zbor, deoarece interfața de zbor nu poate oferi nicio implementare pentru comportamentul de zbor, iar mai târziu, dacă dorim să schimbăm implementarea metodei fly () în orice subclasă va trebui să deschidem acea clasă și să schimbăm codul ceea ce este rău. Ne lipsește ceva mare și, adică, nu putem schimba comportamentul de zbor al unei clase în timpul rulării.
Dar nu vă faceți griji, modelul strategiei este acolo pentru a vă scoate din această problemă.
Deci, să refacem codul nostru pentru a utiliza modelul de strategie.
Interfața de zbor va rămâne la fel ca în prezent. Acum, mai degrabă decât fiecare subclasă de zbor care implementează interfața de zbor în sine, vom defini clase concrete separate care vor implementa un comportament de zbor diferit. Să vedem cum să facem asta.
Deci, cum funcționează totul, să vedem TestClass
Prin utilizarea modelului de strategie, suntem acum capabili să schimbăm comportamentul de zbor al oricărui animal în timpul rulării și asta fără a impune nicio subclasă pentru a specifica comportamentul de zbor în sine.
Când se folosește modelul de strategie?
Când doriți să puteți schimba dinamic comportamentul la rulare.
Pentru a ne asigura că înțelegeți clar modelul de strategie, să luăm un alt exemplu.
În clasa de angajați de mai sus stabilim plata salariatului în funcție de desemnarea acestuia. Dacă un angajat este „stagiar”, adăugăm 10% bonus la salariul de bază pentru a calcula salariul real.
Dacă un angajat este „Dezvoltator web”, adăugăm bonus de 20% la salariul de bază pentru a calcula plata efectivă și urmează un proces similar pentru alte tipuri de angajați. Deși algoritmul nostru pentru calcularea plății reale este foarte simplu pentru a ușura înțelegerea, dar de cele mai multe ori, include multe comparații și calcule.
cum se creează un parametru în tablou
Deci, ce este în neregulă cu codul de clasă pentru angajați?
Ei bine, codul pentru calcularea plății (getPay ()) este static. Să presupunem că vreau să schimb bonusul pentru „Intern” de la 10% la 14%. Va trebui să deschid codul clasei angajaților și să-l schimb.
Și o altă problemă este că nu pot schimba algoritmul de plată al unui angajat în timpul rulării. Deci, cum să faci asta? Modelul de strategie este utilizat în mod special pentru gestionarea acestui tip de problemă.
Să refactorizăm codul pentru a utiliza modelul de strategie.
Voi defini mai mulți algoritmi pentru calcularea plății. Apoi voi putea folosi oricare dintre acești algoritmi pentru a calcula plata în timp de execuție.
Acum, să vedem cum se va schimba clasa de angajați.
Notă: Am eliminat logica de calcul a plății din clasa Angajați și am creat o metodă setată PayAlgorithm () prin care voi seta PayAlgorithm pe care vreau să îl folosesc pentru calcularea plății.
Acest lucru îmi va oferi flexibilitatea de a calcula plata prin specificarea oricărui PayAlgorithm dinamic în timpul rulării. De asemenea, rețineți că ulterior, dacă trebuie să schimb logica de calcul a plății, pot crea un nou PayAlgorithm și îl pot folosi pentru a calcula plata. Nu este nevoie să schimb codul anterior, nu-i așa?
Deci, să vedem că funcționează.
Sper că ați înțeles foarte bine modelul de strategie. Cel mai bun mod de a învăța ceva este practicând.
În cazul în care aveți întrebări referitoare la modelul de strategie sau la orice alt model, lăsați-le mai jos.
Aveți grijă la următoarea postare, unde vom descoperi unul dintre cele mai populare tipare de design, modelul de fabrică.
Până atunci puteți descărca jocul cu codul și asigurați-vă că cimentați modelul de strategie în cap.
Ai o întrebare pentru noi? Menționați-le în secțiunea de comentarii și vă vom răspunde.
Postări asemănatoare: