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

Cand este necesar un obiect intantiat in stare "nevalida" ?  cand  starea de "validitate" a obiectului  depinde de alte obiecte care la timpul curent nu exista.

Exemplu: obiectul table nu poate fii instantiat direct in stare "valida":

Table table  = new Table(); //instantiere in stare "nevalida"
for(int i =0; i<dataSet.size();i++){
	Row row = new Row(); //intializare in stare "nevalida"
	for(int j = 0; j <dataSet.get(i).size(); j++) {
	   Object value =  dataSet.get(i).get(j).getValue();
	   Cell cell = new Cell(value); // initializare in stare  "valida"
		row.add(cell);
	}
	//s-a finalizat definirea completa a obiectului Row din interatia curenta
	table.add(row);
}
//s-a finalizat  definirea completa a obiectului Table din interatiile  anterioare
//prelucrari in continuare cu obiectul Table complet validat

Edited by Iulius-Foyas, 30 April 2019 - 22:06.

Ai putea spune foarte usor:  "pai pot sa pun ambele for-uri in interiorul obiectului table  intr-o metoda si sa invoca metoda in constructor si gata"
adica:

Class Table() {
//campurile clasei
private DataSet ds;

public Table(DataSet ds) {
	 this.ds = ds;
	 processDataSet();
}

//alte metode publice

//alte metode private
private void processDataSet(){
	 //codul din exemplu anterior aici
}
}

altundeva:

//obiectul dataSet vin din alte obiect
Table table = new Table(dataSet);

Da, se poate asa ceva.Insa daca am un DataSet de 3 milioane de linii si 120 de coloane,
din care doresc  un subset de doar 300 de linii si 4 coloane , atunci varianta anterioara cu buclele for exteriorizate, te avantajeaza.
Insa este drept, ca ai putea face si astfel:

Table table = new Table(dataSet, maxNumberOfRows, maxNumberOfColumns);

Sunt situatii cand instantierea intr-o stare "nevalida" te poate avantaja dar si situatii cand instantiera in stare "valida" te poate avantaja
De aceea aceasta  "validitate" este subiectiva.
Uneori programatorul poate considera ca starea valida al unui obiect sunt totalitatea operatiilor necesare doar pt instantiera obiectului.
Alterori acelasi programator poate considera ca stare valida al unui obiect sunt totalitatea operatiilor necesare doar pt instantiera si pregatirea obiectului
in vederea prelucrarilor ulterioare.
Insa de multe ori programatorii isi creaza clase care pot fi folosite pt a instantia obiecte "atat in stare valida"  cat si in stare "nevalida" in
functie de cum doreste sa foloseasca obiectele  instantiate, ca produse  "valide/nevalide" ale aceluiasi prototip de clasa.

Caz clasic in acest sens: trebuie sa creezi un modul nou intr-un proiect vechi unde s-a lucrat pe un anumit stil si anumita filosofie iar tu (prin regulile interne de scriere a codului)
trebuie sa creezi acel modul in alt stil si alta filosofie.
Atunci creezi un clasa cu rol de "bridge adapter" care permite ca inputurile proiectului vechi sa fie introduse pe acea filosofie si outputul  sa fie scos pe noua filosofie, si atunci
iti trebuie astfel de clase care pot intantia si obiecte "nevalide" si obiecte "valide".

In fond starea de validate o determina programatorul si nu este batuta in cuie.

Edited by Iulius-Foyas, 30 April 2019 - 22:30.

N-am citit tot pomelnicul de postari, dar pot spune doar ca metode ca load...Data() n-au ce cauta ca metode publice. Daca e, le apelezi intern, cand e nevoie de informatii in metode care fac lucruri utile.

Eu as zice si ca nu exista nici o scuza pentru instantierea unui obiect intr-o stare invalida.
In momentul in care constructorul s-a executat, obiectul este valid - si va continua sa fie, pana la distrugere. Orice altceva este o eroare de design.

OriginalCopy, on 30 aprilie 2019 - 22:41, said:

Pai daca n-ai citit nu poti spune.Te invit sa le recitesti.

Quote

gandirea ta cat si a lui TS030 sunt de fapt gandiri in paradigme imperative insa folosind cod OOP, ceea ce este in opinia mea personala   periculos atunci
cand dezvolti cod OOP.Adica este periculos atunci cand dezvolti cod OOP in paradigma imperativa, in loc sa fie facuta in paradigma OOP .Daca o sa lucrati cu specialisti
OOP (candva in viitor) o sa vi se atraga imediat atentia asupra acestor aspecte.

La revedere.

Edited by Iulius-Foyas, 30 April 2019 - 23:30.

As aprecia daca ai face mai putine judecati personale. Nu vreau sa zic mai multe, ca n-are rost.

Ca fapt divers, exemplele cu Table nu sunt OOP.

OriginalCopy, on 30 aprilie 2019 - 20:40, said:

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

Definiti state invalid/stare invalida.

DemocracySucks, on 01 mai 2019 - 09:48, 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.

Unde intra constructorul in joc: daca nu reusesti sa construiesti un obiect valid, mai bine arunci o exceptie, atunci macar nu mai ai un obiect in apelant, decat sa continui sa operezi pe un obiect care va interactiona (cel mai probabil) cu alte obiecte si va corupe date cine stie pe unde.

dexterash, on 30 aprilie 2019 - 01:21, said:

Mea culpa
Cratimile sunt o problema veche,

@Iulius-Foyas: Ne omori cu pomelnicele astea. Te rog pune-le in spoiler!

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

Edited by elbjorn, 01 May 2019 - 10:05.

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

Serios? Si cum zici ca ai face o structura de date de tip container ce poate fi inclusiv goala ca varianta perfect valida(ca de aia e container) si ar respecta ce zici tu? In conditiile in care ai sa zicem o metoda get() care evident trebuie sa functioneze doar daca exista ceva de returnat(iar o valoare precum null e perfect valida ca valoare)?

Un container gol e intr-o stare valida. Un exemplu ipotetic de cum ar putea fi un container gol intr-o stare invalida intalnim in C:

struct IntVector* vector = malloc(sizeof(IntVector));
vector->size = 0; //pana nu fac asta nu pot folosi adecvat vectorul, constructorul ar trebui sa rezolve acest detaliu (si o face in mai toate bibliotecile limbajelor OOP).

Edited by dani.user, 01 May 2019 - 11:23.

DemocracySucks, on 01 mai 2019 - 11:04, said:

O incapsulez in asa fel incat ma pot asigura ca e mereu valida.

dani.user, on 01 mai 2019 - 11:21, said:

Evident ca e stare valida. Numai ca asta:

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

pica!

Cam trebuie sa folosesti o testare gen if(!(container.isEmpty()) inainte de a apela o metoda ce returneaza ceva din container, gen get()

Decat acel if prefer sa-mi returneze get un option<ceva>.

DemocracySucks, on 01 mai 2019 - 11:38, said:

Vorbim despre lucruri diferite.

Acest topic, postarea #1, da de inteles ca e vorba despre ceva specific de business, nu containere generale.

Eu despre aceasta situatie vorbesc.

Tu poti sa iti deschizi topic separat in care sa vorbesti despre orice doresti tu.

dani.user, on 01 mai 2019 - 11:40, said:

Da, asta e o solutie foarte eleganta, pentru ca il forteaza pe apelant sa faca verificarea.

dani.user, on 01 mai 2019 - 11:40, said:

Adica sa complici codul aiurea, un container sa-ti returneze un alt container, iar in final de verificare tot nu se scapa(doar muti problema si faci codul mai complex).

Solutia voastra "eleganta" deja da dureri de cap prin java unde au bagat mizeria de Optional<T>

Edited by DemocracySucks, 01 May 2019 - 11:53.

DemocracySucks, on 01 mai 2019 - 11:48, said:

Tocmai asta e ideea, sa nu scapi de verificare, sa te asiguri ca verificarea e acolo in apelant. Dar asta e o problema diferita de subiectul acestui topic.

Exemplu mai bun e: Un site are o lista de domenii, si are cel putin un domeniu. Atunci introduci clasa Site. Deasemenea, ai metode de adaugare sau de stergere domenii, iar cea de stergere se asigura ca nu poti sterge ultimul domeniu.

Exemplu usor de inteles ce inseamna sa ai un obiect mereu valid.

Despre asta e acest topic - si despre rolul constructorului.

"Site" este un container (in acest exemplu), dar nu unul generic al carui state valid e si sa fie gol, ci unul specific cu constrangeri din domain logic.

Edited by OriginalCopy, 01 May 2019 - 11:57.

Ideea de baza este ca orice clasa/tip de date are un set de invarianti, care sunt stabiliti in constructor si raman valizi orice metode ai apela, pana la distrugerea obiectului.
Un pointer ar putea pointa catre o zona de memorie alocata sau nullptr.
Un container ar putea contine 0 sau mai multe elemente.
Un Site ar putea contine 1 sau mai multe domenii.

Daca trebuie sa mai apelezi o metoda pentru a avea un obiect valid... ai o problema.

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