L'accesso ai dati utilizzando un valore rappresentativo è una strategia praticabile?

Question

L'accesso ai dati utilizzando un valore rappresentativo è una strategia praticabile?

#1 da (1 voti)

2

Nel corso degli anni ho visto più casi in cui i dati sono accessibili e / o manipolati utilizzando un valore rappresentativo internamente risolto nell'oggetto / campo dati / algoritmo corretto.

Alcuni esempi:

// 1. Provide same logger globally using it's name
auto myLogger = LoggingService.getLogger("myLogger")

// 2. Get person object using a unique id
auto person = PersonCatalog.getPerson("12345")

// 3. Get the left child of a B-Tree node
auto lnode = BTreeNode.getNode("left")

// 4. Make player character do something based off a command
playerCharacter.performAction("move_north")

Capisco, perché si dovrebbe usare questo approccio per il logger, dal momento che non è necessario passare oggetti concreti a un'istanza di Logger nell'intero programma. Posso anche vedere il merito nel secondo esempio, in quanto potrebbe fornire un'interfaccia a un dizionario o una ricerca nel database.

Ma il terzo e il quarto esempio in contrasto annusano i difetti di progettazione.

Questo tipo di design ha un nome ed è una strategia praticabile per più di un paio di scenari speciali?

design

posta Luca Fülbier 11.11.2015 - 02:33

fonte

1 risposta

Leggi altre domande sui tag design

API e un client API condiviso Miglior prodotto con più tabelle con categorie

score 1 · Accepted Answer

Sono d'accordo, gli ultimi due sembrano essere odori di codice, e anche il primo. Ma credo che il contrasto posto in questa domanda abbia più a che fare con scegliere le strutture dati appropriate piuttosto che con schemi specifici. Andrò su ciascuno di essi, iniziando da quello che sembra perfetto.

Il numero 2 qui sopra sembra ok (presumendo che la stringa magica sia solo per brevità) e usi il concetto di < a href="https://en.wikipedia.org/wiki/Identifier"> identificatore . È meno un modello e più un concetto di base usato molto prima che esistessero i computer. In questo caso, l'identificatore scelto come stringa numerica.

Il n. 1 è un odore perché non è chiaro cosa deve essere passato per ottenere il logger giusto. "MyLogger" è un nome interno o una classe da istanziare o una stringa di connessione? Non posso dire da questa chiamata, e ho visto tutte quelle opzioni usate prima. Se assumo nuovamente che la stringa magica è per brevità, potrebbe essere accettabile se il nome della variabile e / o un commento lo chiariscono.

Il n. 3 è un odore perché usa una struttura molto fluida e facile da ottenere (un identificatore di stringa) per rappresentare un concetto molto concreto. In effetti, ci sono 2 o più stringhe corrette che puoi passare e stringhe inesatte virtualmente infinite. Questo è abbastanza concreto da essere idealmente rappresentato da una struttura validata in fase di progettazione come una classe. Quindi, quando si ottiene un nome membro errato, il codice non verrà compilato o darà un errore di sintassi. La struttura stessa è abbastanza importante che il compilatore / interprete non dovrebbe nemmeno eseguirlo se non è corretto.

Il n. 4 è un odore simile al n. 3 (nessuna struttura convalidata) e n. 1 (mancanza di chiarezza), ma meno specifico del codice B in # 3. (Supponendo che tu abbia motivi per non rappresentare le azioni usando metodi / funzioni, es. Client / server.) Puoi rappresentarlo con uno schema o due. Puoi utilizzare messaggistica o anche il GOF schema di comando , a seconda dell'applicazione specifica. Avere messaggi come classi concrete darebbe ai tuoi input una struttura validata e darà ai tuoi chiamanti un mezzo ben definito per comunicare con te.

In sintesi, la maggior parte di questi esempi evidenzia la necessità di scegliere la struttura dati appropriata. Utilizzare le stringhe per attivare i rami di codice non è abbastanza specifico per algoritmi noti come b-tree. Ma potrebbe andare bene per una connessione al database. Scegli con saggezza.