Muncă multă în constructor - da sau ba?

Iulius-Foyas, on 03 mai 2019 - 13:04, said:

Un vector ca atare este valid si gol.

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.

OriginalCopy, on 03 mai 2019 - 13:09, 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."
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.

Iulius-Foyas, on 03 mai 2019 - 13:36, 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.

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.

Mosotti, on 03 mai 2019 - 14:18, said:

De acord. Depinde foarte mult de detalii, asta am si zis in primul meu raspuns aici pentru @OP.

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.

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).

Iulius-Foyas, on 03 mai 2019 - 12:53, said:

cine este programator? Tu sau IDE-ul ?

Toata discutia asta confirma inca o data stupiditatea functiilor cu nume substantiv

OriginalCopy, on 03 mai 2019 - 13:43, said:

Pai in aceasta noua paradigma lucrurile se schimba radical,discutam altfel.

Iulius-Foyas, on 03 mai 2019 - 17:45, said:

Tu trebuia sa citesti postarea #1 si sa o intelegi, atunci ai fi discutat despre ceea ce tot discutam noi, in loc sa trollezi.

TS030, on 01 mai 2019 - 13:04, said:

Orice clasa, orice metoda? Pe bune?

TS030, on 01 mai 2019 - 13:04, said:

Are un "set" de... pe langa setul ala poate sa mai aiba si alt set care sa nu se supuna ideii de "invariant" din c++?

TS030, on 01 mai 2019 - 13:04, said:

O gramada de metode(apropo de "orice metoda") dau eroare pe nullptr. Ca sa eviti trebuie sa faci verificare prealabila.

TS030, on 01 mai 2019 - 13:04, said:

Exact CE PROBLEMA?

TS030, on 01 mai 2019 - 13:04, said:

In lumina:

OriginalCopy, on 01 mai 2019 - 09:54, said:

Stii ce ai acolo? Trei functii care trebuie apelate intr-o anumita ordine!

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:

Exact la fel cum un vector poate sa fie gol, la fel ai si diverse structuri de date ale unei aplicatii (business sau te miri ce) care trebuie sa fie ori goale, ori in te miri ce stare anume pentru a se putea efectua anumite operatiuni. Daca ai avea experienta reala de programare, ai intelege destul de usor asta.

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.

Despre ce vorbim?

 a.gif   90.72K   17 downloads

TS030, on 02 mai 2019 - 14:20, said:

Nu. Trebuia sa explici de ce codul respectiv nu e OOP. Evident ca n-ai ce sa explici. Dupa ce o sa inveti OOP ai sa intelegi de ce e OOP.

Mosotti, on 03 mai 2019 - 14:18, said:

dupa pararea mea , validitatea unui obiect  trebuie sa fie legata de indeplinirea business-logicului pt care a fost creat obiectul.In acest context rareori, un obiect valid ar putea fi creat de un constructor
implicit si de multe ori indeplnirea business-logicului ar depinde si de alte obiecte.

OriginalCopy, on 03 mai 2019 - 14:23, said:

Pai evident. Numai ca ai ajuns de la afirmatii categorice pe ton de profesor, la "depinde, depinde, depinde: ...

Iulius-Foyas, on 03 mai 2019 - 17:59, said:

De fapt, daca ne gandim bine, nu exista "validitatea obiectului" ci validitatea utilizarii obiectului.

DemocracySucks, on 03 mai 2019 - 17:54, said:

iesi cu el:

Iulius-Foyas, on 03 mai 2019 - 17:45, said:

la o bere, si iti va desena ca la destepti, ca el a inteles despre ce vorbim. Tu tot bati campii.

DemocracySucks, on 03 mai 2019 - 18:03, said:

De fapt, nici "constructor" nu e corect, dar noi tot asa ii zicem si tot la acelasi lucru ne referim, si culmea, ne intelegem unii cu altii. "Constructorul" nu construieste nimic, obiectul e deja construit.

Un nume mai bun ar fi "Initializator" sau ceva de genul.

Mosotti, on 03 mai 2019 - 14:18, said:

Si aici ne lovim de modificatorii de access private/public/protected (daca vreau de exemplu ca anumiti membrii ai clasei /metode sa fie accesati in anumit fel)
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  in cazul asta poti considera ca orice obiect creat  de un  constructor (fie el si implicit) poate fi socotit a fi valid pt a fi utilizat.
Insa validitatea obiectului este complet diferita de validitatea utilizarii obiectului.

Edited by Iulius-Foyas, 03 May 2019 - 18:12.

Iulius-Foyas, on 03 mai 2019 - 18:06, said:

Getterii nu sunt atat de evil, setterii sunt, iar @OP stie asta:

jegmihai, on 29 decembrie 2018 - 23:26, said: