Dark-Snake1992 ha detto:
quindi? alla fine chi è quello che ce l'ha più lungo?
C'é chi ama discutere, oltre che fare help desk a voi.
stoner ha detto:
Ancora con i puntatori? Se voglio che l'handle sia visibile all'esterno metto un metodo get ma non fornisco un metodo set. Così posso VEDERLO ma non posso MODIFICARLO.
stoner, non stai afferrando ciò che dico. Non sto dicendo che così NON E' POSSIBILE CREARE BUONE LIBRERIE, ma che è un modo di fare ridondante, una filosofia che parte da basi errate. Se non prevedi sto metodo get, io non posso accedervi in modo canonico. Ritengo sia una filosofia sbagliata; non è che ti ho chiesto di listare i modi per fare buoni programmi lo stesso. =)
stoner ha detto:
L'esperienza mi insegna che il 99,99% dei problemi è proprio dovuto all'utente.
Quindi il C++, si potrebbe dire, è un linguaggio da baby sitters.
E' questo ciò su cui non concordo. Il limitare l'utente per salvarlo dai suoi stessi errori; certo, forse è più difficile sbagliare se si usa private, perché l'uso "scorretto" (anche quando non lo sarebbe) genera errori a compile-time, ma l'uso di convenzioni rigide porta allo stesso risultato senza limitare l'utente consapevole.
stoner ha detto:
Si, ma così è inconsistente. Io definisco l'attributo pubblico, tu lo modifchi come ti pare, dentro ai membri che accedono a tale attributo faccio il controllo di integrità , cosa ci ho gudagnato? Ho spostato un controllo dalla funzione set a tutte le funzioni membro che accedono a quell'attributo, così se domani decido che i mesi vanno da 3 a 11 devo modificarmi tutto il resto, invece che un'unica funzione.
No, tu stai facendo il percorso logico che fa un programmatore che segue quella filosofia.
Lascia che ti spieghi in modo più approfondito la diversa filosofia di cui parlo.
Supponiamo di avere, in pseudocodice, una classe come quella di cui parli; in stile OOP del C++ faremmo:
Codice:
class Month {
private int month;
bool setMonth (int newmonth) {
if(1<=newmonth<=12) { // Se rientra nel range setta e ritorna true
this->month = newmonth;
return true;
}
return false; // Altrimenti torna false.
}
int getMonth() {
return this->month;
}
}
Che succede? Che comunque vada, anche se devo settare month con dei literal che sono sicuro saranno validi, devo usare la set. Che se voglio fare delle test unit con dati errati, devo modificare la classe, altrimenti si fermerà alla set e non potrò vedere come si comporta il codice successivo (lascia perdere il controllo d'integrità che assicura la bontà dei dati); insomma, sono limitato, e in caso di classi più complesse potrei essere impossibilitato a fare un uso particolare o insolito, ma non errato, della classe. In più, non ho modo di evitare l'overhead delle chiamate a metodi, neanche per una semplice printf.
Invece usando uno stile basato sulle convenzioni:
Codice:
class Month {
int __month; // Il doppio underscore significa che è a uso interno e non andrebbe manipolato direttamente.
bool setMonth (int newmonth) {
if(1<=newmonth<=12) { // Se rientra nel range setta e ritorna true
this->month = newmonth;
return true;
}
return false; // Altrimenti torna false.
}
}
Uso setMonth quando ho necessità di fare il controllo di integrità . E se voglio realizzare test, usare literal evitando l'overhead del test d'integrità , lo faccio con facilità .
Un'altra cosa che sfugge ad un programmatore non abituato all'uso di questi linguaggi, è che le convenzioni sono molto più sentite che in altri linguaggi. Non è come la notazione ungara che non la conosce nessuno, per esempio. TUTTI i programmatori Python sanno che _attributo indica che attributo è a uso interno, è privato. E' scritto nel manuale, è un concetto allo stesso livello del for.
stoner ha detto:
Sono io che scrivo la classe, e sono io a decidere se devi o non devi accedere ad un menbro, e sono sempre io che definisco le modalità di accesso. Il motivo è semplice, preservare l'integrità dei dati. E poi i motivi te li ho elencati 200 volte sopra, rileggiteli se te li sei scordati.
A scapito della flessibilità . Non è che non concordo con il preservare l'integrità , è che non concordo sull'imporlo anche quando non è necessario.
stoner ha detto:
Allora che è tutto questo macello sul private? Tu dici che se vuoi puoi modificarlo, allora io ti do la classe come l'ho pensata io e come credo che sia giusto che debba essere implementata, poi se tu vuoi modificarla sei libero di farci quello che vuoi.
Filosofia di programmazione.
stoner ha detto:
Scaricati qualsiasi framework o libreria in un qualsiasi linguaggio OOP completo e vedrai che nessun programmatore specifica tutto a public. Non devi neanche andare tanto lontano, sfoglia i sorgenti della libreria uSock di BlackLight o la libreria xmlpp di meh. Se non sei contento vai su SourceForge o CodeProject e cerca.
Certo, nei linguaggi che prevedono l'incapsulamento di quel tipo lo usi, giustamente. Non era questo che mettevo in discussione, facevo un discorso astratto.
stoner ha detto:
Magari sono anni che stiamo sbagliando tutti, grazie per averci illuminato
In effetti, questo modo di effettuare l'incapsulamento è al centro di una polemica che va avanti dagli anni 70. =)
