"Evitare il problema yo-yo" è un motivo valido per consentire l '"ossessione primitiva"?

Secondo Quando l'ossessione primitiva non è un odore di codice? , Dovrei creare un oggetto ZipCode per rappresentare un codice postale anziché un oggetto String.

Tuttavia, nella mia esperienza, preferisco vedere

public class Address{
    public String zipCode;
}

invece di

public class Address{
    public ZipCode zipCode;
}

perché penso che quest'ultimo richieda che io passi alla classe ZipCode per capire il programma.

E credo di dover passare da una classe all'altra per vedere la definizione se tutti i campi di dati primitivi sono stati sostituiti da una classe, che sembra soffrire del problema yo-yo (un anti-pattern).

Quindi vorrei spostare i metodi ZipCode in una nuova classe, ad esempio:

Vecchio:

public class ZipCode{
    public boolean validate(String zipCode){
    }
}

Nuovo:

public class ZipCodeHelper{
    public static boolean validate(String zipCode){
    }
}

in modo che solo chi deve convalidare il codice postale dipenda dalla classe ZipCodeHelper. E ho trovato un altro "vantaggio" di mantenere l'ossessione primitiva: mantiene la classe simile alla sua forma serializzata, se presente, ad esempio: una tabella di indirizzi con colonna stringa zipCode.

La mia domanda è: "evitare il problema yo-yo" (spostarsi tra le definizioni di classe) è un motivo valido per consentire l '"ossessione primitiva"?

Il presupposto è che non è necessario accedere alla classe ZipCode per comprendere la classe Address. Se ZipCode è ben progettato, dovrebbe essere ovvio ciò che fa semplicemente leggendo la classe Address.

I programmi non vengono letti end-to-end - in genere i programmi sono troppo complessi per renderlo possibile. Non puoi tenere in mente tutto il codice di un programma contemporaneamente. Quindi usiamo astrazioni e incapsulamenti per "dividere" il programma in unità significative, in modo da poter guardare una parte del programma (diciamo la classe Address) senza dover leggere tutto il codice da cui dipende.

Ad esempio, sono sicuro che non ti piace leggere il codice sorgente per String ogni volta che incontri String nel codice.

Rinominare la classe da ZipCode a ZipCodeHelper suggerisce che ora ci sono due concetti separati: un codice postale e un helper di codice postale. Quindi due volte più complesso. E ora il sistema dei tipi non può aiutarti a distinguere tra una stringa arbitraria e un codice postale valido poiché hanno lo stesso tipo. Qui è dove "ossessione" è appropriata: stai suggerendo un'alternativa più complessa e meno sicura solo perché vuoi evitare un semplice tipo di wrapper attorno a una primitiva.

L'uso di una primitiva è IMHO giustificato nei casi in cui non esiste alcuna convalida o altra logica a seconda di questo particolare tipo. Ma non appena aggiungi una logica, è molto più semplice se questa logica è incapsulata con il tipo.

Per quanto riguarda la serializzazione, penso che sembri una limitazione nel framework in uso. Sicuramente dovresti essere in grado di serializzare un ZipCode su una stringa o mapparlo su una colonna in un database.

Se puoi fare:

new ZipCode("totally invalid zip code");

E il costruttore per ZipCode fa:

ZipCodeHelper.validate("totally invalid zip code");

Quindi hai rotto l'incapsulamento e aggiunto una dipendenza piuttosto stupida alla classe ZipCode. Se il costruttore non chiama, ZipCodeHelper.validate(...)allora hai una logica isolata nella sua isola senza applicarla effettivamente. È possibile creare codici postali non validi.

Il validatemetodo dovrebbe essere un metodo statico sulla classe ZipCode. Ora la conoscenza di un codice postale "valido" è raggruppata insieme alla classe ZipCode. Dato che i tuoi esempi di codice sembrano Java, il costruttore di ZipCode dovrebbe generare un'eccezione se viene fornito un formato errato:

public class ZipCode {
    private String zipCode;

    public ZipCode(string zipCode) {
        if (!validate(zipCode))
            throw new IllegalFormatException("Invalid zip code");

        this.zipCode = zipCode;
    }

    public static bool validate(String zipCode) {
        // logic to check format
    }

    @Override
    public String toString() {
        return zipCode;
    }
}

Il costruttore controlla il formato e genera un'eccezione, impedendo così la creazione di codici postali non validi e il validatemetodo statico è disponibile per altri codici, quindi la logica di controllo del formato è incapsulata nella classe ZipCode.

Non esiste "yo-yo" in questa variante della classe ZipCode. Si chiama semplicemente corretta programmazione orientata agli oggetti.

Ignoreremo anche qui l'internazionalizzazione, che potrebbe richiedere un'altra classe chiamata ZipCodeFormat o PostalService (ad esempio PostalService.isValidPostalCode (...), PostalService.parsePostalCode (...), ecc.).

Se combatti molto con questa domanda, forse la lingua che usi non è lo strumento giusto per il lavoro? Questo tipo di "primitive tipizzate dal dominio" sono banalmente facili da esprimere, ad esempio in F #.

Lì potresti, ad esempio, scrivere:

type ZipCode = ZipCode of string
type Town = Town of string

type Adress = {
  zipCode: ZipCode
  town: Town
  //etc
}

let adress1 = {
  zipCode = ZipCode "90210"
  town = Town "Beverly Hills"
}

let faultyAdress = {
  zipCode = "12345"  // <-Compiler error
  town = adress1.zipCode // <- Compiler error
}

Questo è davvero utile per evitare errori comuni, come il confronto di ID di entità diverse. E poiché queste primitive tipizzate sono molto più leggere di una classe C # o Java, finirai per usarle.

La risposta dipende interamente da ciò che vuoi effettivamente fare con i codici postali. Ecco due possibilità estreme:

(1) Tutti gli indirizzi sono garantiti in un singolo paese. Nessuna eccezione. (Ad esempio nessun cliente straniero o nessun dipendente il cui indirizzo privato è all'estero mentre lavorano per un cliente straniero.) Questo paese ha codici postali e non ci si può aspettare che siano mai seriamente problematici (cioè non richiedono input in formato libero come "attualmente D4B 6N2, ma questo cambia ogni 2 settimane"). I codici postali vengono utilizzati non solo per l'indirizzamento, ma per la convalida delle informazioni di pagamento o per scopi simili. - In queste circostanze, una classe di codice postale ha molto senso.

(2) Gli indirizzi possono essere presenti in quasi tutti i paesi, pertanto sono rilevanti dozzine o centinaia di schemi di indirizzamento con o senza codici di avviamento postale (e con migliaia di strane eccezioni e casi speciali). Un codice "ZIP" è davvero richiesto solo per ricordare alle persone dei paesi in cui i codici postali sono usati per non dimenticare di fornire il loro. Gli indirizzi vengono utilizzati solo in modo tale che se qualcuno perde l'accesso al proprio account e può dimostrare il proprio nome e indirizzo, l'accesso verrà ripristinato. - In queste circostanze, le classi di codice postale per tutti i paesi interessati sarebbero uno sforzo enorme. Fortunatamente non sono affatto necessari.

Le altre risposte hanno parlato della modellazione del dominio OO e dell'utilizzo di un tipo più ricco per rappresentare il tuo valore.

Non sono in disaccordo, soprattutto dato il codice di esempio che hai pubblicato.

Ma mi chiedo anche se questo risponda effettivamente al titolo della tua domanda.

Considera il seguente scenario (estratto da un progetto reale a cui sto lavorando):

Hai un'applicazione remota su un dispositivo di campo che comunica con il tuo server centrale. Uno dei campi DB per la voce dispositivo è un codice postale per l'indirizzo a cui si trova il dispositivo campo. Non ti importa del codice postale (o di qualsiasi altra parte dell'indirizzo). Tutte le persone che se ne occupano sono dall'altra parte di un confine HTTP: ti capita di essere l'unica fonte di verità per i dati. Non ha posto nella modellazione del tuo dominio. Basta registrarlo, convalidarlo, archiviarlo e, su richiesta, rimuoverlo in un BLOB JSON per punti altrove.

In questo scenario, fare molto di più che convalidare l'inserimento con un vincolo regex SQL (o il suo equivalente ORM) è probabilmente eccessivo della varietà YAGNI.

L' ZipCodeastrazione potrebbe avere senso solo se anche la tua Addressclasse non avesse una TownNameproprietà. Altrimenti, hai una mezza astrazione: il codice postale designa la città, ma questi due bit di informazioni correlate si trovano in classi diverse. Non ha molto senso.

Tuttavia, anche allora, non è ancora un'applicazione corretta (o piuttosto una soluzione a) ossessione primitiva; che, a quanto ho capito, si concentra principalmente su due cose:

1. Usare le primitive come valori di input (o persino output) di un metodo, specialmente quando è necessaria una raccolta di primitive.
2. Classi che sviluppano proprietà extra nel tempo senza mai riconsiderare se alcune di queste debbano essere raggruppate in una sottoclasse.

Il tuo caso non è nessuno dei due. Un indirizzo è un concetto ben definito con proprietà chiaramente necessarie (via, numero, CAP, città, stato, nazione, ...). Non vi è alcun motivo per dividere questi dati in quanto ha un'unica responsabilità: designare una posizione sulla Terra. Un indirizzo richiede tutti questi campi per essere significativo. La metà di un indirizzo è inutile.

Questo è il modo in cui sai che non è necessario suddividere ulteriormente: la scomposizione ulteriore ridurrebbe l'intenzione funzionale della Addressclasse. Allo stesso modo, non hai bisogno di una Namesottoclasse per essere usata nella Personclasse, a meno che Name(senza una persona collegata) sia un concetto significativo nel tuo dominio. Che non è (di solito). I nomi sono usati per identificare le persone, di solito non hanno valore da soli.

Dall'articolo:

Più in generale, il problema yo-yo può anche riferirsi a qualsiasi situazione in cui una persona deve continuare a alternare tra diverse fonti di informazioni per comprendere un concetto.

Il codice sorgente viene letto molto più spesso di quanto sia scritto. Pertanto, il problema yo-yo, di dover passare da un file all'altro è una preoccupazione.

Tuttavia, no , il problema yo-yo sembra molto più rilevante quando si ha a che fare con moduli o classi profondamente interdipendenti (che si richiamano tra loro). Questi sono un tipo speciale di incubo da leggere, ed è probabilmente ciò che il direttore del problema yo-yo aveva in mente.

Tuttavia - sì , evitare troppi strati di astrazione è importante!

Tutte le astrazioni non banali, in una certa misura, presentano delle perdite. - la Legge delle Astrazioni Perdenti.

Ad esempio, non sono d'accordo con l'ipotesi fatta nella risposta di mmmaaa secondo cui " non è necessario yo-yo per [(visitare)] la classe ZipCode per comprendere la classe Address". La mia esperienza è stata che lo fai - almeno le prime volte che leggi il codice. Tuttavia, come altri hanno notato, ci sono momenti in cui una ZipCodeclasse è appropriata.

YAGNI (Ya A't Not Gonna Need It) è un modello migliore da seguire per evitare il codice Lasagna (codice con troppi livelli) - astrazioni, come tipi e classi, sono lì per aiutare il programmatore e non dovrebbero essere usate a meno che non lo siano un aiuto.

Personalmente mi propongo di "salvare righe di codice" (e ovviamente i relativi "salva file / moduli / classi", ecc.). Sono fiducioso che ci siano alcuni che potrebbero applicare a me l'epiteto di "ossessionato primitivo" - trovo più importante avere un codice di cui sia facile ragionare piuttosto che preoccuparsi di etichette, schemi e anti-schemi. La scelta corretta di quando creare una funzione, un modulo / file / classe o inserire una funzione in una posizione comune è molto situazionale. Mi riferisco all'incirca a 3-100 funzioni di linea, 80-500 file di riga e "1, 2, n" per il codice libreria riutilizzabile ( SLOC - esclusi commenti o targhetta della caldaia ; in genere desidero almeno 1 SLOC minimo aggiuntivo per riga di obbligatorio boilerplate).

La maggior parte dei modelli positivi sono nati dagli sviluppatori facendo esattamente questo, quando ne avevano bisogno . È molto più importante imparare a scrivere codice leggibile che cercare di applicare schemi senza lo stesso problema da risolvere. Qualsiasi buon sviluppatore può implementare il modello di fabbrica senza averlo mai visto prima nel caso insolito in cui si adatta perfettamente al loro problema. Ho usato il modello di fabbrica, il modello di osservatore e probabilmente anche centinaia, senza conoscerne il nome (ovvero, esiste un "modello di assegnazione variabile"?). Per un esperimento divertente - vedi quanti schemi GoF sono integrati nel linguaggio JS - Ho smesso di contare dopo circa 12-15 nel 2009. Il modello Factory è semplice come restituire un oggetto da un costruttore JS, ad esempio - non è necessario una WidgetFactory.

Quindi - sì , a volte ZipCode è una buona classe. Tuttavia, no , il problema yo-yo non è strettamente pertinente.

Il problema yo-yo è rilevante solo se devi capovolgere avanti e indietro. Ciò è causato da una o due cose (a volte entrambe):

1. Cattiva denominazione. ZipCode sembra a posto, ZoneImprovementPlanCode richiederà uno sguardo alla maggior parte delle persone (e i pochi che non ne saranno colpiti).
2. Accoppiamento inappropriato. Supponiamo che la classe ZipCode abbia una ricerca per prefisso. Potresti pensare che abbia senso perché è utile, ma non è realmente correlato allo ZipCode e infilarlo in esso significa che ora le persone non sanno dove andare per le cose.

Se puoi guardare il nome e avere un'idea ragionevole di ciò che fa, e i metodi e le proprietà fanno cose ragionevolmente ovvie, non devi andare a guardare il codice, puoi semplicemente usarlo. Questo è il punto centrale delle classi in primo luogo: sono pezzi di codice modulari che possono essere utilizzati e sviluppati in modo isolato. Se devi vedere qualcosa di diverso dall'API per la classe per vedere cosa fa, è nella migliore delle ipotesi un errore parziale.

Ricorda, non esiste un proiettile d'argento. Se stai scrivendo un'app estremamente semplice che deve essere sottoposta a scansione veloce, una semplice stringa potrebbe fare il lavoro. Tuttavia, nel 98% delle volte, un oggetto valore come descritto da Eric Evans in DDD sarebbe la soluzione perfetta. Puoi facilmente vedere tutti i vantaggi offerti dagli oggetti Value leggendo in giro.