Assegnazione di nomi alle raccolte di metodi di supporto ed evitando parole gergali senza senso

Question

Assegnazione di nomi alle raccolte di metodi di supporto ed evitando parole gergali senza senso

#1 da (1 voti)

0

Durante la codifica di qualcosa di remotamente utile, mi ritrovo inevitabilmente a voler aggiungere metodi per eseguire piccoli pezzi. (Potrebbe essere un metodo per restituire tutto in una stringa a sinistra della prima occorrenza di un particolare carattere.) Nel corso del tempo, la scrittura di tali metodi si inserirà facilmente in una sorta di libreria.

Come dovremmo nominare tali classi, o come dovrebbero essere strutturate? Il metodo di stringa menzionato in precedenza dovrebbe probabilmente essere in una classe chiamata "String something", ma penso che l'utilizzo di suffissi come Utils, Helper, Manager o Service non faccia altro che rendere il nome più lungo senza aggiungere significato reale. Il nome "StringMethods" non è molto meglio.

Quindi come possiamo organizzare e nominare i nostri metodi di "aiuto" in modo ragionevole? Qualcuno è riuscito a farlo?

c# naming libraries naming-standards

posta Ola Eldøy 07.06.2017 - 23:23

fonte

1 risposta

Leggi altre domande sui tag c# naming libraries naming-standards

È possibile proteggere sia l'accesso alle pagine Web che alle API Web con un JWT? Modelli di modelli di modelli in MVC

score 1 · Answer 1

Naming

Utilizza i verbi attivi.
Se una "classe helper" è specifica per le classi personalizzate, utilizzare la terminologia di dominio
I metodi di supporto possono essere organizzati in modo funzionale anziché in base al tipo di dati? Quindi un nome di classe utilmente descrittivo sarebbe più immediato.
Il nome della classe e / o la firma del metodo dice molto e ridurrà la necessità di inserire un tipo di dati come parte di un nome di metodo.
Esperimento! Abbi coraggio nel cambiare i nomi delle classi. Avete il controllo della versione, sì?

Struttura

Preferisci metodi statici e classi statiche. Questo mi trasmette l'intento che i metodi non sono statici; riferimenti a argomenti o calcoli i risultati non vengono mantenuti e non dovrebbero esserlo.
Annulla in modo esplicito qualsiasi membro di livello di classe dopo l'uso. Non conservare riferimenti a oggetti. Non cedere per "non importa in quanto verrà sovrascritto la prossima volta". Ascoltami ora e credimi più tardi.
I metodi di classe helper dovrebbero considerare gli argomenti come immutabili. Queste classi di scopo generale non sono le tue classi di dominio e non dovrebbero alterare lo stato della classe di dominio.

Metodi di estensione

Come suggerito da @BenCottrell, è anche una buona idea.

Ciò implica una stretta relazione con il tipo su cui lavorano. Più vicino alla tipica "classe helper"
Se è necessario modificare qualsiasi stato dell'oggetto dominio, direi creare metodi di estensione, non utilizzare classi helper per scopi generici.
Definire questi w / nel proprio spazio dei nomi o namespace nidificato come necessario per limitare il loro ambito. In caso contrario, un metodo di estensione sulla classe string sarà disponibile per tutti gli oggetti stringa ovunque. Il namespace enfatizza l'uso previsto dell'estensione per i target desiderati.

Metodi di estensione vis-a-vis Helper Classes

Questi non si escludono a vicenda
Vedo la differenza nell'esprimere qualcosa sul loro comportamento come un fattore di progettazione, trattando gli oggetti come immutabili o meno. Vedi sopra.
A volte si dice che le classi di aiuto sono un odore di codice, il che suggerisce che uno sguardo più attento al design è in ordine. Dopotutto, se questi metodi sono pensati per funzionare su particolari classi, forse è proprio lì che dovrebbero essere.