Principi OOP nelle classi clienti e account di una banca

1. Ideally the bank application should worry more about the account than the customer. For example, the bank should have methods like addAccount() : which will add account and create a customer implicitly if it is the first account of the customer and deleteAccount() : which will delete the account and delete the customer implicitly if it is the last account.

Qual è la tua definizione di "preoccupazione"? :)

Come menzionato nella risposta di @James Anderson , le attività dei clienti e gli account sono monitorati, quindi non sarà consuetudine se i record degli account vengono fisicamente cancellati dalla memoria di persistenza (ad es. database, o semplicemente file flat se questo è solo un piccolo incarico accademico che prende in prestito un contesto della banca) viene eseguito il momento deleteAccount() .

Ciò che probabilmente si può fare qui è introdurre campi temporali che possono segnare i timestamp di inizio e fine del record, se il record è considerato logicamente inattivo o entrambi (cioè quattro campi). L'opzione finale può avere senso se si desidera tenere traccia di clienti / account temporaneamente sospesi, con l'opzione che possono essere attivati in seguito. Per esempio. un esempio semplificato in scala cronologica:

01/01 ------------ 04/30 -------------- 08/31 -------------- 12/31
* Account created  * Account            * Account            * Account
  and active         suspended            active               inactive

2. There can be a use case in the future where an account can have multiple customers. So that can be accommodated easily in the second approach than the first.

Vero ... in una certa misura. Spero solo che la seguente riga significhi solo l'intenzione di utilizzare una struttura dati multi-elemento, non un limite rigido di 5 account:

 Account[] accounts = new Account[5];

Un approccio alternativo è semplicemente memorizzare i riferimenti in entrambe le classi di dominio, ad es. in Java:

public class Customer {
    // ...
    Set<Account> accounts = new HashSet<>();
}

public class Account {
    // ...
    Set<Customer> customers = new HashSet<>();
}

In questo modo, puoi facilmente identificare tutti i conti di un singolo Customer o tutti gli Customer s associati di un Account . Per perfezionare ulteriormente, forse queste relazioni possono essere memorizzate come associazioni Map<Account, AccountType> e Map<Customer, CustomerType> .

Oh Dear.

Il tuo design è il modo in cui sono state progettate le applicazioni bancarie negli anni '70. Io e diverse migliaia di professionisti abbiamo trascorso decenni a cancellare questo errore di progettazione per ottenere sistemi più simili all'opzione 1.

Le banche trattano con i clienti l'account è solo un meccanismo per gestire alcuni dei soldi dei clienti.

Ancora più importante la pila di regolatori che appesantiscono qualsiasi attività finanziaria sono molto interessati ai clienti. Vogliono conoscere tutte le attività e le responsabilità di qualsiasi individuo o azienda; non lo stato di un singolo account. Non riuscendo a segnalare tutti i conti detenuti da un individuo, o, avendo più di un record del cliente per la stessa persona, potrebbe ottenere una multa o alla fine portare alla perdita della licenza bancaria.

Come cancellerà i dati dei clienti quando un account è chiuso! Devi conservare tutto per diversi anni.

Sembra un classico tipo di rapporto Has Many / Belongs To . Quello che facciamo di solito è una specie di unione tra le 2 opzioni, dove:

1. Un Customer ha una lista di molti Account s che ha .
2. Un Account ha un riferimento al Customer che appartiene a .

Detto questo, @James Anderson è preciso in quanto afferma l'importanza dei clienti piuttosto che l'account stesso.

Modellazione orientata agli oggetti, utilizzata per rappresentare il mondo reale in un'applicazione software.

In altre occasioni, un singolo account, aveva solo, e solo un cliente, assegnato. Al giorno d'oggi, diversi clienti possono essere assegnati e rimossi da un account.

Ci sono molti modi per modellare un'applicazione, quindi non esiste un modo "100% cattivo" o "100% buono".

Il tuo esempio è un "molti-a-molti" associazioni.

E, in genere, viene aggiunta una classe intermedia aggiuntiva.

Un modo per iniziare, è modellare ogni set di dati, o oggetto, escludendo esplicitamente le relazioni tra loro e aggiungere tali relazioni, più tardi.

class CustomerClass
{
     int   CustNo;
     String name;
     Date   dob;
     .
     .         
} // class CustomerClass

class AccountClass
{
     int   accNo;
     float amount;
     .
     .
} // class AccountClass

class AccountCustomerClass
{ 
     int   acccustNo;

  // How to relate both, added later
} // class AccountClass

Successivamente, scegli una delle classi "edge" ("Account" o "Cliente"), che meglio si adatta alle tue esigenze e aggiungi una raccolta o una matrice di classe "relazione".

In questo esempio, prendiamo "Cliente":

class AccountClass
{
     int   accNo;
     decimal amount;
     .
     .
} // class AccountClass

class AccountCustomerClass
{ 
     int   accustNo;
     DateTime RegistrationDate;
     .
     .
     AccountClass Account;
} // class AccountClass

class CustomerClass
{
     int   CustNo;
     String name;
     Date   dob;
     .
     .
     AccountCustomerClass Accounts[];
} // class CustomerClass

Nota che l'uso di "Account clienti account clienti []", in "AccountClass", anziché "CustomerClass" non è "cattivo", è solo un modo alternativo.

Ecco un suggerimento che ti insegnerà a pescare.

"modella il mondo come è realmente nel software"

Guardati allo specchio e pronuncia le due opzioni di progettazione come una frase.

Opzione 1: "Sono un cliente e ho molti account"

Opzione 2: "Sono un account e ho un cliente."

Quale suona sciocco? quale suona vero? Scegli quello che funziona nel mondo reale. Attenersi al linguaggio ubiquitario: leggi Domain Driven Design (Eric Evans).

Risciacquo & ripeti il resto della tua carriera di successo!