Qual è la logica dietro a Apache Jena * tutto è un'interfaccia se possibile * filosofia del design?

2

Se hai familiarità con il motore Java RDF e OWL Jena , allora hai attraversato la loro filosofia che tutto dovrebbe essere specificato come un'interfaccia quando possibile. Ciò significa che una risorsa , istruzione , RDFNode , proprietà e persino il modello , ecc. sono, contrariamente a quanto si potrebbe pensare, Interfacce invece di classi concrete.

Questo porta all'uso delle fabbriche abbastanza spesso. Poiché non è possibile creare un'istanza di Proprietà o Modello , è necessario che qualcos'altro lo faccia per te - il modello di progettazione di fabbrica .

La mia domanda, quindi, è, qual è il motivo dietro l'utilizzo di questo modello rispetto a un sistema di gerarchia di classe tradizionale? Spesso è perfettamente fattibile utilizzare uno dei due. Ad esempio, se desidero un modello di memoria invece di un modello supportato da database, posso semplicemente istanziare quelle classi, non ho bisogno di chiedere a una fabbrica di darmene uno .

Per inciso, sto scrivendo una libreria per manipolare i dati Pearltrees , che vengono esportati dal loro sito web nel forma di un documento RDF / XML. Mentre scrivo questa libreria, ho molte opzioni per definire le relazioni presenti nei dati di Peartrees. Ciò che è bello dei dati di Pearltrees è che ha un sistema di classi molto logico: un albero è fatto di perle, che possono essere sia perle di pagina, di riferimento, di alias o di radice.

La mia domanda viene dal cercare di capire se dovrei adottare la filosofia Jena nella mia libreria che usa Jena, o se dovrei ignorarla, scegliere la mia filosofia di design e attenerci ad essa.

    
posta David Cowden 29.06.2012 - 22:43
fonte

2 risposte

2

Ci sono alcuni vantaggi nell'usare solo le interfacce come la faccia pubblica della tua API:

  • È possibile creare proxy dinamici che implementano un'interfaccia ( leggi di più ). I proxy dinamici vengono spesso utilizzati per implementare meccanismi RPC trasparenti (mentre gli oggetti "vivono" su un server ma possono essere recuperati e gestiti da un'applicazione client). Si possono classi proxy, ma solo tramite hack. Pertanto, le API implementate utilizzando i proxy possono essere facilmente esposte per RPC.

  • Si apre ad avere diverse implementazioni delle interfacce che possono essere commutate in modo trasparente. Quindi, puoi avere un'API che ha diverse implementazioni indipendenti che utilizzano tecniche diverse (ad esempio, qualcuno potrebbe creare un'implementazione che è più performante, potresti passare alla loro implementazione senza modifiche al tuo codice).

Certo, è un tipo di dolore; devi utilizzare le fabbriche per creare un'istanza delle classi API e rende il codice di implementazione dell'API più complesso e ridondante (tutti i metodi pubblici sono duplicati).

Penso che una soluzione accurata sia quella di Dart: ogni classe dichiara implicitamente un'interfaccia costituita dai metodi pubblici della classe, evitando così la duplicazione del codice.

Riguardo alla necessità di fabbriche, non sono sicuro che esista una soluzione migliore. Si potrebbe reimplementare un'API che sovrascrive lo spazio dei nomi delle classi originali, ma è una specie di hacker e penso che potrebbe creare problemi, esp. con strumenti.

    
risposta data 30.06.2012 - 14:05
fonte
1

Ciò che alex ha detto è corretto e sono le migliori ragioni per cui posso pensare di usare le interfacce ovunque sia possibile. Il proxy dinamico è importante perché non possono essere utilizzati con classi, anche astratte!

Non ho familiarità con Jena in particolare, ma una strong preferenza per le interfacce è abbastanza comune in OOP.

L'unico pericolo da prestare attenzione è l'uso eccessivo delle interfacce. Posso dire che la best practice di programmazione su interfaccia è stata abusata quando vedo tonnellate di interfacce con solo una singola implementazione chiamata dopo l'interfaccia e la parola "Impl".

public interface WidgetManager {
    ...
}

public class WidgetManagerImpl implements WidgetManager {
    ..
}

Avrei potuto trasformare WidgetManager in una classe e averne finito. Invece, abbiamo raddoppiato il numero di tipi di Java necessari e abbiamo aggiunto un cerchio in più da utilizzare durante il debug.

    
risposta data 26.02.2013 - 02:11
fonte

Leggi altre domande sui tag