Quale sarebbe il modo migliore di strutturare i pacchetti per evitare i nomi dei pacchetti duplicati quando viene ripetuto un sottoprotocollo?

Question

Quale sarebbe il modo migliore di strutturare i pacchetti per evitare i nomi dei pacchetti duplicati quando viene ripetuto un sottoprotocollo?

#1 da (2 voti)

0

Ci scusiamo per il lungo titolo un po 'poco chiaro, non potremmo pensare a come esprimere il problema che sto avendo. Quindi, in pratica, ho una struttura del pacchetto con due alternative ragionevoli (per quanto posso vedere), ma entrambe implicano una ripetizione al secondo livello.

Ad esempio, i miei pacchetti di primo livello potrebbero includere tcp e bluetooth e quindi ognuno di questi avrebbe bisogno di un pacchetto secondario sink e source ; in alternativa sinks e sources potrebbero essere pacchetti di primo livello e ognuno di questi ha un sottoprogetto tcp e bluetooth . Il modo in cui ho iniziato originariamente era il primo esempio, ma ora ho bisogno di un'interfaccia source e sink per la riusabilità, il che sarebbe strano inserire solo in un sottoprogetto e importare da, diciamo, tcp in %codice%; tuttavia avere una copia in ciascuno sarebbe una pratica abbastanza terribile, sono sicuro che tutti sarebbero d'accordo!

Un'ulteriore complicazione è rappresentata dal fatto che fonti e sink nel mio progetto non verranno consegnati esclusivamente alle tecnologie di connessione, in quanto un dispositivo di riproduzione locale viene anche considerato come un sink per una classe che invia i dati.

java packages

posta Harvey Adcock 11.08.2016 - 19:05

fonte

1 risposta

Leggi altre domande sui tag java packages

Modo RESTful per definire un'API che richiede due chiavi per restituire una risorsa Guadagna utilizzando OpenCV?

score 2 · Accepted Answer

Hai veramente bisogno di pacchetti secondari per ognuna delle fonti e amp; affonda? Potresti pensare troppo a questo.

In ogni caso, se dovessi votare sulla questione, terrei il sink & fonte per un particolare protocollo insieme, quindi i vostri pacchetti di livello superiore rispecchiano il protocollo (ip / bluetooth / seriale): come sorgente e amp; sink per ogni protocollo sono più strettamente correlati tra loro rispetto a varie fonti su più protocolli.

Una buona astrazione ci suggerisce che dobbiamo accoppiare sorgenti e amp; affonda insieme, perché altrimenti lasceremo che sia il client a fare quell'accoppiamento per formare l'astrazione bidirezionale source / sink.

Le interfacce comuni per source e sink dovrebbero ottenere il loro posizionamento nella gerarchia dei pacchetti indipendentemente dai protocolli.

Quindi potresti avere un pacchetto I / O e sotto alcune interfacce, e anche sotto il pacchetto IO, alcuni protocolli.

One additional complication is that sources and sinks in my project will not be consigned purely to connection technologies, as a local playback device is also counted as a sink to a class that sends it data.

Come da ultimo, potresti trovare più livelli di astrazione su sorgenti e amp; sink (uno molto generale, uno più specifico dei protocolli che implementa il generale mentre aggiunge alcune cose specifiche del protocollo); utilizzare le interfacce e posizionarle al di fuori dei protocolli e delle implementazioni.