Lo "scopo" della conoscenza su quali sono i parametri validi

Per me, sembra che il controllo di validità di un numero di registrazione di un'auto non sia nulla che appartiene "logicamente a Car ", come hai scritto, perché quando hai solo questo numero, non hai intrinsecamente un'auto correlata oggetto nell'ambito e probabilmente non ne avrai bisogno per eseguire la convalida. (Naturalmente, non appartiene logicamente a ParkingLot ). Il numero di registrazione è qualcosa con una durata che potrebbe essere indipendente da altri oggetti.

La convalida potrebbe verificare alcune regole nazionali sull'ordine di cifre e lettere. Oppure, potrebbe chiedere alla commissione nazionale di registrazione quali numeri sono validi. Quindi potrebbe essere funzione in un oggetto RegistrationNumber o in una classe RegistrationBoard . Ciò rende la convalida disponibile in qualsiasi metodo della classe ParkingLot , nonché in qualsiasi metodo della classe Car o in altre posizioni del codice, laddove richiesto.

Nota inoltre che il design del metodo getCar , e ciò che restituisce, non dovrebbe dipendere da dove il controllo di validazione può essere implementato al meglio. Il design del metodo getCar dovrebbe dipendere dal suo uso previsto, su nient'altro. Penso che sia un po 'strano pensare a un ParkingLot che convalida la correttezza del numero di registrazione di una macchina chiedendo alla commissione nazionale di registrazione, ma se nel vostro sistema tale convalida ha senso quando viene chiamato quel metodo, allora fatelo , utilizzando ad esempio il citato oggetto RegistrationBoard .

Penso che ci sia un po 'di confusione sul fatto che tu stia cercando di modellare un dominio reale o implementare un vero programma software.

In realtà, la maggior parte dei parcheggi non "sa" quale auto si trova in quale posizione, o anche se una determinata macchina è nel lotto. (Alcuni luoghi hanno il riconoscimento automatico delle immagini delle targhe, ma questo è un problema separato).

Nel software, a seconda di cosa si suppone che la classe ParkingLot faccia, l'interfaccia più semplice è probabilmente addCar(Car c) e removeCar(Car c) , in questo modo ParkingLot è libero di registrare una mappa hash di ogni oggetto Car e quando è entrato nel lotto in modo che le spese totali possano essere calcolate. In questo modo, non è necessario che si verifichi una perdita di requisiti nella classe Car di un campo VIN o numero di targa # di un determinato tipo di dati.

(Una piccola ottimizzazione su questo sarebbe di generare una classe Ticket ogni volta che si chiama addCar , che ha un identificatore di transazione univoco. Poiché il ParkingLot è quello che si preoccupa del campo unico, è opportuno che fornisce un'interfaccia per generarne uno, piuttosto che richiederlo da un chiamante).

È un cattivo esempio, perché controllare per tutte le registrazioni di auto valide.

Diciamo che si tratta di carte di credito e si desidera eseguire un controllo lun lun 10 prima di effettuare una chiamata api slow alla banca.

Avrei un oggetto separato per la convalida del numero. Dopotutto potresti voler diversi schemi di convalida diversi in base al tipo di carta. O ci si potrebbe aspettare errori di immissione sull'interfaccia utente e si desidera presentare / registrarli in modo diverso dagli errori API.

La flessibilità di assemblare il client API raw e la classe di validazione in vari modi è in genere migliore rispetto all'utilizzo di entrambi i bit di logica incapsulati nella stessa classe.