Come modellerai un oggetto che rappresenta le diverse fasi di un ciclo di vita di un'entità?

Uno degli eventi che mi hanno più aperto gli occhi è stato l'apprendimento di Modellazione basata sul colore . Ha totalmente trasformato il mio approccio alla progettazione di sistemi.

L'idea chiave è che ci sono quattro archetipi nella progettazione orientata agli oggetti:

1. Intervallo di Momento rappresenta un evento o un intervallo di tempo. Ad esempio, la richiesta di un prestito è un momento in cui l'intero processo dall'applicazione alla chiusura del prestito sarebbe un intervallo
2. Il ruolo rappresenta i partecipanti in un intervallo di momenti. Attaccando con il prestito, un candidato sarebbe un ruolo, il funzionario di prestito sarebbe un altro, i sottoscrittori sarebbero un terzo.
3. Descrittore rappresenta un'etichetta o una "classe" di oggetti. Ad esempio, potresti avere un descrittore per prestiti immobiliari rispetto a prestiti auto, ma i prestiti stessi sono fondamentalmente gli stessi. Il descrittore può anche fungere da fabbrica. Di solito uso descrittori in cui le persone normalmente usano Enum.
4. Persona / Luogo / Cosa rappresenta un oggetto fisico, tangibile. Michael Brown è una persona, Global Corp. Headquarters è un luogo, Dell Precision Laptop con numero di serie 12345 è una cosa. (Nota: il mio computer portatile Dell Precision specifico potrebbe avere un descrittore collegato ad esso nel sistema E-commerce di Dell).

Questi sono i 4 elementi di base di un modello O-O. Ed ecco come si riferisce alla tua domanda.

Il primissimo archetipo è il Moment-Interval. Se si richiama una delle linee guida per la programmazione di base orientata agli oggetti "Gli oggetti sono nomi, i metodi sono verbi" si potrebbe essere tentati di rappresentare l'applicazione di prestito come metodo "ApplyForLoan" sull'oggetto Richiedente e memorizzare tutte le informazioni sull'applicazione su un singolo oggetto di prestito. Quindi potresti essere tentato di avere un'enumerazione "LoanStatus" sul prestito che elenca in sostanza tutte le fasi in cui il prestito passa mentre viene elaborato.

Il modo migliore è avere un oggetto momento dell'applicazione. E un oggetto ruolo del richiedente. I ruoli sono associati a Persona / Luogo / Cosa e partecipano ai momenti (in pratica, di solito conferisco la responsabilità di creare un momento oggetto a un ruolo che identifico come "attore". Nel caso della domanda di prestito, il candidato è "l'attore".

All'interno del libro, Coad parla del concetto di Predecessori e Successori. Cioè prima che un RiskAssessment possa essere eseguito, ci deve essere una Applicazione . I momenti formano una catena di eventi pertinenti al sistema che si sta creando. Ad esempio, il sistema di approvazione del prestito non si preoccuperebbe dei pagamenti sul prestito, quindi non sarebbero mappati come parte del sistema. Anche se potrebbe esserci un altro sistema che si occupa di questi dettagli.

La parte bella di questo approccio è che il sistema diventa molto flessibile ed estensibile, piuttosto che attaccare nuovi campi e metodi su un oggetto "LoanCustomer" gonfiato (o peggio derivante dal cliente in prestito per rappresentare diversi ruoli che il cliente potrebbe giocare nel sistema), creiamo nuovi ruoli man mano che crescono le esigenze del sistema.

Consiglio vivamente di prendere in mano il libro e di esaminarlo. È una tecnica molto potente nonostante il fatto che UML non sia più a favore, i concetti sono senza tempo.

Se fossi in te, terrei immutabili i miei dati. È molto più sicuro e semplice ragionare su; quando gestisci denaro, questo è particolarmente importante.

Ogni fase del processo di richiesta del prestito sarebbe rappresentata dalla sua stessa classe, descrivendo quella fase nel modo più adeguato e un collegamento alla fase precedente.

Dove è economico, coperei i dati della fase precedente: ad esempio, i numeri. Le stringhe sono probabilmente anche facili da "copiare" se stai usando un linguaggio in cui le stringhe sono immutabili e internate e basta copiare un riferimento.

Se una grande quantità di dati deve essere condivisa con una fase precedente (una tabella di dati, una scansione di documenti, ecc.), questi dati probabilmente formano il proprio oggetto, riferito a ciascuna fase che lo utilizza.

Naturalmente, renderemmo anche immutabile ogni oggetto secondario di questi oggetti. Se un elenco di offerte cambia, è un altro oggetto che rappresenta la modifica e contiene sia i vecchi che i nuovi elenchi, entrambi immutabili.

Upsides:

• La mappatura dei dati è semplice, quindi parlare con gli uomini d'affari diventa più facile.
• Hai una visione completa di come i tuoi dati si sono evoluti, ottimo per la ricerca di bug o test, risoluzione dei problemi, reporting e auditing.
• Non sarai mai in grado di perdere dati attraverso un bug nella logica di modifica dei dati. (Se fai multi-threading, anche le intere classi di data race e i bug di modifica simultanea vanno via.)
• Ogni fase ha la migliore rappresentazione senza compromessi e nessun campo extra non utilizzato.
• Il tuo sistema di tipi ti aiuta a utilizzare sempre un oggetto di fase di flusso corretto, rilevando molti possibili bug in fase di compilazione.

Svantaggi:

• Hai molte classi interdipendenti, a volte ingannevolmente simili.
• La modifica della logica aziendale potrebbe richiedere un po 'più di modifiche nel codice.

Ecco la parte fondamentale di un articolo che descrive questo approccio . Usa Scala, ma spiega la logica in inglese semplice. Sentiti libero di dare un'occhiata alle parti precedenti che mostrano gli svantaggi di un approccio di oggetti mutevoli.

Durante la lettura della tua domanda, ho sentito un sacco di ha-una relazione. Un prestito ha un'applicazione. Un prestito ha 0 o più offerte. Ecc, ecc.

Immagino qualcosa del genere (pseudocodice Java):

public class Loan {
    private Application application;
    private List<Offers> offers;
    // etc
}

Al fine di ridurre al minimo la duplicazione, penso che vorrei che ogni elemento figlio rimandasse al genitore:

public class Application {
    private Loan parent;
    private List<Address> addresses;
    private List<Person> responsibleParties;
    private State currentState;
}

In questo modo, gli elementi di Loan potrebbero navigare in elementi correlati per acquisire i dati.

Ci sono alcuni lati negativi in questo. Ad esempio, se questo viene archiviato in un database, potresti essere costretto a caricare l'intero grafico Loan quando tutto ciò che vuoi è un po 'di informazione. Inoltre, alcune duplicazioni vanno bene e addirittura incoraggiano. Considera l'indirizzo di una persona. L'indirizzo corrente potrebbe non essere l'indirizzo utilizzato nella loro applicazione. In questi casi, potresti volere delle copie difensive. L'indirizzo dell'applicazione non dovrebbe mai cambiare, ma l'indirizzo corrente sarà. È utile ricordare che parti di questo sono un documento e che la deduplicazione è problematica.

Vorrei iniziare con un oggetto con tutta la data condivisa al suo interno. Tutti gli altri oggetti dovrebbero avere un riferimento ad esso in modo che possano ottenere quei dati condivisi. Inoltre, avrebbe riferimenti, diretti o, a volte, indiretti, a tutti gli altri oggetti. Potrebbe servire come l'oggetto che rappresenta tutti i relativi prestiti e documenti associati.

Ciascuno degli altri oggetti conterrà, oltre a un riferimento all'oggetto dati condiviso, riferimenti all'altro oggetto a cui sono strettamente correlati: oggetto predecessore, oggetto o oggetti successore e qualsiasi altra cosa che potrebbe essere di interessi.

Ora dovrebbe essere possibile iniziare con qualsiasi oggetto e rintracciare rapidamente tutte le informazioni rilevanti, nessuna delle quali viene memorizzata due volte.