Mi chiedevo solo se fosse una buona pratica: Immagina un modello, ad esempio un utente, che viene letto da un servizio Web o da un database. Ovviamente l'implementazione dell'utente non deve avere alcuna conoscenza sull'origine dati. Mi chiedevo se fosse una buona idea aggiungere quelle conoscenze con un metodo di estensione, quindi avrei potuto fare qualcosa del genere:
import NsOfExtensionmethod
var user = dataAccessInstance.getUser(id)
user.delete(dataAccessInstance)
Questa è un'idea interessante, ma c'è un difetto nel design. Una classe di "accesso ai dati" è normalmente responsabile del recupero e della persistenza dei dati, ei metodi di estensione suddividono questa responsabilità. Inoltre, non si sta rimuovendo la dipendenza dall'oggetto di accesso ai dati, quindi non si ottiene alcuna flessibilità. Come ha sottolineato @Ewan nel suo commento, la natura statica dei metodi di estensione ti impedisce di iniettare oggetti fittizi durante i test unitari, riducendo la testabilità del tuo codice, o almeno rendendolo più difficile da testare.
Questo è esattamente il motivo per cui il pattern di repository è sempre più utilizzato. Questo, oltre a utilizzare un'interfaccia per nascondere l'implementazione dell'oggetto "accesso ai dati" consente di utilizzare un database o un servizio Web e lo scambio dell'implementazione è facile come scrivere una nuova classe concreta.
Leggi altre domande sui tag programming-practices design-patterns