Pentru prietenii mei programatori: ce erori frecvente de OOP găsiţi voi in codul altora (evident, nu în codul personal că ăla e perfect)?
Eu ştiu sigur că erorile pe care le-am văzut au ţinut de overdesign, de layer breaking, de patterns-abuse (singleton-uri, porcării d-astea), cast-uri ciudate (care teoretic nu ţineau de layer breaking).
Voi?
Sincer, nu ştiu ce înţelegi prin „layer breaking”.
Problema pe care am întâlnit-o cel mai frecvent nu ţine atât de overdesign cât de lipsa totală a design-ului. Mentalitate de genul: hai să folosim OOP, că e cool.
De departe cel mai abuzat concept este moştenirea. Probabil din cauză că este primul lucru care se predă pe la noi prin şcoli şi este prezentată ca fiind o metodă magică de a reutiliza codul. Oameni nu e chiar aşa de greu: puneţi întrebarea „is it a…” înainte de a băga moştenire, for [your favorite deity]’s sake. Şi nu faceţi ierarhii de moştenire pe 50 de niveluri. Moştenirea e statică, bătută în cuie, sparge încapsularea etc (deci pretty much sucks). Moşteniţi pe cât posibil de la clase abstracte, cu scopul implementării polimorfismului.
Referitor la design patterns… mie mi se par utile. Singleton-ul este într-adevăr mai hulit, pentru că seamănă oarecum cu o variabilă globală. În rest însă, nu strică să le ştii, din mai multe motive: 1) dacă reinventezi roata ai mari şanse să o reinventezi prost 2) îţi modelează un anumit tip de gândire şi 3) sunt excelente ca şi limbaj comun – e foarte mişto când poţi să-i zici colegului „bă, cred că avem nevoie de un observer aici” şi el să te înţeleagă fără explicaţii suplimentare.
Nu ştiu de ce i-aş spune unui coleg ‘bă, cred că avem nevoie de un observer aici’. Eu unul n-aş înţelege ce zici şi ţi-aş zice fuck off. Design pattern-urile creează următorul scenariu absolut idiot:
Interviu de job la o firmă de software mare. Eu, intervievatul. El întreabă: cum rezolvi problema Half-Sync, Half-Async. Stupoare de partea mea: “Ce problemă?”. El, încrezător: “Half-sync, Half-async”. Din momentul acela nu a mai existat consens în discuţie, pentru că i-am cerut să îmi descrie problema. I-am rezolvat problema aşa cum mi-a descris-o el. El mai avea nevoie de un mutex pe undeva, pentru că aşa era pattern-ul. Eu nu mai aveam. De ce? Pentru că el pur şi simplu nu ştia să-mi definească problema. Am stat 50 de minute să-l conving de faptul că se înşeală, şi pînă la urmă omul a cedat: “mai ai nevoie de un mutex aici că poţi avea mai mulţi cititori”… mă rog, o parte din problemă pe care o uitase.
Concluzia: omul ăla ar fi folosit oricum pattern-ul respectiv cu doi mutecşi, pentru că aşa e pattern-ul. Ceea ce e mişto, dar încetineşte operarea adăugînd un mutex inutil. Şi nici nu e de mirare că ’software gets bloated’, doar pentru că aşa e pattern-ul.
O să public referatul respectiv pe blog după ce îl termin - o să iau un pic în considerare şi ideea pe care ai expus-o tu aici, şi cred că argumentarea o să fie suficientă.
Eu insist totuşi pe chestia cu limbaj comun. Cel puţin pattern-urile GoF ar trebui cunoscute ca să te înţelegi cu alţii, ca să pricepi ce vrea să zică autorul când citeşti o carte etc.
A, nici eu nu sunt de acord cu folosirea de pattern-uri pe care nu le înţelegi, aşa cum a fost în cazul interviului tău. Omul ăla ştia probabil pattern-ul, dar habar n-avea ce se întâmplă acolo.
O altă întrebare stupidă de la interviurile de angajare: care este pattern-ul tău favorit [jaw-drop]. Dacă ai „pattern favorit”, ai o problemă. Pattern-urile nu trebuie forţate. Foloseşti un pattern dacă ai exact situaţia pentru care a fost gândit. Deci „pattern-ul favorit” este pattern-ul care te ajută să rezolvi problema respectivă.
The hell with patterns!!!
lol
Ce suntem noi aici? Masini de recunoscut sabloane?
Mai in gluma mai in serios, programarea nu e o stiinta e o arta. Si atata timp cat va fi o arta nu va fi nici un mod/set de reguli si standarde clar dovedite de a o face bine. Fiecare dupa talent.
Că-ţi place sau nu, şi tu foloseşti şabloane. Doar că le foloseşti pe alea inventate de tine. Presupun că atunci când faci un lucru pentru a n-a oară o faci cam la fel ca atunci când ai făcut-o a n-1-a oară. Şi acel „fel” poate diferă oarecum de felul cum l-ar face altcineva.
Şabloanele consacrate (mă refer în special la GoF, nu la alte chestii mai obscure gen „Half-Sync, Half-Async”) sunt nişte soluţii „tried and true” pentru nişte probleme destul de des întâlnite. Sunt nişte chestii destul de mici şi simple ca să nu-ţi stea în cale. Deci n-o să pui două pattern-uri cap la cap şi o să-ţi iasă un program. Şi nici nu cred că o să ajungă vreodată programarea o permutare de pattern-uri.
Presupui foarte multe si de fapt stii foarte putine despre mine si ce fac eu
Si asta este chiar una dintre problemele artei software. Oamenii presupun si isi inchipuie lucruri cu mult mai monstruoase si complexe decat sunt in realitate.
Iti recomand cartea asta: http://www.industriallogic.com/xp/refactoring/ si conceptul: “refactoring away from patterns”.
Oricum nu sunt asa de tipicar in gandire pe cat crezi tu. Si ca alt punct de vedere, sunt foarte bine instruit in patterns, si da mi se intampla sa vorbesc in patterns ca sa exprim mai scurt ceva ce altfel ar dura mai mult, atunci cand oamenii inteleg ce spun. Dar sabloanele sunt… sabloane. Pentru cei mai putin ajutati de minte, retete sa se descurce cumva si ei.
Aaaa si parerea mea: “the above average software engineer lacks the brains to understand GoF”.
The hell with patterns, I tell you!
Ok, din tonul discuţiei văd că mă contrazici, dar nu prea îmi dau seama pe ce puncte. Oricum, discuţia este cam sterilă. Este – presupun – şi o chestie de preferinţă personală. Mie mi se pare util să cunoşti cel puţin pattern-urile GoF, chiar dacă nu le şi aplici. Poate tu ai găsit soluţii mai eficiente pentru problemele respective (ceea ce, din nou, este discutabil).
Ovidiu: cred că se referă la faptul că prea multe patterns distrug mintea. Problemele nu merg întotdeauna pe şabloane, iar programatorul chinuit de şabloane are probleme mari de adaptare la ‘real life’.
Pattern-urile nu sunt soluţii ‘tried and true’; sunt cel mult guidelines pentru a obţine o anumită soluţie - şi îţi pun în faţa nişte detalii pe care poate le poţi scăpa din vedere (şi majoritatea programatorilor le scapă din vedere). De exemplu, faptul că pentru AbstractFactory creezi ierarhii paralele identice, lucru care poate scăpa la design time, şi alte chestii de genul ăsta. Dar o minte educată nu are nevoie să aplice ‘AbstractFactory’ - ci va fi flexibil în abordarea sa, aplicînd ce e necesar şi cum e necesar.
Of, of ce serios e Ovi ăsta.
Ovi dragă, mai mult rău s-a făcut în lume decât bine de când banda celor patru au inventat sabloane de scris code. De ce? Pentru ca multi cu insuficienţă creierească (adică proşti, că văd că nu îmi guşti ironiile) încearcă să le folosească pentru a arăta cât de bazaţi sunt.
Şi dacă un cod prost şi nestructurat şi nu gândit bine e OK pentru că unu mai inteligent îl înţelege şi îl poate repara, apăi un cod de foloseşte vizitatori peste observatori peste o fabrică abstractă, care nu îşi au rostul nici una dintre ele a fi folosite în locul in care sunt… e mult mai provocator şi mai greu de înţeles chiar şi pentru cei mai răsăriţi.
În 97% din cazuri în care am văzut un şablon folosit, era folosit prost şi fie altul fie niciunul nu trebuia folosit. Iar una din întrebarile mele favorite când trebuie să ţin un interviu este: “ai folosit vreun design pattern sau cunoşti? … ok, ce nu îţi place la el şi ce probleme poate cauza?”
Până nu ştii ce probleme poţi cauza cu un anume şablon ar trebui să fie interzis să îl foloseşti. Şi sunt foarte puţini care ştiu.
Vezi tu problema e că banda celor patru haiduci s-a inspirat din arhitectură, doar că e o mică mare diferenţă. O casă nu se contruieşte în continuu arhitectul şi toţi muncitorii schimbându-se în fiecare 3 luni… şi o casă se mai şi prabuşeşte dacă e construită prost, iar arhitectul e băgat la închisoare. Las la latitudinea ta să faci paralela cu software.
PS: O discuţie e sterilă dacă te aştepţi ca celălalt să îţi dea mură în gură opinia lui (problema tipic românească - fârâ insulte ascunse sau ironii). Sunt neinteresat să fac asta, dacă vrei să înţelegi (aka use the brain and parse the text, not just read) ce spun eu aici putem avea o discuţie, daca nu… picturile murale sunt frumoase şi îmi place să le admir când vorbesc cu ele.
„Până nu ştii ce probleme poţi cauza cu un anume şablon ar trebui să fie interzis să îl foloseşti.”
De acord.