L'obiezione eccessiva e / o l'incapsulamento ridondante sono concetti riconosciuti? [chiuso]

Question

L'obiezione eccessiva e / o l'incapsulamento ridondante sono concetti riconosciuti? [chiuso]

#1 da (8 voti)
#2 da (4 voti)

6

Sono curioso di sapere se esiste una serie di tendenze o anti-pattern durante la programmazione, in base alla quale uno sviluppatore reimpiegherà sempre le dipendenze esterne durante il consumo.

Un esempio un po 'meno vago potrebbe essere dire quando si consuma un'implementazione di un'interfaccia o di un abstract, e mappare localmente ogni touch-point prima di interagire con essi. Come una composizione complicata sulla composizione. Dato il mio esempio, l'interfaccia non sarebbe abbastanza affidabile e qualsiasi modifica ad esso non potrà mai essere superata da alcun livello di riferimento indiretto?

Questa è una buona o una cattiva pratica? Può mai andare troppo lontano? Ha un nome proprio?

encapsulation interfaces composition theory

posta Omega 17.10.2013 - 19:53

fonte

2 risposte

Leggi altre domande sui tag encapsulation interfaces composition theory

ASP.NET AJAX e la mia ascia! Qual è l'antonio del "codice legacy"? [chiuso]

score 8 · Answer 1

Ho visto queste cose chiamate "shearing layers" - che sono specializzazioni di "livelli di astrazione" per dipendenze esterne.

Personalmente, penso che sia una cattiva pratica che spesso cade in YAGNI.

Sì, i livelli di astrazione ti proteggono dal cambiare le interfacce al di fuori del tuo controllo o se modifichi le dipendenze. Ma ho visto troppo spesso persone andare "ma cosa succede se il nostro fornitore di database cambia?!?" per un'app che ha una durata di 6 mesi. Ho anche visto troppi livelli di astrazione cattivi . Trapelano attraverso abbastanza dettagli di implementazione che si finisce con un carico di lavoro in barca per adattarlo comunque alla nuova implementazione.

Se conosci l'interfaccia esterna cambierà, l'astrazione potrebbe essere prudente. Se conosci di avere bisogno di più implementazioni, l'astrazione è importante. Se non conosci , non avrai ( probabilmente ) alcun bisogno.

score 4 · Answer 2

Penso che molte persone lo chiamino semplicemente "wrapping a API". Ci sono alcune circostanze in cui può essere utile:

Quando si esegue il wrapping solo di un piccolo sottoinsieme dell'API. Questo impone un'interfaccia più piccola.
Quando il tuo ABI non è costante. Nvidia fa questo per i loro driver Linux. Lo script di installazione compila il wrapper e lo collega al loro binario closed source.
Quando stai creando un'astrazione utile, non solo una copia funzione per funzione dell'API originale.
Quando hai già due implementazioni dell'API, sai che devi usare. Ad esempio, diversi database o sistemi operativi o versioni linguistiche. Ho un progetto sia per Android che per desktop Java in cui ho implementato la maggior parte delle funzionalità dell'interfaccia utente.

L'errore che molte persone fanno è quello di avvolgere un'API nella remota possibilità che potrebbe aver bisogno di sostituirla un giorno, ma se e quando arriverà quel giorno, il loro wrapper è troppo simile all'originale e deve comunque essere riscritto. Le astrazioni sono utili solo se aggiungono qualche valore al livello sottostante.