Tocmai ce m-am uitat la vreo 3-4 thread-uri mai devreme și am văzut o mică tendință de a împinge OOP-ul în față. Mi-a adus aminte de vremurile când frecventam phpromania.net, acum vreo 5 ani. Eram începător, iar OOP-ul era “all the rage”, inclusiv pentru mine. De pildă, Zend Framework punea totul în clase, chit că erau o grămadă de metode statice care puteau la fel de bine să fie funcții. Iar unii numeau OOP cam orice avea legătură cu cod structurat rezonabil.
Eram curios câți dintre voi consideră că OOP e un fel de silver bullet al programării. Sau dacă nu silver bullet, ceva foarte apropiat. Filter bubble-ul în care sunt eu acum e plin de functional programming (FP) și mai puțin de OOP, chiar dacă e încă prezent.
Cum se vede de la voi? Cât de mult sunteți entuziasmați de ideea de OOP? Sau poate a fost înlocuit cu altceva?
Am inceput cu OOP citind PHP Power Programming, dupa cativa ani am trecut spre Funcitonal Programming, dar folosesc clase unde are sens, cel mai probabil cand am nevoie de state. Recomand folosirea unui sistem modular de unde se pot importa usor functii, decat un sistem bazat pe clase care extind alte clase.
In general da, catre asta tind, dar sunt si cazuri in care incep un proiect pe care-l dezvolt alaturi de alti developeri si ma mulez pe stilul lor de lucru daca vor prelua mentenanta.
Eu sunt în stadiul în care combin FP cu OO. FP pentru small scale, iar OO pentru large scale. În principiu tratez obiectele ca pe module de funcții cu un closure comun (constructor params). De-asta nu prea am o paradigmă favorită. Mă rog, FP și OO sunt oarecum ortogonale, pentru că poți avea functional objects.
Abordarea OO în care tratezi apelurile de metode ca message passing, adică un fel de actor model, nu mi-a ieșit niciodată. E un pic prea îngăduitoare pentru mine și ajung să am grafuri de obiecte și mesaje pe care nu le mai înțeleg.
A aplica paradigme FP in limbaje OOPesque nu este echivalent cu a folosi FP in productie. Pe de alta parte clar nu este ceva rau (de fapt da, just look at Scala I kid, I kid)
Sunt doua paradigme diferite si da multe concepte din FP fac codul OOP mult mai clar, safe, etc. Insa, cel putin din mica mea incursiune in FP - you get the most of it whilst keeping FP purity at least when you’re using a FP language.
De fapt cred ca aici este distinctia importanta:
mix OOP languages with FP
don’t try to mix the OOP mindset in FP languages
acum cat de pure sunt, depinde clar - in final some argue that even Haskell is impure but you get my point.
Ăsta e momentul ăla în care părerile devin foarte subiective, iar definițiile se evaporă
Din punctul meu de vedere, orice program care folosește imutabilitate în procent majoritar, este scris în stil FP. Când n-ai mutabilitate o multitudine de construcții dispar. Nu mai poți folosi while sau for, nu mai poți folosi if fără un else, iar de aici alte consecințe. E adevărat că ai nevoie de un pic de suport din partea limbajului; musai să ai funcții anonime.
Agree insa unele limbaje sunt construite sa ruleze best intr-o anumita paradigma. In Ruby de exemplu daca fortezi imutabilitatea - prepare for abysmal performance and memory bloat (they go hand in hand - hail the GC) Un alt exemplu ar fi Scala, Clojure peste JVM care sunt iarasi slower (correct me if I’m wrong).
Ca sub-point: cred ca este destul de greu sa optimizezi un limbaj sa accepte orice paradigma si sa si ruleze fast enough. (dunno why asm.js comes to mind)
Bineinteles it depends: un pic de FP + profiling & benchmarking ca totul ramane in parametrii normali => heck yeah. Insa FP style in limbaje care nu sunt facute pt. FP? IMHO just use an actual FP language of choice and drop the OOP whilst reaping the full benefits.
EDIT: bonus point article on how Joe Armstrong and Ralph Johnson argue that Erlang is OOP
OOP are aplicabilitate foarte mare în continuare. FP este probabil viitorul (și trecutul, fiind prima paradigmă inventată ), dar mai are până la mainstream.
Să nu uităm că abia am reușit să învățăm cum să scriem cod OOP decent - mă refer la practicile și principiile Agile, lucruri încă prea tinere pentru mediul enterprise.
FP este pasul următor logic pentru că OOP nu poate fi ușor aplicat pe un număr mare de procesoare sau core-uri. Tehnologia hardware ne va forța către FP. Dar mai sunt suficienți ani să savurăm OOP.
Prefer OOP ca schelet principal, nimic nu egalează toolingul și experiența de zeci de ani acumulate în materie de patterns and practices. Dar îmi place FP, e elegant, și îl folosesc unde are sens.
Stiu OOP si il folosesc, dar ca fapt divers poti face un proiect cu programare procedurala(imperativa) fara OOP dar invers nu se poate, legat de FP nu imi plac limbajele pur functionale gen Erlang, nu pot gandi in ele dar in schimb am inteles lambda expression in C#.
I kid, I kid)
