Le classi API pubbliche hanno metodi di supporto che forniscono funzionalità anticipate?

Question

Le classi API pubbliche hanno metodi di supporto che forniscono funzionalità anticipate?

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

0

Allo scopo di fornire un esempio concreto per la mia domanda, diciamo che sto costruendo un'API che fornisce l'accesso a un sistema di posta elettronica e contiene un insieme di classi pubbliche, ad es. Mailbox , MailboxFolder , Message , MessageAttachment e così via.

È una buona idea provare ad anticipare in che modo i client possono utilizzare l'API e fornire metodi di "aiuto" per le operazioni comuni?

Ad esempio, immagina che la mia classe Message abbia un metodo Save(string toFilePath) . Forse sarebbe utile fornire un altro metodo in Message che crea un "nome file sicuro" dall'oggetto del messaggio, cioè un nome di file che è una porzione ragionevole del soggetto (poiché la lunghezza di un oggetto di posta elettronica può essere lontana supera la lunghezza massima di un percorso file) dove tutti i caratteri che non sono validi per l'uso in un nome di file sono stati sostituiti con un carattere utilizzabile.

Il motivo potrebbe essere che prevedo che i clienti potrebbero voler salvare un'email con un nome simile all'oggetto.

design

posta rory.ap 08.10.2015 - 16:04

fonte

2 risposte

3

No, assolutamente no!

In generale, dovresti mai "anticipare". Le previsioni sono difficili, specialmente quelle che riguardano il futuro. Le API dovrebbero essere estratte dal codice funzionante, non tirate fuori dal nulla. Segui YAGNI, segui la regola del terzo (non estrai un'API finché non hai tre client indipendenti).

In questo caso particolare, anche se avevi tre client, l'API sanitizzante del nome file non ha attività commerciali in una libreria di e-mail. Appartiene a una libreria di nomi di file.

risposta data 08.10.2015 - 20:54

fonte

Leggi altre domande sui tag design

Massimizza la quantità di lavoro non eseguita in Agile? [duplicare] Sviluppo lato server per sviluppatori Android [chiuso]

score 3 · Accepted Answer

"Generatore di nomi di file sicuro" non è qualcosa che mi aspetterei (o anche solo desiderare) di vedere in una libreria correlata all'email. Costruire una stringa "sicura" dall'oggetto del messaggio arbitrario può essere un compito piuttosto complicato se si pensa alla codifica, ai caratteri consentiti per i percorsi in diversi sistemi operativi, ecc., Quindi è meglio che venga gestito da API / libreria specializzata.

I principi generali sono:

Assumi meno, rendi la tua API più agevole del suo "ambiente" possibile. Immagina che la tua API possa essere utilizzata in un browser, che non può nemmeno salvare un file, quindi non avrebbe nemmeno bisogno del metodo Save . È preferibile fornire una forma di serializzazione anziché il metodo Save e consentire agli utenti di decidere come gestire i massaggi serializzati: stampa, salvataggio in file, trasferimento in rete, ecc.
Non ingombrare la tua API con roba che gli utenti possono solo possibilmente hanno bisogno - vedi creep dell'oscilloscopio e YAGNI
Rispetta il principio di responsabilità singola . Scegliere un nome per un file non è qualcosa che il messaggio di posta elettronica dovrebbe fare o anche solo essere a conoscenza.

Per quanto riguarda i metodi di supporto che non violano i principi sopra menzionati: se si sceglie di mettere tali metodi nelle classi appropriate, va bene.