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

Uitati-va de exemplu la QPixmap si explicati cit de prosti sint aia ca nu te obliga sa initializezi obiectul in constructor.

Ba, toti constructorii initializeaza QPixmap intr-o stare valida.

Nu in sensul definit de OC

framework-urile, bibliotecile, containerele generice, astea sunt lucruri diferite ca scop.

Astfel de componente sunt gandite pentru a putea fi utilzate intr-o varietate de situatii greu de controlat de catre vendor.

Pe cand in softul tau ai cerinte mai specifice, si scopul aici e de a limita sursele de greseli.

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

Acesta*** este unul dintre motivele principale pentru care in general e bine sa nu leakuiesti (API leak) in clasele tale clase ale unui framework folosit, ci sa incapsulezi/izolezi ermetic aceste frameworks/biblioteci. Alt motiv important este evitarea vendor lock-in****.

*** mentinerea intr-un state valid a tuturor obiectelor

**** evitarea vendor lock-in nu e ceva absolut, ci trebuie privit ca o portita de scapare in caz de urgenta; bineinteles ca daca te uiti la un cod asa cum e el momentan, mereu vei fi "locked" de unul sau mai multi vendori, de la sistemul de operare pana la limbajul de programare; ideea e alta: cat de usor poti inlocui orice vendor. daca trebuie sa iei la rand tot codul ca sa scapi de un vendor, atunci esti locked; daca trebuie sa inlocuiesti "doar" biblioteca standard ca sa treci de la windows la BSD, atunci nu esti locked. "Doar" e amuzant aici, normal ca ar fi o groaza de munca, dar vorbim in termeni relativi, comparat cu "cealalta situatie" in care ai fi locked.

Exemplu de metoda care leakuieste detalii de implementare: Site::getDomains() : vector<string>. Problema aici e ca orice apelant iti poate corupe obiectul. Analog si cu QT sau cu orice alt detaliu de implementare. Frameworkurile/bibliotecile ar trebui sa fie doar detalii de implementare - dar uneori are sens sa incalci acest principiu. De exemplu as leakui fara griji un BigNumber dintr-o biblioteca matematica intr-un proiect in care BigNumber e foarte aproape de core domain.

Edited by OriginalCopy, 01 May 2019 - 22:24.

Nu se pune problema de vendor lock-in cind dai 500 de euro pe luna de developer. Atunci deja ti-ai ales destinul, probabil dupa o atenta analiza a optiunilor de pe piata...

Oricum daca validitatea unui obiect si robustetea codului sta intr-o initializare de juma de ora in constructor ceva e horribly wrong

Dar si daca n-ar fi vorba de asa ceva, ci de exemplu ai nevoie de o clasa care tine datele din buletin. Nume, prenume, cnp, etc, ce faci, un constructor cu 10 parametri obligatorii ca sa obtii un obiect “valid”?

Mosotti, on 01 mai 2019 - 22:24, said:

De acord. Such is life.

Mosotti, on 01 mai 2019 - 22:24, said:

La modul serios, nu mi s-a intamplat. In 99% din cazuri, daca te uiti mai atent la cerinte, ai revelatii gen "defapt, numele, prenumele si data nasterii vin de la instanta Person pe care am avea-o deja daca am introduce-o, si apelul s-ar reduce la new Buletin(person, ...)", si tot asa, pana cand reduci numarul de parametri la un numar decent.

Dar da, trebuie sa te uiti mai atent la cerinte si sa iti pese de detalii, nu sa bagi rapid ca indienii cod ca carbunele in locomotiva cu abur.

OriginalCopy, on 01 mai 2019 - 22:07, said:

Definition: A vector of dimension n is an ordered collection of n elements, which are called components.

Tinand cont de cele de mai sus, eu am inteles , ca  de fapt initial ai un vector cu dimensiune de zero elemente(conform definitiei tale) .(adica starea 1)
Ce poti face cu un vector gol ? Pai mai nimic. Ca sa faci ceva cu el, atunci trebuie sa-i schimbi starea .

Insa noua starea nu se mai potriveste cu definitia vechi stari pe care ai dat-o tu.(pt ca un vector cu N elemente este o alta stare decat un vector gol care este starea initiala de "invalid state")
De fapt reprezinta evolutia unui obiect din starea 1("invalid state") catre starea 2("valid state").Adica de fapt ai un container care a fost initializat in "stare invalida" (zero componente) ca apoi  sa fie populat catre o stare valida(N componente) prin intermediul  constructorului implicit.
Privind dpdv al al unui vector cu N elemente putem spune ca vectorul tau care are zero elemente este un obiect instantiat in "invalid state"
Adica ceva de genul:

MyVector myvector = new MyVector(); //zero elemente
myvector.add(data); //autosize la lenght()-ul lui data

Si dam peste ce ziceam eu in posturile anterioare(vezi exemplul meu cu containerul Table) Si este normal sa fie asa doarece un vector este un container. Iar containerul este o clasa care instantiaza la cererea programatorului obiecte in stare "nevalida" cat si obiecte in stare "valida".

Imi mentin afirmatia ca starea de  "validate/nevaliditate" este data  de interpretarea personala a business-logicului de catre programator.
Dpdv tehnic constructorii creaza un singur lucru: obiecte.

Quote

Deja aici vorbim clar de design patterns.Doarece elaborarea  unui cod pe baza unui design patterns nu se poate face repede (ce trebuie alocate ore bune pt analiza)
deja ce spui tu nu mai depinde doar de programator ci si de project manager(daca este dispus sa aloce timp sau se astepte un cod de calitate).
Daca programatorul care doreste implementarea prin design patterns nu este si seful proiectului, atunci sperante desarte, doarece orice manager vrea un singur lucru:
programul sa fie cat mai repede realizabil si in daca se poate cat mai repede fatza de dead-line ca project managerul sa-si ia bonusurile salariale.

Din aceste motive tocmai  se merge pe anti-patternul  de  "vendor lock-in" si culmea este ca se face presiuni pt indeplinirea acestui antipattern.

Iar implementarea acestui anti-pattern poti sa-l observi si tu cu multa usurinta  atunci cand se scot pe piata jocuri neterminate cu buguri din versiuni alpha cu crash-uri de NullPointer Exception sau memory leak.Vezi lista de jocuri AAA care au avut si inca au aceste probleme, doarece au mers pe anti-pattern si asta pt ca au fost obligati  de management sa mearga asa.

Tu vorbesti fie de un domeniu de nisa, cercetare  sau  in domeniul invatamantului, unde timpul nu inseamna bani , altfel in domeniul de productie unde toate proiectele
vin mai in gluma mai in serios cu dead-line:ieri,  sa vezi ce presiune se pune pe tine de la managementul superior.

Cat despre partea de memory leaking,  sunt probleme doar daca lucrezi intr-un limbaj ce nu are managementul automat al memoriei.
Un altfel de limbaj ar presupune ca  echipa de dev sa investeasca timp serios in cod review, patching, refactoring ale unor sectiuni cu potential periculos, sa zicem
ori astea i-au timp si ultimul lucru pe care un project manager ar vrea sa vada este un sprint de 2 saptamani dedicat pt astfel de chestii. (vorbesc dpdv al managerului, nu al programatorului).
Singurul caz unde ar merge asa ceva ar fi daca project managerul a fost inainte programator si intelege necesitatea unor astfel de sprinturi, dar daca project managerul
este ASE si n-are nici o treaba cu programarea, foarte greu sa gaseste intelegere la astfel de oameni.

Probabil o sa spui ca asta tin de management si nu de realizarea codului.Problema este ca in softwareul de productie, intotdeauna  softwerul rezultat reprezinta
actiunea directa a mangerului asupra proiectului, implicit a produsului final si intotdeauna  dupa modul de comportare a variantei release-candidate poti sa-ti dai
seama daca managerul proiectului este programator sau  nu.

Edited by Iulius-Foyas, 02 May 2019 - 05:05.

Iulius-Foyas, on 02 mai 2019 - 05:01, said:

Cine vorbeste despre memory leaking?

TS030, on 30 aprilie 2019 - 23:41, said:

Dar de ce nu e OOP?  

OriginalCopy, on 01 mai 2019 - 11:41, said:

Adica vrei sa zici ca "exista exceptii".

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

Nu te forteaza sa verifici nimic, doar iti muta posibilitatea.

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

Pentru ca aia e cererea si logica respectivului cod, nu pentru ca ar fi vreo buna practica sau ceva de genul.

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

Cand vii cu anumite definitii, iar dupa aia cu exceptii, se pare ca nu-i.

Edited by DemocracySucks, 02 May 2019 - 12:43.

DemocracySucks, on 02 mai 2019 - 12:40, said:

Huh? Trebuie sa explic ce este OOP?
http://www.stroustrup.com/whatis.pdf

Iulius-Foyas, on 02 mai 2019 - 05:01, said:

Ouch! Ia zi, cinstit, de unde-ai luat definitia aia?

Un obiect container care contine zero elemente este cat se poate de valid. Urmatoarea constructie:

std::vector<int> my_vec{};

Initializeaza corect si complet un obiect de tip std::vector<int>.

DemocracySucks, on 02 mai 2019 - 12:40, said:

Nu stiu ce altceva sa-ti spun, decat sa citesti cu atentie:

OriginalCopy, on 01 mai 2019 - 22:07, said:

Dar vei avea dificultati, din cauza dezvoltarii profesionale precare.

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

Este valid doar daca business-logicul cere doar un container gol cu care sa nu face nimic.
Insa daca business-logicul cere un container care sa contina elemente atunci un vector gol este in stare nevalida, si pt a trece in stare valida trebuie sa fie introduse elemente.

MyVector myvector = new MyVector(); //zero elemente
myvector.add(data); //autosize la lenght()-ul lui data

Quote

Iulius-Foyas, on 02 mai 2019 - 20:48, said:

Gresit. Un vector este valid din momentul in care i se executa constructorul.

Un obiect business-logic precum un Site ar putea fi valid daca (printre altele) are unul sau mai multe domenii asociate. Dar, daca stocheaza domeniile intr-un vector (sa zicem, vector<string>) acesta - vectorul - va fi valid din momentul in care i se executa constructorul - al vectorului - si nu cand se termina initializarea obiectului Site.
In exemplul tau, cand ai ajuns la:

myvector.add(data);

myvector este evident valid; d-aia poti sa-i apelezi - cu un rezultat bine definit - metoda add().

TS030, on 02 mai 2019 - 21:25, said:

Nu, nu este inca valid pt ca nu pot sa fac  nimic cu un vector gol.
Adica:

std::vector<int> myvector;
myvector.at(5);
Exception thrown at 0x7564C6F2 in ConsoleApplication2.exe: Microsoft C++ exception: std::out_of_range at memory location 0x004FFDEC

Practic tu imi spui ca orice container(clasa) care este instantiata de constructorul implicit este valida, lucru fundamental gresit dpdv al OOP-ului si asta
pt ca validatea /nevalidatea depind daca obiectul respectiv respecta sau nu criteriul de business-logic dupa care a fost creat.

Ba mai mult, uite ce spune  OriginalCopy:

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

Ghici ce ? In exemplul de mai sus, nu pot apela myvector.at(index) pt ca intai trebuie sa apelez  myvector.push_back(number)
adica vectorul meu gol, instantiat prin constructorul implicit este invalid.

Eu sunt si mai restrictiv decat OriginalCopy si zic:
"state invalid e atunci cand obiectul nu este conform cu business-logicul pe care il deserveste.In momentul in care obiectul devine conform cu business-logicul
pe care il deserveste atunci devine valid.
Starea de validate/nevalidate este data  de interpretarea personala a business-logicului de catre programator."

Diferenta intre cele zise de mine si OC este ca OC spune ca daca poti accesa in orice ordine metodele publice ale unui obiect atunci este considerat a fi valid, iar eu
zic ca obiectul este valid doar daca poate fi accesat conform business-logicului dupa care a fost creat. Asta inseamna ca daca prin business-logic am decis ca
obiectul este valid doar daca poti accesa in orice ordine  o metoda publica, atunci picam pe ce spune OC,

Insa daca prin business-logic am decis  ca obiectul trebuie  sa fie accesat doar  astfel: metodaA->metodaC->metodaF->metodaB ,
atunci daca obiectul  mai poate fii accesat si altfel atunci este invalid (doarece nu este conform cu  business-logicul specificat).

Ce spune OC este in caz particular a ce spun eu.

Edited by Iulius-Foyas, 03 May 2019 - 00:55.

Iulius-Foyas, on 03 mai 2019 - 00:51, said:

Cum nu poti sa faci nimic cu un vector gol? Poti sa adaugi elemente; poti sa-i cresti capacitatea; poti sa verifici daca este empty, poti sa iterezi prin toate cele zero elemente, poti sa aplici algoritmi...
Iar dupa logica ta:

Iulius-Foyas, on 03 mai 2019 - 00:51, said:

un vector cu un numar arbitrar de elemente N este invalid, pentru ca poti apela

myvector.at(N);

si obtii aceeasi exceptie. Hai sa nu confundam erorile crase de programare cu argumentele tehnice.

Iulius-Foyas, on 03 mai 2019 - 00:51, said:

Amesteci rau de tot lucrurile, si n-ar strica sa incepi prin a invata ce este OOP. Ai citit articolul indicat de mine? In continuare exemplele tale n-au urma de OOP...

Trebuie sa te asiguri ca toti constructorii stabilesc setul de invarianti corespunzator acelui tip de date. Trebuie sa te asiguri ca orice metode mentin setul de invarianti corespunzator acelui tip de date. Orice altceva este greseala de logica.


Un tip de date precum vector nu are nici un "business logic".

Edited by TS030, 03 May 2019 - 01:13.

TS030, on 03 mai 2019 - 01:10, said:

Dar adaugare de elemente si cresterea capacitatii sunt metode publice care nu pot fi accesate in orice ordine, de aici conform celor spuse de OC  un vector gol este invalid.

Quote

Cum, cum ? pot sa verific daca un vector gol este empty ?
pot sa iterez prin toate cele zero elemente ale unui vector gol ?
pot sa aplica algoritmi  pentru un vector gol ?  

Quote

Dap, pt ca starea de invalidate/validate este subiectiva si  in realitate exista doar obiecte si pici pe ce ziceam eu in posturile anteriore.

Quote

Pai ce facem ? Ne suparam atunci cand suntem batuti cu popriile supozitii ?

Quote

N-ar strica  sa incepi prin a invata ce este OOAD si cum se aplica OOP-ul in contextul OOAD

Quote

Ba din contra, ele sunt OOP real modelat prin OOAD si nu din lumea academica teoretica, unde se prind fluturi ideali cu prastia.

Quote

ba da, business-logicul unui vector este de stoca date dinamic si de a le deservi atunci cand programatorul doreste.
Tu tocmai mi-ai spus ca un container nu are nici un business-logic(adica nici un criteriu/motiv de a exista) , cand OOP-ul inseamna implementarea de business-logicuri folosind containere.

Edited by Iulius-Foyas, 03 May 2019 - 01:29.

Nu poti apela orice metoda publica asupra unui vector gol -> conform  OriginalCopy-> obiectul este invalid("invalid").

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

Insa starea de valididate este cum spuneam subiectiva.Constructorii fac un singur lucru:construiesc obiecte atata tot. Iar pana acum Limbajul C++ imi spune ca exista pot crea
un obiect aflat in stare "invalida -conforma  OriginalCopy" .De fapt orice limbaj OOP permite asta ,doarce starea de invaliditate/validitate depinde daca obiectul este conform business-logicului creat  si nu daca respecta nu stiu ce cutume academice "Stroussstrupiene"

Edited by Iulius-Foyas, 03 May 2019 - 01:56.

Iulius-Foyas, on 03 mai 2019 - 01:51, said:

Nu am spus asta asa. Am nuantat.