Ho lavorato/visto alcuni progetti di applicazioni Web con sospensione letargica con tante interfacce quante sono le effettive classi di servizio e dao.Perché sempre le singole interfacce di implementazione sono disponibili nei livelli service e dao?
ho sempre pensato che questi due come le principali ragioni di queste singole interfacce di attuazione:
molla può cablare attuazione effettiva come dipendenze in una determinata classe (accoppiamento lasco)
public class Person { @Autowired private Address address; @Autowired private AccountDetail accountDetail; public Person(Address address, AccountDetail accountDetail) { // constructorDurante il test delle unità, posso creare classi di simulazione e testare una classe in isolamento.
Address mockedAddress = mock(Address); AccountDetail mockedAccountDetail = mock(AccountDetail); Person underTestPerson = new Person(mockedAddress, mockedAccountDetail); // unit test follows
Ma, negli ultimi tempi, mi sono reso conto che:
molla può collegare le classi di implementazione concreti come dipendenze:
public class Person {
@Autowired
private AddressImpl address;
@Autowired
private AccountDetailImpl accountDetail;
public Person(AddressImpl address, AccountDetailImpl accountDetail) {
// constructor
quadri Mock come EasyMock possono deridere classi concrete, nonché
AddressImpl mockedAddress = mock(AddressImpl);
AccountDetailImpl mockedAccountDetail = mock(AccountDetailImpl);
Person underTestPerson = new Person(mockedAddress, mockedAccountDetail);
// unit test follows
Inoltre, come nel caso della discussione this, penso che il riassunto sia che all'interno di una singola app, le interfacce sono per lo più sovrautilizzate probabilmente per convenzione o abitudine. In genere hanno senso nei casi in cui ci interfacciamo con un'altra applicazione, ad esempio slf4j utilizzata da molte app in tutto il mondo. All'interno di una singola app, una classe è quasi un'astrazione quanto un'interfaccia.
Quindi, la mia domanda è perché abbiamo ancora bisogno di interfacce e quindi abbiamo implementazioni singole come le classi * ServiceImpl e * DaoImpl e aumentano inutilmente le dimensioni della base del codice. C'è qualche problema nel prendere in giro lezioni concrete di cui non sono a conoscenza.
Ogni volta che ho discusso di questo con i miei compagni di squadra, la sola risposta che ottengo è che il servizio di implementazione e le lezioni dao basate su interfacce è IL PROGETTO che seguono tutti - citano le migliori pratiche di primavera, OOP, DDD ecc. ancora non si ottiene una ragione pragmatica per avere così tante interfacce all'interno di un'applicazione isolata.
Per quanto riguarda le risposte ottenute, non riesco a vedere come si possa invocare il DDD come motivo per lanciare un'interfaccia davanti a ciascun oggetto. DDD non ha nulla a che fare con questo. Anche l'OOP è una scarsa giustificazione. Se prendi cose come la L, I e D di SOLID, specificano solo come dovresti progettare astrazioni come interfacce e cosa dovresti usarle, non che * dovresti usarle tutto il tempo *. Quindi, come hai detto tu, suppongo che tutto si riduca alla "best practice di primavera" o solo a persone che lo fanno per abitudine. – guillaume31