2013-02-12 6 views
8

Sto creando un gestore errori per un'API su cui lavoro. L'idea è che fornisca un unico archivio di codici di errore che possono essere restituiti dall'API, assicurando che lo stesso errore nelle diverse chiamate sia gestito allo stesso modo (ad esempio, il valore richiesto mancante dalla richiesta).Come evitare numeri magici senza creare dipendenze

Il mio approccio iniziale era lungo le linee di:

$this->_errorManager->setError(ErrorCodes::REQUIRED_FIELD); 

Tuttavia, questo crea una dipendenza dalla classe codici di errore da nessuna parte Voglio impostare un errore.

L'alternativa è:

$this->_errorManager->setError(100); 

Ma ora ho un certo numero seduto nel mezzo del mio codice che non significa nulla.

Mentre riesco a pensare a soluzioni a questo problema specifico, ci saranno altre situazioni in cui vorrò usare un 'enum' e non riesco a pensare a una soluzione che non accoppiasse strettamente le classi.

C'è un modo migliore di fare questo o un approccio diverso che posso prendere per rimuovere i numeri magici? O è l'accoppiamento stretto qualcosa che devo solo accettare e considerare caso per caso?

+3

Non chiamerei questo "accoppiamento", poiché "ErrorCodes' non ha alcun * comportamento *. È una buona pratica e sicuramente non merita le connotazioni negative del termine. Potresti volerlo pensare come "un'entità logica implementata come due classi fisiche" piuttosto che come "due entità logiche accoppiate insieme". – Jon

risposta

4

Questo è l'accoppiamento desiderato. Sebbene sia una buona idea che l'applicazione e il relativo gestore degli errori siano accoppiati liberamente, non vi è alcun motivo per separare l'applicazione e i relativi codici di errore, essi appartengono insieme.

Dipendenze:

+-----------------------+ 
|Application error codes|<------------+ 
+-----------------------+    | 
     ^      | 
      |       | 
+----------+----------+    | 
|Application component|    | 
+----------+----------+    | 
      |       | 
      v       | 
+-----------------------+  +-------+-----+ 
|Error handler interface|<|---+Error handler| 
+-----------------------+  +-------------+ 
+0

Sono con te ... +1 – hek2mgl

1

È possibile cancellare alcuni di questi ostacoli con le macro "del preprocessore" e un makefile. Le macro del preprocessore vengono fornite per gentile concessione di m4.

Si supponga di mantenere un file di codici di errore come questo.

define(`ERR_REQUIRED_FIELD',`100')dnl 

Quindi è possibile scrivere il codice PHP con l'errore inglese "costante".

$this->_errorManager->setError(ERR_REQUIRED_FIELD); 

E includere una riga nel makefile che esegue questi due file tramite m4. C'è più di un modo per gestirlo. (Per brevità, sto omettendo il makefile, e solo in esecuzione il mio file di prova attraverso m4.)

$ m4 test.php.m4 > test.php 
$ cat test.php 
$this->_errorManager->setError(100); 

Questo fa introdurre una dipendenza; i file php dipenderanno tutti dal file dei codici di errore. Ma è una dipendenza banale che è facilmente gestibile attraverso il makefile. In pratica, probabilmente creerei un file di codici di errore simile a questo. . .

ERR_DISK_FULL 
ERR_REQUIRED_FIELD 
ERR_MISSING_ARG 

e utilizzare le utilità testo e make a uno

  • costruire le definizioni di macro m4, o
  • costruire le definizioni per il modulo ErrorCodes.

I valori numerici corrispondono ai numeri di riga; questo ti garantisce di non avere mai un codice di errore duplicato.

Problemi correlati