[Programmazione Object Oriented] Buone norme..

[shang84]

Salve,
volevo sapere quali sono le buone norme di programmazione object oriented.

Intendo dire:

è bene che una classe abbia un costruttore non void all'interno del quale chiama i vari metodi (propri della classe) che inizializzano i diversi attrbuti private dalla classe.

Questi metodi in base al tipo di parametri passati al costrutture non void inizializzano gli attributi della classe in modo diverso.

Vengono chiamati in un'ordine preciso, altrimenti il programma crasha per Segmentation Fault in quanto il metodo 2 lavora sugli attributi inizializzati dal metodo 1 e cosi via.

Non chiedo questo perchè non mi gira il programma, ma bensi per far si che il codice che sto producendo sia il + mantenibile e il -caotico possibile.

Classe A {
  private:
  attributo 1; //puntatore a dato da allocare dinamicamente tramite metodo1
  attributo 2;
  public A(parametro){
       metodo1(parametro);
       metodo2();
      //questo è l'ordine preciso in cui i due metodi devono essere chiamati
    // altrimenti a run time metodo2 che lavora su attributo1 (che ad es è un puntatore)
  // fa crashare il programma per segmentation fault in quanto l'attributo
  // non è stato allocato dinamicamente 

 }
private metodo1(p){...};
private metodo2(){...};

}

[breiko]

è bene che una classe abbia un costruttore non void all'interno del quale chiama i vari metodi (propri della classe) che inizializzano i diversi attrbuti private dalla classe.

Il costruttore non ha tipo di ritorno quindi non esiste costruttore void o non void.

Poi va bene inizializzare le variabili di istanza di un oggetto con il costruttore, è l'utilizzo classico.

Nel tuo caso specifico però non ho chiara la situazione e quindi non posso darti altre soluzioni.

Ciao

[franksisca]

allora, per buona norma una classe ben progettata deve aver un:
toString();
equals();
compareTo();
le variabili private e i metodi di accesso alle variabili set e get.

Per altre specifiche, non credo siano necessarie, al massimo ti consiglio di implementare cloneable e ridefinire il metodo clone();.

[end.is.forever]

Originariamente inviato da franksisca

allora, per buona norma una classe ben progettata deve aver un:
toString();
equals();
compareTo();

Stai scherzando vero?

[franksisca]

forse ho dimenticato di specificare in java


perchè in JAVA è così

Originariamente inviato da franksisca

allora, per buona norma una classe ben progettata deve aver un:
toString();
equals();
compareTo();
le variabili private e i metodi di accesso alle variabili set e get.

Per altre specifiche, non credo siano necessarie, al massimo ti consiglio di implementare cloneable e ridefinire il metodo clone();.

questo è lo stato dell'arte (buono per l'esame )

[franksisca]

Originariamente inviato da trias

buono per l'esame

[end.is.forever]

Originariamente inviato da franksisca

perchè in JAVA è così

Ma in nessun linguaggio

[fek]

Originariamente inviato da franksisca

allora, per buona norma una classe ben progettata deve aver un:

Una classe ben progettata deve fare nulla di piu' di quello che le e' richiesto, in qualunque linguaggio

Quindi se toString() non e' richiesto, non lo si scrive. Se per l'oggetto non ha senso essere clonato, non si implementa Cloneable. E cosi' via...

[franksisca]

Originariamente inviato da end.is.forever

Ma in nessun linguaggio

Non capisco cosa vuoi dire, magari in altri linguaggi non si chiamano in quel modo, ma il significato credo che sia da esplicitare in ogni oggetto, q eusto prp:

equals = ritorna tru se l'oggetto chiamato (a) è uguale all'oggetto chiamante (b), in java a.equals(b)

compareTo = ritorna un intero che individua l'ordine degli oggetti, sempre in java:
a.compareTo(b) =1 se a>b, =-1 se b>a, =0 se aè=b;
il toString() stampa l'oggetto.

Ripeto, in java si chiamano così, ma credo che siano delle otttime regole di lavoro ad oggetto.

[franksisca]

Originariamente inviato da fek

Una classe ben progettata deve fare nulla di piu' di quello che le e' richiesto, in qualunque linguaggio

Quindi se toString() non e' richiesto, non lo si scrive. Se per l'oggetto non ha senso essere clonato, non si implementa Cloneable. E cosi' via...

Vero, naturalmente, ma se mi vengono chiesti degli standard di scrittura di un oggetto, io quelli ce li metto sempre, anche se non mi servono, tanto non mi rubano più di 5 minuti, e se li guarderà qualcun'altro almeno qualcosa di comprensibile ci sarà.

[end.is.forever]

Originariamente inviato da franksisca

Non capisco cosa vuoi dire, magari in altri linguaggi non si chiamano in quel modo, ma il significato credo che sia da esplicitare in ogni oggetto, q eusto prp:

equals = ritorna tru se l'oggetto chiamato (a) è uguale all'oggetto chiamante (b), in java a.equals(b)

compareTo = ritorna un intero che individua l'ordine degli oggetti, sempre in java:
a.compareTo(b) =1 se a>b, =-1 se b>a, =0 se aè=b;
il toString() stampa l'oggetto.

Ripeto, in java si chiamano così, ma credo che siano delle otttime regole di lavoro ad oggetto.

Non sono norme di programmazione, sono particolari interfacce, quindi caratteristiche che alcuni elementi possono avere altri no.

Il metodo equals lo implementi quando per qualche ragione hai bisogno di confrontare due istanze di quella classe, compareTo quando le istanze di quella classe possono essere associate ad un insieme ordinato, toString (e ancora più raro) quando ti serve una rappresentazione sotto forma di stringa dell'istanza (quest'ultimo poi non lo si usa quasi mai, essendo inadatto a pattern di costruzione delle stringhe efficienti, e poi perchè molto spesso si preferisce delegare a classi apposite la conversione dato che non necessariamente è responsabilità della classe stessa).

Posso condividere il get dei campi privati, per il set già sono meno d'accordo, se hai un campo che è scrivibile e leggibile tanto vale che sia pubblico.
Questo a meno che tu non abbia bisogno di fare qualcosa al momento della scrittura/lettura, e anche qui (come per i 3 metodi di cui parli) si tratta sempre di casi particolari e non di norme.

[fek]

Originariamente inviato da franksisca

Vero, naturalmente, ma se mi vengono chiesti degli standard di scrittura di un oggetto, io quelli ce li metto sempre, anche se non mi servono, tanto non mi rubano più di 5 minuti, e se li guarderà qualcun'altro almeno qualcosa di comprensibile ci sarà.

Se un coding standard ti richiede di scrivere metodi anche se non ti servono non e' un buon coding standard e va modificato.

"L'unica riga di codice senza bug e' quella che non scrivi".

Non sono solo i 5 minuti che perdi per classe (che poi per 10 classi significano 50 minuti che puoi spendere magari semplificando il codice, per 100 classi sono gia' 500 minuti, quasi 10 ore, piu' di una giornata di lavoro). Quei metodi li paghi in termini di manutenzione del codice: se cambi qualcosa e il metodo che non usi non compila? lo devi modificare ad esempio; e se cambi l'implementazione della casse? devi cambiare anche quei metodi per riflettere la nuova implementazione, anche se non li usi da nessuna parte; e se li lasci scorretti? che senso avrebbe avere un'implementazione scorretta, nessuno.

Il codice deve esprimere solo e unicamente i concetti che servono alla risoluzione del problema e nient'altro.

[fek]

Originariamente inviato da end.is.forever

Posso condividere il get dei campi privati, per il set già sono meno d'accordo, se hai un campo che è scrivibile e leggibile tanto vale che sia pubblico.

Per buona norma e' sempre e comunque preferibile disaccoppiare i campi attraverso propert get/set, tanto che in linguaggi come C# questa norma e' diventata un costrutto del linguaggio.
La ragione e' disaccoppiare la semantica della proprieta' (ad esempio un contatore in una classe) dall'implementazione della proprieta' stessa (una variabile, oppure magari un ciclo, o quant'altro).
Disaccoppiare l'"interfaccia" dall'implementazione e' sempre una buona idea, perche' riduce gli errori.

Alcuni coding standard portano questo discorso al limite e richiedono che anche i campi privati (e non solo quelli pubblici) siano esposti attraverso property get/set.

[fek]

Originariamente inviato da franksisca

Non capisco cosa vuoi dire, magari in altri linguaggi non si chiamano in quel modo, ma il significato credo che sia da esplicitare in ogni oggetto, q eusto prp:

Come implementeresti compareTo() per una classe Complex che rappresenta numeri complessi?

Non per tutti gli oggetti (anzi per pochissimi, e per la precisione i value type ordinabili) ha senso un'operazione di comparazione.

[franksisca]

Originariamente inviato da fek

Se un coding standard ti richiede di scrivere metodi anche se non ti servono non e' un buon coding standard e va modificato.

"L'unica riga di codice senza bug e' quella che non scrivi".

Non sono solo i 5 minuti che perdi per classe (che poi per 10 classi significano 50 minuti che puoi spendere magari semplificando il codice, per 100 classi sono gia' 500 minuti, quasi 10 ore, piu' di una giornata di lavoro). Quei metodi li paghi in termini di manutenzione del codice: se cambi qualcosa e il metodo che non usi non compila? lo devi modificare ad esempio; e se cambi l'implementazione della casse? devi cambiare anche quei metodi per riflettere la nuova implementazione, anche se non li usi da nessuna parte; e se li lasci scorretti? che senso avrebbe avere un'implementazione scorretta, nessuno.

Il codice deve esprimere solo e unicamente i concetti che servono alla risoluzione del problema e nient'altro.

Sono d'accordo, infatti io molte volte non li uso, ma si parlava di standard.
Ora vi faccio un esempio:
Lo standard di progettazione di un software è questo(molto semplificato) diagramma UML,relazione e manuali, Implementazione, testing e pubblicazione.
Ora dimmi, fek, tu che sei un esempio per molti di noi, se tu nella tua vita lavorativa hai seguito questo sviluppo.
Io personalmente, ancora no, ma ritengo che come standard di progettazione vada bene.
ora, la stessa cosa succede per gli oggetti, almeno credo.
se devo fare un programma di inserimento in un database, è logico che il toString non lo uso, ma se mi chiedi come standard se ce lo metto, io allora ti rispondo di si, che come buona regola lo metterei.

[fek]

Originariamente inviato da franksisca

Sono d'accordo, infatti io molte volte non li uso, ma si parlava di standard.
Ora vi faccio un esempio:
Lo standard di progettazione di un software è questo(molto semplificato) diagramma UML,relazione e manuali, Implementazione, testing e pubblicazione.
Ora dimmi, fek, tu che sei un esempio per molti di noi, se tu nella tua vita lavorativa hai seguito questo sviluppo.

No, perche' questa metodologia di sviluppo (Waterfall) e' tutto fuorche' efficiente. Anzi, e' un metodo molto costoso, e assolutamente non ottimale, per scrivere codice e costruire software

Io personalmente, ancora no, ma ritengo che come standard di progettazione vada bene.
ora, la stessa cosa succede per gli oggetti, almeno credo.
se devo fare un programma di inserimento in un database, è logico che il toString non lo uso, ma se mi chiedi come standard se ce lo metto, io allora ti rispondo di si, che come buona regola lo metterei.

Le buone regole non sono teoriche, sono pratiche e pragmatiche. Una regola e' buona se mi fa risparmiare tempo di sviluppo, mi riduce l'incidenza dei difetti, mi aumenta la produttivita'. Scrivere toString() per tutte le classi anche se non serve, o peggio ancora tale metodo non e' definibile per tale classe, non mi fa risparmiare tempo di sviluppo (anzi), non mi riduce l'incidenza dei difetti (anzi), non mi aumenta la produttivita' (anzi).
Inoltre non segue la regola d'oro della programmazione: "Keep it simple". Ricorda che programmare significa gestire la complessita' di una soluzione, mantenerla al minimo, e vuoi evitare tutto cio' che aumenta questa complessita' e non ti permette di gestirla.

Scrivere codice non utilizzato aumenta la complessita' di una soluzione e come tale non e' una buona regola di programmazione.

In parole povere, se non ti servono, non devi scrivere quei metodi. Questa e' una buona regola di programmazione

[franksisca]

Originariamente inviato da fek

No, perche' questa metodologia di sviluppo (Waterfall) e' tutto fuorche' efficiente. Anzi, e' un metodo molto costoso, e assolutamente non ottimale, per scrivere codice e costruire software

E io sono daccordo, ma in tutti i corsi di progettazione software è wuello considerato "migliore".

Originariamente inviato da fek

In parole povere, se non ti servono, non devi scrivere quei metodi. Questa e' una buona regola di programmazione

E anche qui sono daccordo, ma ripeto, come regole di buona programmazione io le scriverei comunque, è vero che magari non le usano e mi inducono ad errore, ma se sbaglio un toString, o uno dei simili, che a livello di programmazione non sono niente di complicato(confronti e stampa di variabili interne), credo che la quantità d'errore sia davvero minima.

[cionci]

Originariamente inviato da franksisca

allora, per buona norma una classe ben progettata deve aver un:
toString();
equals();
compareTo();
le variabili private e i metodi di accesso alle variabili set e get.

Per altre specifiche, non credo siano necessarie, al massimo ti consiglio di implementare cloneable e ridefinire il metodo clone();.

Non hanno senso per tutte le classi quindi non è vero che debbano essere sempre implementati...

[fek]

Originariamente inviato da franksisca

E io sono daccordo, ma in tutti i corsi di progettazione software è wuello considerato "migliore".

Sbagliano

E anche qui sono daccordo, ma ripeto, come regole di buona programmazione io le scriverei comunque, è vero che magari non le usano e mi inducono ad errore, ma se sbaglio un toString, o uno dei simili, che a livello di programmazione non sono niente di complicato(confronti e stampa di variabili interne), credo che la quantità d'errore sia davvero minima.

Davvero minima e' comunque diverso da zero.

Proviamo un discorso piu' pragmatico: mi dici quali di queste variabile la pratica di scrivere quei metodi anche quando non servono abbassa? Costo, tempo di sviluppo, numero di difetti.

Se una pratica mi abbassa uno di questi numeri, io sono felicissimo di attuarla. Altrimenti no.

In altre parole, se ti serve un mezzo per andare dal lavoro a casa, che distano cinque chilometri, ti compri una bicicletta, una macchina o un elicottero? Nella vita reale tu paghi qualcosa che non usi e che sai che non ti serve?

E' la stessa cosa nel codice: dammi un buon motivo per pagare qualcosa in termini di tempo e io pago. Altrimenti non pago. "Perche' si fa cosi'" non e' un buon motivo.