Nominare le cose per bene

Nominare le cose: Basi della Programmazione Orientata agli Oggetti

Esaminiamo la progettazione di oggetti/classi attraverso degli esempi…

La Situazione

Avete mai progettato un modello di dati (nel codice, in SQL o in fogli Excel)? Il seguente vi sembra familiare?

*** anti-pattern - non copiare-incollare ***
* User
  - id
  - avatarUrl
  - name
  - email
  - password

* Agent
  - id
  - primaryPhoto
  - name
  - email
  - agentEmail
  - agentPhoneMain
  - agentEmailPrimary
  - agentPhonePrimary
  - agentAddressFull
  - agentCompanyName
  - agentCompanyAddress
  - *userEmail* - 'Puntatore' alla tabella User ^^^

Dov’è il bug?

Beh, tecnicamente non c’è nessun bug, semplicemente dati che hanno bisogno di essere riorganizzati.

Vi suona familiare?

Qualsiasi modifica alla vostra applicazione richiederà ore di arduo debug.
Qualsiasi requisito che cambia risulterà in:

rifattorizzazione dello schema

Perché nominare un campo agentEmailPrimary è così male?

Per cominciare, non state creando qualcosa di interamente nuovo nell’universo. L’eccessiva specificità nasconde alcune trappole:

Essere ‘bloccati’ in un nome altamente specifico significa che agentEmailPrimary probabilmente renderà le vostre viste e il codice correlato riutilizzabili al 0%, con bug ricorrenti e fastidiosi come:

Dati non sincronizzati tra le tabelle (non è ovvio se user.email debba propagarsi a agent.agentEmail o viceversa - figuriamoci la complessità di implementare manualmente dove e come far rispettare questa ‘logica’ …)
Regole e logica di validazione sono probabilmente duplicate e incoerenti.
Sempre più spesso, il vostro progetto assomiglierà a un traballante castello di Jenga.
La fragilità si accumula con ogni nuovo file, poiché è richiesta un’attenzione estrema ai dettagli anche per modifiche banali

agentEmailPrimary potrebbe significare diverse cose. Evitate l’ambiguità con nomi più brevi.

Attenzione alle parole in eccesso. Primary? Porta solo a ulteriori domande: Ce n’è una Secondaria? È per il parente più prossimo?

Basta parole, Dan, come dovrebbe apparire invece?

Una Soluzione

// Schema Consolidato:

User
  - id
  - role: ['agent', 'lead', 'admin']
  - name
  - phone
  - address
  - email
  - password
  - company
    - name
    - address

Ho rimosso la tabella Agent, poiché non conteneva campi unici per gli Agent. E l’oggetto User.company (con .name, .address) è emerso una volta ripulita la nomenclatura.

Alcuni principi guida:

Eliminate le tabelle non necessarie. Avete davvero bisogno di una tabella statuses? Quando potreste aggiungere un campo status::VARCHAR(8) sulla tabella User? Va bene, usate quei byte in più per riga.
Provate a unire le tabelle correlate. Dati
Eliminate la raccolta dati ridondante (ad esempio rimuovete la tabella ActivityLogs se sostituita da una soluzione di Analytics.)
Provate a mantenere tutti i nomi dei campi a una singola parola/sostantivo/pronome. Va bene affidarsi al contesto fornito dal nome della tabella. (ad esempio PersonalAccount.email vs BusinessAccount.email - il contesto è fornito dal nome della tabella.)
Non esiste qualcosa come Agent.agentEmail o Agent.agentPhonePrimary. Punto. Ripetete con me: “è email e phone.”
Usando nomi altamente specifici, fissate nella pietra un livello specifico di riutilizzabilità del codice e durabilità, beh, specificamente ZERO %.
Non vi fate alcun favore con robe del tipo User.profileSummaryEmail. 💞

Letture consigliate: