Partea negativa a Programarii Orientate pe Obiecte?

Workflow & Best Practices Code Review
, , ,
1

Nici nu stiu ce sa intreb… dar stiu ca vreau sa intreb ceva… insa nu reusesc sa gasesc o modalitate de a exprima ce vreau sa intreb. Probabil fiindca sunt obosit. Daca nu gasesc un raspuns, voi re-incerca sa formulez intrebari cand voi fi mai treaz.

In orice caz, voi ce parere aveti? (Despre ce se prezinta in video-uri.)

Edit: Intuitia imi spune ca are ceva de-a face cu (misusing OOP) folosirea a OOP cand nu trebuie, precum ai incerca sa te axezi pe scalabilitate, avand doar cateva zeci de actiuni (sql querry-uri, de exemplu) pe zi.

2 Likes
2

Culmea e ca de curand am vazut aceste videoclipuri si nu stiu ce sa mai cred, oare se aplica si in cazul OOP pentru php…

3

nu. oop-ul de php e diferit…

2 Likes
4

Există și varianta mai scurtă? Poți sintetiza în câteva fraze o oră de film?

Am încercat să le vizionez, dar omului îi lipsește entuziasmul; vorbește atât de plictisitor încât îmi lasă impresia că nu prea crede nici el ce spune…

1 Like
5

Am ascultat primul filmuleț în fundal. Ce mi-a rămas în minte (nu garantez că am înțeles corect - a fost cam greu de urmărit):

  • Java a devenit populară datorită contextului (pe vreme aia toate alternativele erau de nașpa)
  • OOP a devenit popular datorită Java
  • Modelul OOP nu a fost gândit până la capăt și până la urmă a creat mai multe probleme sau a complicat lucrurile mai mult decât a ajutat (fragmentarea codului, cod greu de înțeles din cauza abstractizării exagerate, classe create doar pentru encapsulare methode de tip DO-er/Manager/Service)
  • SOLID și celălalte metodologii sunt de fapt “band aids” peste OOP
  • Dacă respecți principiile care au stat la baza OOP ajungi să complici lucrurile mai mult decât ai lucra procedular iar dacă nu le respecți atunci te lupți cu un cod greu de întreținut și alte probleme.
  • codul “procedular” simplifică lucrurile prin folosirea a doar două elemente: date și cod, fără să te gândești la behavior, state și encapsulare.
  • folosește proceduri când simți nevoia, nu trebuie să faci totul OOP
  • encapsularea e ok, dar nu trebuie folosită peste tot în aplicație
  • autorul preferă functional programming din câte observ eu din exemple
  • nu trebuie să-ți fie frică de funcții lungi (total opusul sfatului din Clean Programming) și oferă și ceva tips & tricks pentru cum să structurezi funțiile foarte lungi

Nu văd ca fiind un filmuleț foarte util, e doar o părere foarte personală despre dezavantajele OOP. Face referiri la niște chestii foarte teoretice legate de OOP pe care nu le-am auzit nici în școală și probabil o să mă apuc să le caut, însă în afară de asta nimic impresionat.

Dacă te plictisești rău de tot sau ești interesat de teorii legate de programare e ok de vizionat.

Mi-ar plăcea să aud și părerea lui @Sapioit despre ce a înțeles el din filmuleț. Poate îmi dau seama că am înțeles cu totul altceva.

7 Likes
6

Din cate am inteles, spune ca OOP adauga niveluri inutile de abstactizare, care mai mult te incurca, in the long run. Also, I think he’s onto something (else), but I can’t quite grasp what that might be.

1 Like
7

E o mare ironie in primul video.
Sugerează ideea (greșita de altfel) ca metodele OOP sunt promovate ca fiind răspunsul perfect la scrierea de software.
Ironia e ca titlul video-ului e “Object-Oriented Programming is Bad”. Deci propune o alta soluție ca fiind the best.
Dar practica ne spune ca de fapt nu exista the best. Nimic nu e perfect.

Ma întrebam când o sa vad și exemple concrete de cod și soluții. Am dat skip către 38:00 si am aflat.

Omu’ asta spune ca codul din dreapta, e mult mai bun decât cel din stânga, căci “sunt mai puține funcții și call-uri de citit, deci in concluzie codul e mai ușor de citit” facepalm :expressionless: Deci cum am zice, hai sa fuck Single Responsability, SRP is for noobs

Imagine lipită1610×831 206 KB

Daca astea sunt argumente …

Asta e partea nasoala la dezbateri.
Unii oameni observa niște lucruri, trag niște concluzii, pot avea dreptate in anumite privințe, dar aluneca prea ușor in ideea ca dețin adevarul absolut, și in consecința soluția lor e screw everything, everything sucks.

Mie îmi place citatul asta
“Absorb what is useful, discard what is not. Add what is uniquely your own.” — Bruce Lee

Desi nu-mi place stilul ezoteric lui Eliott, asta e articol bunicel, dar mai bun e video-ul de pe youtute de la sfârșit (desi si ala spune ca inheritance sux, let’s mixin all the things :smiley: )

Eu cred ca unele lucruri sunt interpretabile, relative si nu le poti intelege decat lucrand mult. Si nu invers, nu tragi concluzii decât pana ce ai scris mult cod, te-ai izbit de multe probleme, ai refactorizat, etc. Nu zic ca tipul ala din video nu a făcut asta, habar n-am, dar argumentele pe care le prezinta nu mi se par SOLIDe :smiley:

5 Likes
8

Related: Frameworks don't make much sense - #4 de silviuctinvoicu

Frameworks are about encapsulation, but not for abstractions"

https://www.youtube.com/watch?v=K1EJBmwg9EQ

2 Likes
9

Bestial video-ul.
Inițial credeam că e român tipu :laughing:, la stilul cum vorbește și gesticulează (parcă la caterincă)

EDIT:
Adevărul e că am auzit de mulți developeri buni (care mi-au fost colegi în trecut), că au trecut de la OOP la functional programming și se declară până în ziua de astăzi topiți de fericire, ca urmare a acestei decizii.

1 Like
10

De functional programming am auzit si eu (student fiind, fara experienta pe cartea de munca) destule lucruri bune despre functional programming, dar ca orice lucru, isi are dezavantajele sale. Lafel poate fi spus si despre OOP si a si fost spus, spre exemplu in cele doua video-uri (al doilea ofera si exemple practice).

(That being said, I don’t quite know what functional programming really is… I’ll have to look it up… some time in the future… #procrastination )

1 Like
11

Chiar trebuie sa existe o parte negativa a programarii pe obiecte? Sau a programarii procedurale? Cred ca asta poate fi o problema in cazul in care lucrezi intr-o companie pe un cod deja existent si/sau codul tau este supus unui code review (caz in care ar fi bine sa te aliniezi stilului de programare preferat in compania/proiectul respectiv, or else). In rest, foloseste ce-ti place, eu unul sunt mare fan al OOP, ma ajuta sa-mi structurez codul mult mai bine, venind din Basic si Pascal unde totul e o mare harababura de functii, prima data cand m-am lovit de Objective Pascal (Delphi) am zis ca l-am apucat pe dumnezeu de picior.

2 Likes
12

@voxspace
Nu conteaza daca tu crezi sau iti pasa daca exista parti negative sau parti pozitive, ele exista oricum.

Nu te obliga nimeni sa renunti la OOP, doar ti-se ofera motive sa nu faci greseli pe care le poti regreta… sau nu. It’s your choice if you pay attention to them. “Because, in the end, it doesen’t even matter!” (what you think and/or do)

You’re easier to replace than you’d like to think. ALL of you. Me included, of course.

2 Likes
13

Bineinteles, nici macar nu am pretentia ca sunt unic :slight_smile:

14

Nu la asta ma refeream. Doar am raspuns urmatoarei intrebari:

15

Am inteles acum, scuze, cam prea devreme pentru chestii complexe. Ma refeream strict la faptul ca toti programatorii vad lucrurile intr-un dualism perfect: frameworkuri sau nu, oop sau nu, php sau altceva, noi vedem lucrurile ca niste filozofi innascuti, dar de multe ori lucrurile au aspecte mult mai complexe.

Normal ca exista o parte negativa sau pozitiva a oricarui lucru, dar uneori e bine sa o ignori si sa iti alegi tu calea, cu responsabilitatile care decurg din asta. Indiferent de partile pozitive si negative pe care le vede altcineva in respectivul lucru.

De exemplu, eu stiu ca exista o parte negativa in OOP, din observatiile mele in majoritatea timpului e legata de viteza de executie, dar prefer sa o ignor si sa fac optimizarile necesare in alte locuri. Nu zic ca e metoda perfecta de lucru, dupa cum bine spuneai, oricine e inlocuibil.

De fapt, cred ca amandoi spunem acelasi lucru, dar cred ca tre sa ajung la a doua cafea ca sa imi dau seama exact :slight_smile:

16

Message passing, one should focus on.

3 Likes
17

Eu prefer procedural. Asa am invatat si la etatea mea imi este mai greu sa imi schimb preferintele. In plus deja am un sistem de lucru bazat pe procedural care functioneaza fara probleme si in prezent. M-am gandit de cateva ori sa trec la oop dar n-am avut niciodata rabdare sa imi schimb complet modul personal de lucru. Sunt momente cand ‘tanjesc’ dupa ‘curatenia’ aparenta a oop-ului, dar sunt foarte rare si trec repede. Asta nu inseamna ca nu lucrez lejer si in oop. Dar niciodata n-o sa inceo de la 0 in oop. In oop lucrez cu un framework, sau cu un cod deja existent.
Cam pentru asta a fost creat. Este mai mult un standard de lucru. Ca sa ne putem intege zece minti diferite intr-un limbaj. In procedural te cam manca caini intr-o echipa de 10. In oop scapi mai usor.
Nu cred ca exista parti cu adevarat negative. Si proceduralul si oop-ul sunt niste unelte. Ca orice unealta, folosita corespunzator te poate ajuta sau te poate incurca.
Apropos de Bruce Lee, @kilogrammer ,ca in kung-fu, sa dai cu pumnu daca ala e la distanta de picior e inutil.

2 Likes
18

M-ai facut curios… si este on-topic… deci, poti, te rog, sa oferi mai multe detalii?

19

Cea mai mare limitare a unui limbaj este programatorul, iar cea mai mare limitare a programatorului este timpul.

Majoritatea aplicatiilor foarte complexe cu functii matematice merita sa fie scrise pur functional daca ai de unde sa faci rost de programatori care stiu cu ce se mananca. La facultate nu se invata algebra si logica degeaba oricum.

OOP-ul nu exclude programarea functionala (incepand cu Java 8 cel putin/Scala), dar daca te apuci sa folosesti functii lambda in ceva proiect Java cu alti 10 programatori o sa te injure cineva garantat. Practic tot limbajul devine public static seq(…) {return functie(.,.,functie()) } si singurul scop al obiectelor devine de a incarca datele din bazele de date (in special json).

2 Likes
20

Deci … nu. Nu pot sa detaliez. E ceva acumulat in cativa ani buni de lucru. De fiecare data imi zic sa nu mai ma bag in d-astea, linux vs win, php vs node, oop vs proc…etc. si tot nu pot sa ma abtin. Ideea de baza e ca aleg drumul cel mai scurt si mai sigur de la baza de date la monitor. Oop-ul se dovedeste a fi o ocolire cam mare cateodata, chiar daca in principiu suna bine.

Problema nu cred ca e oop-ul in sine, toate modurile si toate limbajele au dezavantaje clare fata de celelalte, ci modul in care este predat, modul in care este educat developerul sa foloseasca unealta.

In procedural, poti sa denumesti un caine John si sa dai echo direct. Sau esti invatat ca se poate asa si ca nu se prabuseste acoperisul pe tine daca faci asta.

In oop, esti invatat ca cainele nu trebuie sa fie maidanez, ca trebuie sa aiba o c(l)asa in care sta, impreuna cu alte animale, ca are o lesa si ca ai nevoie de o metoda ca sa il botezi. Si dupa ce le faci pe toate, poti sa scrii si metoda prin care vrei sa-l chemi. Si daca nu faci fix asa iti pierzi averea la pacanele si cand te ridici din sant vine apocalipsa.

Pana la urma e ok orice mod de a scrie, atata timp cat tu ca developer esti confortabil cu ce faci si clientul este multumit.

Ca o paranteza, sunt curios cati din voi v-ati bagat nasul in codul sursa de la vreun framework, doar de curiozitate ca sa vedeti ce se intampla cand printezi ceva din baza de date.

5 Likes