"Creazione intelligente" denominazione del metodo

Question

"Creazione intelligente" denominazione del metodo

#1 da (7 voti)
#2 da (4 voti)
#3 da (1 voti)

5

Ogni classe di un modello nella mia applicazione ha un metodo create . Il framework mi dà l'implementazione predefinita di create che è "crea nel DB". A volte ho bisogno di eseguire alcune azioni extra durante la creazione. Esistono numerosi modi per ottenere questo risultato: posso sovrascrivere create (e chiamare super in seguito), comunicare i segnali (se possibile), sovrascrivere i metodi di aggancio (come before_create ), non è mai stato un problema. Il problema è che in realtà non voglio eseguire queste azioni ogni volta , i. e. queste azioni non sono in realtà parte della procedura di creazione, è parte di un'altra procedura di alto livello (rispetto alla% originalecreate). Lo chiamano smart_create in uno dei più grandi progetti con cui abbia mai lavorato.

Prima di procedere oltre, voglio darti un'idea di cosa sono in genere questi metodi smart_create . Quindi, ecco l'esempio. Quando crei qualche entità per un utente, puoi avvisarlo con una email. Ma potresti non volere notifiche durante i test (potrebbe rallentarli), script stand-alone (quando ripari qualcosa che hai appena rotto) o quando un'entità viene creata tramite pannello di amministrazione (per qualsiasi motivo). La tentazione è lì per denominare questo metodo create_and_notify , ma questo non funzionerà quando hai bisogno di altre azioni: create_and_notify_and_add_bonus_credits non è un nome appropriato.

Quindi, qual è la domanda? Non mi piace definire i miei metodi smart_create , ma non posso davvero dire quale sia il nome migliore. Ecco cosa ho provato e perché ancora non mi piace:

%codice%. Cosa succede se ho due modi non banali di creare entità? Qual è il nome per il secondo? %codice%? Più di questo, come fanno gli altri sviluppatori a sapere quale metodo chiamare? Hanno bisogno di "diventare intelligenti"?
smart_create class. In realtà lo stesso, ma con l'intera classe invece di un solo metodo. Nulla cambia davvero: non è ancora chiaro cosa faccia questo "creatore" e perché sia meglio che "creare".
Nessun nome. Perché il controller sa cosa fare. È solo sporco. Il problema con questo approccio è chiaro: non sarò più in grado di riutilizzare la stessa logica.
%codice%. Qui. Questo è quello che fa veramente il metodo, ma in realtà non voglio menzionare alcuni utenti o clienti nei miei modelli: non dovrebbero sapere nulla di loro.

Credo che molti sviluppatori abbiano riscontrato situazioni del genere e voglio sapere qual è il tuo approccio abituale a questo problema.

methods api naming mvc model

posta Vadim Pushtaev 14.02.2016 - 22:10

fonte

3 risposte

7

Devi solo avere il tuo metodo create e passare alcune norme che forniscono funzionalità aggiuntive.

La denominazione di tali criteri dovrebbe essere semplice.

risposta data 14.02.2016 - 22:43

fonte

1

Una delle indicazioni che stai violando il Principio di Responsabilità Unica è quando ti trovi a voler nominare cose con più "and" nel nome. create_and_notify_and_add_bonus_credits , ecc.

link

Se stai lavorando in un ambiente che consente a un dispatcher di eventi, hub di messaggi, hook, ecc., questo è un modo conveniente per separare alcuni dei problemi, mentre ancora legano insieme la loro esecuzione in fase di runtime. Ad esempio, l'utente creato sarebbe responsabile solo della creazione dell'utente e della spedizione di un evento o dell'attivazione di eventuali hook collegati. Nel tuo ambiente di test, sei libero di prendere in giro qualsiasi oggetto che funzioni dopo l'esecuzione del metodo di creazione dell'utente.

Per un approccio più estremo, puoi leggere sull'architettura basata sugli eventi: link

risposta data 15.02.2016 - 17:01

fonte

Leggi altre domande sui tag methods api naming mvc model

Come dovrei valutare un corso di formazione? [chiuso] Esempi di app web di medie e grandi dimensioni create senza un ORM?

score 4 · Accepted Answer

Il mio approccio è:

Usa un nome che indica cosa succede, se non precisamente , quindi almeno inequivocabilmente , invece di un nome che dà semplicemente qualche indizio vago che cosa sarà accadere sarà al di fuori di ciò che potrebbe arbitrariamente essere considerato come "il solito". Questo perché "il solito" tende a variare a seconda del modulo su cui stai lavorando, del tipo di lavoro che stai svolgendo e persino della fase del progetto. Quindi nomi come "smart_create", "special_update", "save_extended", "import_other" ecc. Sono completamente fuori questione per quanto mi riguarda.
Utilizzare un nome che abbia senso nel contesto dei chiamanti della funzione, ma senza appesantire i chiamanti con concetti a cui non interessa (e non dovrebbero preoccuparsi). Ciò significa che create_by_user potrebbe essere preferito su create_and_notify , poiché il fatto che una notifica verrà emessa è un dettaglio di implementazione a cui probabilmente il chiamante non teme di sapere.

Tuttavia, come hai scoperto, ci sono casi in cui il # 2 sopra non può essere soddisfatto, perché anche il chiamante potrebbe non voler sapere nulla degli utenti. Se il nome è abbastanza generico da evitare che il chiamante si occupi di entità di cui preferirebbe non sapere nulla, allora il nome potrebbe essere troppo generico per descrivere ciò che il callee sta realmente facendo.

In questi casi, ciò che a volte devi fare è interporre un'interfaccia aggiuntiva tra il chiamante e il chiamante, in modo da introdurre un cambio di paradigma. In questo modo, al chiamante viene fornita un'interfaccia con cui lavorare, senza sapere nulla sulla sua implementazione, e invoca un metodo su quell'interfaccia chiamata create , e il chiamante è felice, perché non sono gravati da entità che non vogliono sapere.

L'oggetto che implementa quell'interfaccia viene selezionato durante l'assemblaggio del sistema. (La fase di inizializzazione durante la quale vengono risolte le dipendenze.)

Quindi, in circostanze normali, l'implementazione standard di tale interfaccia invocherà create_by_user , per creare l'utente ed emettere una notifica, ma per il pannello di amministrazione probabilmente si collegheranno gli oggetti in modo diverso, usando qualche altra implementazione dell'interfaccia che invoca create_by_admin o semplicemente just_create per astenersi dall'emettere notifiche.