Convenzioni di denominazione comuni per variabili di tipo di opzione e metodi che li restituiscono

Question

Quali sono alcuni metodi comuni per denominare le variabili del tipo di opzione ei metodi che restituiscono tipi di opzioni per distinguerli dalle controparti non facoltative?

Supponiamo che un DAO al momento abbia un metodo findById che restituisce un'istanza di un'entità o null, se depreciamo tale metodo e ne aggiungiamo uno che restituisce un tipo di opzione, come dovremmo chiamarlo?

Ora supponiamo di dover rifattorizzare il codice per utilizzare questo nuovo metodo, non vogliamo sostituire tutti i riferimenti alla variabile di entità con il tipo di opzione, come dovremmo denominare la variabile del tipo di opzione?

interface Dao<ENTITY ,ID> { 
    @Deprecated 
    ENTITY findById(ID id); 

    //What naming convention should we use? 
    Optional<ENTITY> maybeFindById(ID id); 
} 

public class MyService { 
    PersonDao personDao; 

    public void changeAge(final Long id,final int age) { 

    //final Person person = personDao.findById(id); 
    //if(person !=null) 

    //What naming convention should we use? 
    final Optional<Person> maybePerson = personDao.maybeFindById(id); 

    if (maybePerson.isPresent()){ 
     final Person person = maybePerson.get(); 
     person.setAge(age); 
    } 
} 

Answer 1

penso che questa è davvero una domanda abbastanza opinione a base, in quanto in realtà non può essere qualsiasi risposta autorevole e corretta.

Detto questo, la mia preferenza è di nominare solo i metodi che restituiscono normalmente Optional, ad es. Optional<Foo> findById(Id id). Il metodo non è in realtà diverso da un metodo che può restituire null per indicare "nessun risultato", tranne per il fatto che il tipo restituito lo rende molto più esplicito.

Come per una variabile Optional, tendo solo a chiamarli come optionalFoo ... ma in generale penso che il nome di una variabile locale (o anche campo) sia molto meno importante di come si denomina un metodo.

Answer 2

Se non pensate che sia una buona idea avere due metodi diversi qui. In caso di dubbi sulla migrazione, mantieni quello vecchio.

Ma c'è un modo di refactoring l'intero codice in due fasi:

In primo luogo, modificare l'interfaccia da

interface Dao<ENTITY ,ID> { 
    ENTITY findById(ID id); 
} 

a

interface Dao<ENTITY ,ID> { 
    default ENTITY findById(ID id) { return newFindById(id).orElse(null); } 
    Optional<ENTITY> newFindById(ID id); 
} 

presumo dalla tua domanda che l'adattamento le implementazioni dell'interfaccia non sono un problema. Ora indica allo strumento di refactoring lo in linea il vecchio metodo, ora default, findById.

In secondo luogo, rinominare il metodo newFindById a findById.

In questo modo la migrazione del interface a

interface Dao<ENTITY ,ID> { 
    Optional<ENTITY> findById(ID id); 
} 

mentre tutti i siti di chiamata sono stati modificati da:

Person maybePerson = personDao.findById(id); // may be null 

a

Person maybePerson = personDao.findById(id).orElse(null); 

---

In questo modo si dispone di un pulito interface in primo luogo mentre l'altro codice è adattato per funzionare come prima. Quindi puoi passare attraverso i siti di chiamata uno per uno e decidere se e come devono essere modificati. Questo potrebbe richiedere del tempo ma poiché lo interface è già pulito e il problema della convenzione di denominazione risolto, non è necessario affrettarsi.

Si noti che il metodo di esempio dovrebbe allora piuttosto assomigliare:

public void changeAge(final Long id,final int age) { 
    personDao.findById(id).ifPresent(person -> person.setAge(age)); 
} 

Si noti che in entrambe le forme, il vecchio codice refactoring e il nuovo codice, non v'è alcuna necessità di nominare una variabile di tipo Optional quindi non c'è non c'è bisogno di una convenzione di denominazione.

Il refactoring richiede ovviamente uno strumento compatibile con Java 8.