classi di utilità .. buono o cattivo?

Question

Ho letto che la creazione di dipendenze utilizzando classi statiche / singletons nel codice, è di cattivo gusto, e crea problemi di IE. attacco ed unit test.

Ho una situazione in cui ho un gruppo di metodi analisi degli URL che non hanno stato associato con loro, ed eseguire operazioni utilizzando solo gli argomenti di input del metodo. Sono sicuro che si ha familiarità con questo tipo di metodo.

In passato avrei proceduto a creare una classe e aggiungere questi metodi e chiamarli direttamente dal mio codice ad es.

UrlParser.ParseUrl(url);

Ma aspettate un minuto, che sta introducendo una dipendenza ad un'altra classe. Sono incerto se classi di questi 'utilità' sono cattivi, in quanto sono apolidi e questo riduce al minimo alcuni dei problemi con detti classi statiche, e single. Qualcuno potrebbe chiarire questo?

Dovrei essere in movimento i metodi alla classe chiamata, cioè se solo la classe di chiamata verrà utilizzato il metodo. Questo può violare il 'Single Responsibilty Principio'.

Answer 1

Dal punto di vista di design teorica, sento che le classi di utilità sono qualcosa da evitare, quando possibile. Essi sono fondamentalmente differente che classi statiche (sebbene leggermente migliore, poiché non hanno uno Stato).

Dal punto di vista pratico, però, faccio a creare questi, e incoraggiare il loro utilizzo se del caso . Cercando di evitare classi di utilità è spesso ingombrante, e porta a codice meno gestibile. Tuttavia, cerco di incoraggiare i miei sviluppatori per evitare questi in API pubbliche, quando possibile.

Per esempio, nel tuo caso, sento che UrlParser.ParseUrl (...) è probabilmente meglio gestita come una classe. Guardate System.Uri nel BCL - questo gestisce un pulito, facile da usare l'interfaccia per Uniform Resource indentifiers, che funziona bene, e mantiene lo stato attuale. Preferisco questo approccio ad un metodo di utilità che funziona sulle stringhe, e costringendo l'utente a passare intorno una stringa, ricordo per convalidarlo, ecc.

Answer 2

classi di utilità sono ok ..... fintanto che non violano i principi di progettazione. Usarli come felicemente come usereste le classi del framework di base.

Le classi dovrebbero essere ben nome e logico. In realtà non sono tanto "utilità", ma parte di un framwework emergente che le classi native non forniscono.

Utilizzando le cose come metodi di estensione possono essere utili anche per allineare la funzionalità sulla classe di "destra". MA, possono essere causa di confusione le estensioni non sono confezionati con la classe si estendono generalmente, che non è ideale, ma, comunque, può essere molto utile e produrre codice più pulito.

Answer 3

Si può sempre creare un'interfaccia e l'uso che con l'iniezione di dipendenza con le istanze di classi che implementano l'interfaccia invece di classi statiche.

La questione diventa, è davvero valsa la pena? In alcuni sistemi, la risposta di sì, ma in altri, specialmente quelli più piccoli, la risposta è probabilmente no.

Answer 4

Sono d'accordo con alcune delle altre risposte qui che è il singleton classico che mantiene una singola istanza di un oggetto con stato che deve essere evitato e non necessariamente classi di utilità con nessuno stato che sono il male. Sono anche d'accordo con Reed, che se possibile, mettere questi metodi di utilità in una classe dove ha senso farlo e dove ci si logico sospettare tali metodi sarebbero risiedere. Vorrei aggiungere, che spesso questi metodi di utilità statici potrebbero essere buoni candidati per i metodi di estensione.

Answer 5

Davvero, davvero cercare di evitarli, ma chi vogliamo prendere in giro ... strisciano in ogni sistema. Tuttavia, nell'esempio dato avrei usato un oggetto URL che poi esporre vari attributi del URL (protocollo, dominio, percorso e parametri query stringa). Quasi ogni volta che voglio creare una classe di utilità della statica, posso ottenere più valore con la creazione di un oggetto che fa questo tipo di lavoro.

In modo simile ho creato un sacco di controlli personalizzati che hanno costruito nella convalida per cose come percentuali, valuta, numeri di telefono e simili. Prima di fare questo ho avuto una classe di utilità Parser che ha avuto tutte queste regole, ma rende molto più pulito di cadere solo un controllo sulla pagina che conosce già le regole di base (e quindi richiede solo logica di business validazione da aggiungere).

Conservo ancora la classe di utilità parser e questi controlli nascondere che classe statica, ma lo uso ampiamente (mantenendo tutto il parsing in uno facile da trovare posto). A questo proposito ritengo accettabile per avere la classe di utilità, perché mi permette di applicare "Non Repeat Yourself", mentre io ottenere il beneficio di classi istanziati con i controlli o altri oggetti che utilizzano le utilità.

Answer 6

Questo dipende molto dal contesto, e come le usiamo.

classi di utilità, per sé, non è male. Tuttavia, diventerà male se usiamo il brutto modo. Ogni modello di progettazione (in particolare pattern Singleton) può essere facilmente trasformato in anti-modello, lo stesso vale per le classi di utilità.

Nella progettazione del software, abbiamo bisogno di un equilibrio tra flessibilità e semplicità. Se stiamo andando a creare uno StringUtils che è responsabile solo per la stringa di manipolazione:

• Ha viola SRP (Responsabilità unico principio)? -> No, è che gli sviluppatori mettere troppa responsabilità in classi di utilità che violano SRP
.
• "Non può essere iniettata utilizzando quadri DI" -> Sono StringUtils implementazione andando varia? Faremo a passare le sue implementazioni in fase di esecuzione? Stiamo andando mock? Certo che no.

=> classi di utilità, da sè stesso non sono male. E 'colpa degli sviluppatori che peggiorare.

Tutto in realtà dipende dal contesto. Se hai intenzione basta creare una classe di utilità che contiene solo un'unica responsabilità, ed è usato solo privatamente all'interno di un modulo o di un livello. Allora sei ancora bene con esso.

Answer 7

Stanno bene finchè li si progetta bene (che è, non c'è bisogno di cambiare la loro firma di volta in volta).

Questi metodi di utilità non cambiano spesso, perché fanno solo una cosa. Il problema nasce quando si vuole stretto un oggetto più complesso ad un altro. Se uno di loro ha bisogno di cambiare o essere sostituito, sarà più difficile per a se li avete fortemente accoppiati.

Dal momento che questi metodi di utilità non cambierà che spesso direi che non è molto problema.

Credo che sarebbe peggiore se si copia / incollare lo stesso metodo di utilità più e più volte.

Questo video Come progettare una buona API e perché è importante da Joshua Bloch , spiega diversi concetti da tenere a mente quando si progetta un'API (che sarebbe la vostra libreria di utilità). Anche se lui è un architetto Java riconosciuto il contenuto si applica a tutti i linguaggi di programmazione.

Answer 8

Utilizzare con parsimonia, si vuole mettere quanto più logica, come si può nelle vostre classi in modo essi non diventino solo contenitori di dati.

Ma, allo stesso tempo, non si può davvero evitare di programmi di utilità, a volte sono necessari.

In questo caso penso che sia ok.

FYI c'è la classe system.web.httputility che contiene un sacco di utility http comuni che si possono trovare utili.