Second Opinion
Folosind serviciul second opinion ne puteți trimite RMN-uri, CT -uri, angiografii, fișiere .pdf, documente medicale. Astfel vă vom putea da o opinie neurochirurgicală, fără ca aceasta să poată înlocui un consult de specialitate. Răspunsurile vor fi date prin e-mail în cel mai scurt timp posibil (de obicei în mai putin de 24 de ore, dar nu mai mult de 48 de ore). Second opinion – Neurohope este un serviciu gratuit. www.neurohope.ro |
Muncă multă în constructor - da sau ba?
#73
Posted 03 May 2019 - 13:09
Iulius-Foyas, on 03 mai 2019 - 13:04, said:
Yes sir, chiar acum imi repet ca o mantra "daca pot sa apelez orice metoda publica in orice mod atunci obiectul este valid" si imi apare in minte faptul ca la un vector nu pot sa apelez metoda .at(index) fara sa-l populez mai intai si ma intreb: este un vector gol un obiect valid din moment ce contrazice aceasta mantra ? Un vector ca proprietate a unei clase proprii, care are constrangeri din domeniu, trebuie sa se supuna acelor constrangeri ca sa fie valid. Mai exact, clasa care il incapsuleaza trebuie sa se asigure de asta. Tu habar n-ai despre ce vorbim in acest topic, le faci varza si apoi te smiorcai. Pe mine si pe @OP ne leaga un mini-proiectel frumos: https://forum.softpe...tori-mid-level/ Edited by OriginalCopy, 03 May 2019 - 13:09. |
#74
Posted 03 May 2019 - 13:36
OriginalCopy, on 03 mai 2019 - 13:09, said:
Un vector ca atare este valid si gol. "la un obiect valid pot folosi orice metoda publica in orice ordine." Ce facem acum ? Contrazicem mantra ? Sa ne reamintim: https://forum.softpe...6#entry24622791 si https://forum.softpe...6#entry24618416 Edited by Iulius-Foyas, 03 May 2019 - 13:34. |
#75
Posted 03 May 2019 - 13:43
Iulius-Foyas, on 03 mai 2019 - 13:36, said:
si atunci de ce nu pot folosi metoda .at(index) inainte de metoda .push_back(valoare) conform mantrei? Repetam mantra: "la un obiect valid pot folosi orice metoda publica in orice ordine." Asta nu inseamna ca nu poti scrie propriul tau cod in asa fel incat obiectele sa fie mereu valide. Si in interiorul claselor tale, sa te asiguri ca incapsulezi lucrurile din std:: si ca mentii mereu invariantele din domeniu. Noi nu vorbim pe acest topic despre ce fac altii, ci despre ce facem noi in propriile noastre clase. |
#76
Posted 03 May 2019 - 14:18
Discutia a plecat de la multa munca in constructor. Daca validitatea obiectului depinde de un calcul de juma de ora pe care sa-l pui in constructor, ca sa nu-ti crape codul pentru ca nu apelezi o anumita metoda, e timpul sa regindesti ideea de validitate sau obiectul in sine.
|
#77
Posted 03 May 2019 - 14:23
Mosotti, on 03 mai 2019 - 14:18, said:
Discutia a plecat de la multa munca in constructor. Daca validitatea obiectului depinde de un calcul de juma de ora pe care sa-l pui in constructor, ca sa nu-ti crape codul pentru ca nu apelezi o anumita metoda, e timpul sa regindesti ideea de validitate sau obiectul in sine. Poti avea de exemplu ceva "mission critical" d.p.v. al acuratetii pe care il poti pune intr-un thread separat, si e ok daca la startup acel thread are nevoie de 5 minute to catch up. Depinde, depinde, depinde. |
#78
Posted 03 May 2019 - 14:48
Much ado about nothing. Apropo, ca tot pomeniti de C++ pe aici, exista niste motive pentru care C++ e multi-paradigma. Nu e nevoie s-o dai in fanatism obiectual cu el (sau functional, etc, desi se pot supara fanii programarii functionale).
|
#79
Posted 03 May 2019 - 16:50
#80
Posted 03 May 2019 - 17:37
Toata discutia asta confirma inca o data stupiditatea functiilor cu nume substantiv
|
#81
Posted 03 May 2019 - 17:45
OriginalCopy, on 03 mai 2019 - 13:43, said:
Biblioteca standard C++ nu este moderna din cauza BC. Asta nu inseamna ca nu poti scrie propriul tau cod in asa fel incat obiectele sa fie mereu valide. Si in interiorul claselor tale, sa te asiguri ca incapsulezi lucrurile din std:: si ca mentii mereu invariantele din domeniu. Noi nu vorbim pe acest topic despre ce fac altii, ci despre ce facem noi in propriile noastre clase. |
#82
Posted 03 May 2019 - 17:50
|
#83
Posted 03 May 2019 - 17:54
TS030, on 01 mai 2019 - 13:04, said:
Ideea de baza este ca orice clasa/tip de date [...]arman valizi orice metode ai apela, TS030, on 01 mai 2019 - 13:04, said:
are un set de invarianti, TS030, on 01 mai 2019 - 13:04, said:
Un pointer ar putea pointa catre o zona de memorie alocata sau nullptr. TS030, on 01 mai 2019 - 13:04, said:
Daca trebuie sa mai apelezi o metoda pentru a avea un obiect valid... ai o problema. TS030, on 01 mai 2019 - 13:04, said:
Apropo, exemplu banal de cum poti folosi un container fara a verifica daca are sau nu elemente: auto sum = std::accumulate(begin(cont), end(cont), 0); OriginalCopy, on 01 mai 2019 - 09:54, said:
state invalid e atunci cand nu poti apela orice metoda publica in orice ordine, cand trebuie sa apelezi foo() inainte de bar(), ambele public. Dar ai uitat sa ne prezinti ce-a mai banala si frecventa operatiune, cum anume returnezi o valoare dintr-un container fara sa verifici daca e gol sau nu. OriginalCopy, on 01 mai 2019 - 22:07, said:
Povestea cu QPixmap e analoga cu povestea cu vector care are voie sa fie gol - normal ca are voie sa fie gol, asta e definitia unui vector. Una e cand un framework zice "hai sa desenam o imagine oarecare", alta e cand in aplicatia X cu cerinte precise trebuie sa zici "hai sa desenam o harta cu butoanele X, Y, Z care fac ...". Nu e o contradictie in ce spun, pentru ca trebuie sa te uiti la un proiect/librarie in contextul lor: 1. care sunt cerintele pentru qt, din perspectiva celor care au creat qt 2. care sunt cerintele pentru aplicatia mea, care poate foloseste qt Cred ca tot tu erai ala care zicea ca nu e bine sa ai setteri, ca cica duc foarte usor obiectele in stari invalide. Asta e o prostie. Din contra, setteri permit cod ce se ocupa de validarea datelor introduse, pentru a evita valorile invalide. Ai luat din zbor niste idei care ti s-au parut la moda de prin programarea functionala, ideile cu imutabilitatea si lipsa setterilor, povestea cu "nu trebuie sa conteze ordinea apelarii metodelor", obsesia cu "validitatea" starii obiectelor samd. Numai ca astea sunt niste prostioare nerealiste, care nu pot fi aplicate cum visati voi in programarea reala. Nu ai cum sa folosesti doar tipuri de date imutabile, nu ai cum sa faci totul din constructori, nu are nicio logica sa construiesti noi obiecte cand vrei de fapt doar sa modifici o componenta a unui obiect. Imutabilitatea se preteaza doar pentru anumite tipuri de date value-based(adica rolul lor principal e sa stocheze niste date), nu pentru obiecte complexe. Din constructori nu poti intitializa mereu tot, oricand, oricum, caci exista obiecte complexe, care trebuie initializate intr-o anumita ordine, a caror initializare depinde cutare alte aspecte(poate stari ale altor obiecte, poate operatiuni I/O, poate cine stie ce). Si nici sa restrictionezi excesiv disponibilitatea metodelor publice(asta deja miroase a preocupare comuna cu a celora care fac api-uri/biblioteci/frameworkuri), doar ca sa subscrii nu stiu caror idei de aiurea ce le-ai auzit pe la nu stiu care "guru", caci in final ajungi sa faci niste prostii similare cu optimizarea prematura, dar in speranta ca vei evita erori pe viitor. O invatare corecta a paradigmei OOP ar trebui sa lamureasca multe aspecte. Fara "influente" din asa zisa "programare functionala" sau alte prostii. Edited by DemocracySucks, 03 May 2019 - 17:55. |
#85
Posted 03 May 2019 - 17:58
#86
Posted 03 May 2019 - 17:59
Mosotti, on 03 mai 2019 - 14:18, said:
Discutia a plecat de la multa munca in constructor. Daca validitatea obiectului depinde de un calcul de juma de ora pe care sa-l pui in constructor, ca sa nu-ti crape codul pentru ca nu apelezi o anumita metoda, e timpul sa regindesti ideea de validitate sau obiectul in sine. implicit si de multe ori indeplnirea business-logicului ar depinde si de alte obiecte. |
#87
Posted 03 May 2019 - 18:03
OriginalCopy, on 03 mai 2019 - 14:23, said:
De acord. Depinde foarte mult de detalii, asta am si zis in primul meu raspuns aici pentru @OP. Depinde, depinde, depinde. Iulius-Foyas, on 03 mai 2019 - 17:59, said:
dupa pararea mea , validitatea unui obiect trebuie sa fie legata de indeplinirea business-logicului |
|
#88
Posted 03 May 2019 - 18:06
DemocracySucks, on 03 mai 2019 - 17:54, said:
Exact la fel cum un vector poate sa fie gol Iulius-Foyas, on 03 mai 2019 - 17:45, said:
Pai in aceasta noua paradigma lucrurile se schimba radical,discutam altfel. DemocracySucks, on 03 mai 2019 - 18:03, said:
De fapt, daca ne gandim bine, nu exista "validitatea obiectului" ci validitatea utilizarii obiectului. Un nume mai bun ar fi "Initializator" sau ceva de genul. |
#89
Posted 03 May 2019 - 18:12
Mosotti, on 03 mai 2019 - 14:18, said:
Discutia a plecat de la multa munca in constructor. Daca validitatea obiectului depinde de un calcul de juma de ora pe care sa-l pui in constructor, ca sa nu-ti crape codul pentru ca nu apelezi o anumita metoda, e timpul sa regindesti ideea de validitate sau obiectul in sine. In acest moment daca dorim sa protejam tot timpul anumiti membrii ai clasei trebuie sa folosesc si setteri sau perechi setteri/getteri. Problema este ca in acest caz ma lovesc de o alta cutuma in OOP: getter and setter methods are "evil" DemocracySucks, on 03 mai 2019 - 18:03, said:
Pai evident. Numai ca ai ajuns de la afirmatii categorice pe ton de profesor, la "depinde, depinde, depinde: ... De fapt, daca ne gandim bine, nu exista "validitatea obiectului" ci validitatea utilizarii obiectului. Insa validitatea obiectului este complet diferita de validitatea utilizarii obiectului. Edited by Iulius-Foyas, 03 May 2019 - 18:12. |
#90
Posted 03 May 2019 - 18:14
Iulius-Foyas, on 03 mai 2019 - 18:06, said:
Problema este ca in acest caz ma lovesc de o alta cutuma in OOP: getter and setter methods are "evil" jegmihai, on 29 decembrie 2018 - 23:26, said:
Am reușit să evit setterii într-un proiect recent de nivel mediu (cam pe acolo îl apreciez). I-am încurajat și pe colegii de echipă să procedeze asemenea. Pe de altă parte, dacă faci o aplicație care interacționează cu o baza de date (JPA, Entity Framework), atunci cam ai nevoie de setteri pentru operația de Update. |
Anunturi
▶ 1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users