Cum cei doi programatori au coace pâine
Lucrez ca programator de mai mulți ani, timp în care, destul de ciudat, mă confrunt cu toții. . Managerul (dacă în universul clasă de produse, de la care el moștenește diferența de clasă este manager de minim de proiect, un pic de înțelegere mai profundă (este se pare doar, da) la nevoile clientului, vine pentru a doua oară și a spus, - alocarea de abstractizare „, precum și Implementat implementarea dependenței prin setter!
cerința clientului este propria sa inițiativă. Dar nimeni nu va ști despre asta, nu? - Avem nevoie de pâine, plăcinte și prăjituri pentru a fi coapte în funcție de diferite rețete.
„Hmm,“ - spune Boris și își aduce aminte șablon „constructor“ (împreună, desigur, cu „interfață liberă.“). Creează o clasă de rețete, și pentru ea un constructor RecipeBuilder. Reteta el introduce (dintr-o dată!) În foc, cu ajutorul unui setRecipe setter (reteta: Rețetă).
Și Marcus (nu veți crede) adaugă încă un parametru întreg în createBread - rețetă.
Cel mai interesant, ca întotdeauna, se întâmplă departe de calculatoare. Anume: managerul întâlnește clientul pentru prima dată după începerea dezvoltării și în cele din urmă își dă seama de ce a fost nevoie de aragaz. El (managerul) vine pentru programatori pentru a șaptea oară și spune: - Trebuie să ardem cărămizi în cuptor.
Pentru Boris, aceasta este ultima intalnire cu managerul, dar totusi face cele mai recente schimbari in arhitectura. Alocă clasa abstractă AbstractHeatingSmth - încălzire abstractă. Pentru el, el creează o fabrica de încălzire. Din AbstractHeatingSmth, el moștenește ProductOven și Furance. Acesta din urmă are o metodă de fabricare a fabricației, care reprezintă un obiect din cărămidă. Dar nimic nu funcționează. Cititorul este invitat să găsească pe cont propriu o eroare în arhitectură.
Și la Marcus nu toate sunt așa de netede. Trebuie să creeze clasa a treia (!). El îl numește Brick și adaugă metoda MakeBrick managerului său.
Desigur, puteți argumenta că Marcus în cadrul metodei createBread creează Ad și Israel. și acest lucru este de fapt așa. Dar, cu ajutorul modelului "metodei șablonului", tulburarea poate fi complet structurată. Și în abundența de fabrici și abstracții de a înțelege, bine, un pic mai dificil.
Concluziile pe care vreau să le fac sunt probabil puțin previzibile.
Abordarea lui Boris este bună deoarece aproape fiecare parte a sistemului poate fi izolată și acoperită cu teste. Dar timpul pentru a crea un astfel de număr mare de clase va lăsa multe indecente, și fiecare schimbare cerințe se va transforma schimbarea codului în cascadă. O încercare de a face arhitectura flexibilă, anticipând dorințele clientului, de obicei nu reușește - arhitectura este îndoită complet. La urma urmei, după cum știm, "lumea nu este doar mai uimitoare decât ne imaginăm, este mai uimitoare decât ne putem imagina". Și, după ce a primit următoarea solicitare de schimbare, programatorul este convins de acest lucru ca nimeni altcineva.
Abordarea lui Marcus, în cele din urmă, nu permite utilizarea testării unității. dar dă rezultatul mult mai rapid, iar modificările sunt date în mai puțin sânge. Aceasta abordare este cel mai rapid inceput pe care starii de toate dungile doresc. Și, destul de ciudat, într-un astfel de cod este într-adevăr mai ușor de înțeles, pentru că este mai ușor.
Și pentru a rescrie totul, dacă asta este întotdeauna de succes.
Imagine a luat com .tr / galeridetay.aspx? P = 2cid = 35509rid = 4369 „> aici
Articole similare
Trimiteți-le prietenilor: