Qual è la ricerca di Netbean?

Question

Ho difficoltà a capire questo. Fondamentalmente, questa ricerca API è usata per mantenere la natura intermoduluminata liberamente accoppiata. Quindi, in pratica, un fornitore di servizi e i moduli di consumo possono ogni comunicare tra loro utilizzando l'API di ricerca corretto?

Ma quello che non capisco è:

La ricerca è come una borsa piena di quali oggetti per quella classe? Qualcuno può dare un'analogia più facile?

Quindi vengono create le dipendenze e implementate il lookuplisener nel consumatore del servizio corretto? Ovviamente il consumatore ha dipendenza dal fornitore.

Allora, qual è l'implementazione di lookupListener che ascolta? La ricerca personale? Quindi, se c'è una mappa della classe di un altro modulo, verrà memorizzata come oggetto all'interno della ricerca dell'attuazione di LookupListener?

Quindi la ricerca è un po 'come una borsa che può memorizzare le classi di un altro modulo e i suoi metodi?

È questo il processo corretto di determinare una selezione?

.
1. nel topcomponent (View) implementato il listener di ricerca e l'ascolto dell'azione.
2. fai un nuovo oggetto (dall'altro modulo)
3. associateLookup(Lookups.singleton(fff)); di nuovo, confusione con questa linea: cosa sta esattamente facendo associateLookup()?
4. result = Utilities.actionsGlobalContext().lookupResult(Browser1.class); Cosa sta facendo questa linea? Cosa è risultato? Contiene la classe Browser1 (da altro modulo)?

5. result.addLookupListener (this); Perché dovresti aggiungere listener il risultato? E cosa stiamo ascoltando e perché sul topcomponent?

6. Fatto?

E infine, per ulteriormente la mia confusione, come entra in Pla7y API del nodo?

Answer 1

C'è un buona discussione dell'API della ricerca della piattaforma NetBeans .

Answer 2

Puoi pensare alle ricerche come strumento di base che supporta Accoppiamento allentato alta coesione Principio .

Fondamentalmente hai un API nel modulo beverage-api:

public interface Beverage {
   ...
}

.

Allora un altro modulo beers che dipende da beverage-api:

@ServiceProvider(service = Beverage.class)
public class SomeBeer implements Beverage {
   ...
}

.

In un altro modulo che dipende anche da beverage-api è possibile scrivere una formula magica:

Collection list = Lookup.getDefault().lookupAll(Beverage.class);

.

che ti porterà un elenco di tutti i fornitori di bevande in giro senza dichiarare la dipendenza esatta dalla classe specifica o dalla dipendenza da quel modulo. Questo è fantastico, il tuo codice non dipende da un'implementazione specifica, è sufficiente avere questi moduli sul percorso di classe e si "automaticamente magicamente" vengono caricati nella tua applicazione.

.

associateLookup(Lookups.singleton(fff)); di nuovo, confusione con questa linea: cosa è AssociateLookup () esattamente facendo?

Sì, è confuso. Fondamentalmente stai aggiungendo manualmente un oggetto al sistema di ricerca.

.

result = Utilities.actionsGlobalContext().lookupResult(Beverage.class);

Utilities.actionsGlobalContext() è correlato al TopCompoment attualmente selezionato (attivo). Restituirà un'istanza di Beverage.class se esiste nel componente attivo. Se si desidera tutte le istanze della classe data è necessario utilizzare lookupAll().

.

result.addLookupListener(this); Perché aggiungere il risultato del ascoltatore?

per ottenere la notifica sulle modifiche. Quando l'utente seleziona alcuni oggetti Beverages innesca il metodo LookupListener:

void resultChanged(LookupEvent ev);

.

e result.allInstances(); restituiranno quali istanze sono state selezionate.