Questo sito utilizza cookies, anche di terze parti, per mostrare pubblicità e servizi in linea con il tuo account. Leggi l'informativa sui cookies.
Username: Password: oppure
Algoritmi - Ritornare o non ritornare? Questo è il problema
Forum - Algoritmi - Ritornare o non ritornare? Questo è il problema

Avatar
Bonnox (Member)
Pro


Messaggi: 82
Iscritto: 23/08/2014

Segnala al moderatore
Postato alle 11:01
Sabato, 04/07/2015
Ok, spero di aver colto la vostra attenzione con il titolo :)

volevo semplicemente chiedere un parere.

mi capita di dover creare dei piccoli metodi di tipo Integer che cercano un elemento in una lista. io fornisco il valore di un campo di un oggetto della lista, e loro ritornano l'indice dell'oggetto con tale valore.

ora sorge la mia domanda:
è un'azione "sana" ritornare null nel caso in cui non ci siano risultati? Tenete conto che il campo di ricerca assume un valore univoco per ogni oggetto, dunque ci può essere al più un risultato. Ma se non ce ne è neanche uno? Non si può di certo ritornare 0, o peggio ancora -1! (quale sia peggiore dipende dai punti di vista)

alcuni marchiano ritornare null come "il male". E voi?

( l'ultima frase sembra tratta da una pubblicità invasiva :rofl: )

Ultima modifica effettuata da Bonnox il 04/07/2015 alle 11:04
PM Quote
Avatar
Roby94 (Member)
Guru


Messaggi: 1127
Iscritto: 28/12/2009

Segnala al moderatore
Postato alle 16:02
Sabato, 04/07/2015
Come prima cosa, questa domanda mi sembra strettamente legata al linguaggio. Soprattutto dal fatto che sia "tipizzato" o meno.
In ogni caso diverse funzioni costruite per i linguaggi di più basso livello (vedi C) ritornano -1 in caso di "fallimento" non vedo proprio dove stia il problema. -1 non può essere un valore di indice, più che altro scoccia dover dedicare un intero bit significativo solo per il risultato di non trovato, ma in ogni caso non vedo tante altre soluzioni. null è strettamente legato al linguaggio. Se si trattasse per esempio di php sarebbe un valore accettabile.

In conclusione nessuna scelta è sbagliata se è ben gestita, non causa indeterminazione ed è ben commentata.


La programmazione è arte... fa che i tuoi script siano degni di un museo.
PM Quote
Avatar
Bonnox (Member)
Pro


Messaggi: 82
Iscritto: 23/08/2014

Segnala al moderatore
Postato alle 16:40
Sabato, 04/07/2015
Testo quotato

Postato originariamente da Roby94:

Come prima cosa, questa domanda mi sembra strettamente legata al linguaggio. Soprattutto dal fatto che sia "tipizzato" o meno.
In ogni caso diverse funzioni costruite per i linguaggi di più basso livello (vedi C) ritornano -1 in caso di "fallimento" non vedo proprio dove stia il problema. -1 non può essere un valore di indice, più che altro scoccia dover dedicare un intero bit significativo solo per il risultato di non trovato, ma in ogni caso non vedo tante altre soluzioni. null è strettamente legato al linguaggio. Se si trattasse per esempio di php sarebbe un valore accettabile.

In conclusione nessuna scelta è sbagliata se è ben gestita, non causa indeterminazione ed è ben commentata.


:k:



il linguaggio è giava ehm Java, ma comunque penso si possa applicare a tutti i linguaggi ad oggetti, giusto?

ho pensato che -1 non sia accettabile perchè se viene passato come argomento al metodo get ottengo out of bounds...
poi certo, non si può usare con linguaggi di livello più basso come il C (*) , sia perchè non esiste, sia perchè serve un approccio meno astratto

---

(*) lo so, lo so. infatti non ho detto "basso" in assoluto, ma "più basso".
questo non era per te, l'ho messo perchè ci sarà sempre qualcuno che si arrabbia se gli si va a toccare il C, ancora di più dicendo che è di basso livello :p

PM Quote
Avatar
netarrow (Admin)
Guru^2


Messaggi: 2502
Iscritto: 12/05/2004

Segnala al moderatore
Postato alle 17:53
Sabato, 04/07/2015
Ritornare null è piuttosto comune in questi casi.
Però è visto in generale male perché ritornare o passare null richiede che un altro, o tu stesso in un altro momento, lo gestisca adeguatamente per evitare errori di puntatore nulli.

Le soluzioni sono:

- se non è accettabile che ciò che cerchi non ci sia, lancia piuttosto una tua exception con un messaggio chiaro di cosa è successo, cioè item non trovato.

- se l'eventualità che un item non sia trovato è una eventualità accettabile e quindi da gestire man mano, in casi un pò più strutturati e ripetuti in giro, può valere la pena sfruttare lo Spacial Case pattern o Null Value Object. Questo perchè di fatto un if di quel genere potrebbe essere assimilabile ad un if di tipo e quindi da cercare di rimuovere con del polimorfismo per poter abbattere la complessità ciclomatica.
http://martinfowler.com/eaaCatalog/specialCase.html

- oppure in progetti più blandi dove gestire con un design apposito queste situazioni è overkill ritorna pure null, ma nel nome del metodo specifica alla fine per esempio GetCustomerOrNull, giusto per ricordare al chiamante che il metodo fra le cose che fa potrebbe anche ritornare null.



Mai memorizzare quello che puoi comodamente trovare in un libro.
Imparare è un'esperienza; tutto il resto è solo informazione.
L'immaginazione è più importante della conoscenza.
(A. Einstein)


Esistendo poi google...
PM Quote
Avatar
Bonnox (Member)
Pro


Messaggi: 82
Iscritto: 23/08/2014

Segnala al moderatore
Postato alle 21:06
Sabato, 04/07/2015
Testo quotato

Postato originariamente da netarrow:

Ritornare null è piuttosto comune in questi casi.
Però è visto in generale male perché ritornare o passare null richiede che un altro, o tu stesso in un altro momento, lo gestisca adeguatamente per evitare errori di puntatore nulli.

Le soluzioni sono:

- se non è accettabile che ciò che cerchi non ci sia, lancia piuttosto una tua exception con un messaggio chiaro di cosa è successo, cioè item non trovato.

- se l'eventualità che un item non sia trovato è una eventualità accettabile e quindi da gestire man mano, in casi un pò più strutturati e ripetuti in giro, può valere la pena sfruttare lo Spacial Case pattern o Null Value Object. Questo perchè di fatto un if di quel genere potrebbe essere assimilabile ad un if di tipo e quindi da cercare di rimuovere con del polimorfismo per poter abbattere la complessità ciclomatica.
http://martinfowler.com/eaaCatalog/specialCase.html

- oppure in progetti più blandi dove gestire con un design apposito queste situazioni è overkill ritorna pure null, ma nel nome del metodo specifica alla fine per esempio GetCustomerOrNull, giusto per ricordare al chiamante che il metodo fra le cose che fa potrebbe anche ritornare null.



Graz.. Che???

il livello più alto che ho compreso è "polimorfismo"

scusa, mea culpa :rofl:

mi piace la cosa del GetOrNull, penso che la applicherò (il nome poi sa molto di ultimatum)

(PS: e in lunguaggio "più umano"? )

PM Quote
Avatar
netarrow (Admin)
Guru^2


Messaggi: 2502
Iscritto: 12/05/2004

Segnala al moderatore
Postato alle 21:43
Sabato, 04/07/2015
il primo mi sembra chiaro.
Nel senso che se è inaccettabile non trovare l'oggetto nella lista, non devi ritornare un valore che rappresenta il non aver trovato niente: devi lanciare un errore costringendo così il chiamante a gestirlo, e se non lo fa l'eccezione che arriva a galla conterrà un errore specifico, e non rischierai un generico null reference.

il secondo punto l'ho spiegato male in effetti. Volevo dire che in progetti sufficientemente grandi, e soprattutto dove il metodo che ritorna null potrebbe essere usato in svariati punti, piuttosto che ridondare in giro il check su null, puoi implementare la gestione del caso "item non trovato" come una specifica implementazione dell'interfaccia ritornata dal metodo.
Essendo una cosa molto comune nello sviluppo software questo design, è ormai un pattern noto che si chiama Special Case o Null Value Object.
Il resto del discorso era una generalizzazione: in generale qualunque if di tipo in un design ad oggetti andrebbe sostituito con del polimorfismo, per avere meno if, e quindi per avere complessità ciclomatica più bassa e quindi codice più lineare e gestibile.

Se vuoi approfondire:
https://sourcemaking.com/refactoring/replace-conditional-wi ...
https://it.wikipedia.org/wiki/Complessit%C3%A0_ciclomatica



Mai memorizzare quello che puoi comodamente trovare in un libro.
Imparare è un'esperienza; tutto il resto è solo informazione.
L'immaginazione è più importante della conoscenza.
(A. Einstein)


Esistendo poi google...
PM Quote
Avatar
Bonnox (Member)
Pro


Messaggi: 82
Iscritto: 23/08/2014

Segnala al moderatore
Postato alle 20:56
Giovedì, 09/07/2015
Testo quotato

Postato originariamente da netarrow:

il primo mi sembra chiaro.
Nel senso che se è inaccettabile non trovare l'oggetto nella lista, non devi ritornare un valore che rappresenta il non aver trovato niente: devi lanciare un errore costringendo così il chiamante a gestirlo, e se non lo fa l'eccezione che arriva a galla conterrà un errore specifico, e non rischierai un generico null reference.

il secondo punto l'ho spiegato male in effetti. Volevo dire che in progetti sufficientemente grandi, e soprattutto dove il metodo che ritorna null potrebbe essere usato in svariati punti, piuttosto che ridondare in giro il check su null, puoi implementare la gestione del caso "item non trovato" come una specifica implementazione dell'interfaccia ritornata dal metodo.
Essendo una cosa molto comune nello sviluppo software questo design, è ormai un pattern noto che si chiama Special Case o Null Value Object.
Il resto del discorso era una generalizzazione: in generale qualunque if di tipo in un design ad oggetti andrebbe sostituito con del polimorfismo, per avere meno if, e quindi per avere complessità ciclomatica più bassa e quindi codice più lineare e gestibile.

Se vuoi approfondire:
https://sourcemaking.com/refactoring/replace-conditional-wi ...
https://it.wikipedia.org/wiki/Complessit%C3%A0_ciclomatica



danke:k:

PM Quote