Qu'est-ce que la recherche de netbean?

Question

J'ai du mal à comprendre cela. Fondamentalement, cette API Lookup est utilisée pour conserver une nature intermodule faiblement couplée. Donc, fondamentalement, un fournisseur de service et les modules de consommation peuvent chacun communiquer les uns avec les autres en utilisant l'API de recherche correcte?

Mais ce que je ne comprends pas:

est Lookup comme un sac plein dont les objets pour cette classe? Quelqu'un peut-il donner une analogie plus facile?

Donc les dépendances sont créées, et vous implémentez le LookupListener dans le consommateur de service correct? De toute évidence, le consommateur dépend du fournisseur.

Alors qu'est-ce que l'implémentation de LookupListener écoute? C'est propre Lookup? Donc, s'il y a une carte de la classe d'un autre module, elle sera stockée en tant qu'objet dans Lookup de l'implémentation de LookupListener? Donc, la recherche est un peu comme un sac qui peut stocker les classes et les méthodes d'un autre module?

Est-ce le bon processus de détermination d'une sélection? Dans le TopComponent (affichage), vous implémentez le port d'écoute de recherche et l'action Listener.

2. vous faites un nouvel objet (à partir de l'autre module)
3. associateLookup(Lookups.singleton(fff)); encore, la confusion avec cette ligne: qu'est-ce que associateLookup() exactement faire?
4. result = Utilities.actionsGlobalContext().lookupResult(Browser1.class); Que fait cette ligne? quel est le résultat? contient-il la classe Browser1 (à partir d'un autre module)?

5. result.addLookupListener (this); Pourquoi ajouteriez-vous l'écouteur au résultat? et qu'est-ce qu'on écoute et pourquoi sur le TopComponent?

6. Terminé?

Et enfin, pour compliquer davantage ma confusion, comment l'API Node peut-elle entrer dans pla7y?

Answer 1

Il existe un good discussion of the NetBeans platform Lookup API.

Answer 2

Vous pouvez considérer Lookups comme un outil de base qui prend en charge le couplage lâche haute cohésion principe.

Fondamentalement, vous avez une API dans beverage-api Module:

public interface Beverage { 
    ... 
} 

Ensuite, un autre module beers qui dépend beverage-api:

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

dans un autre module qui dépend aussi de beverage-api vous pouvez écrire une formule magique :

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

qui vous obtiendra une liste de tous les fournisseurs de boissons sans déclarer la dépendance exacte à la classe spécifique ou ayant une dépendance sur ce module. C'est génial, votre code ne dépend pas d'une implémentation spécifique, il suffit d'avoir ces modules sur le chemin de la classe et ils seront "magiquement" chargés dans votre application.

associateLookup(Lookups.singleton(fff));associateLookup(Lookups.singleton(fff)); encore une fois, confusion avec cette ligne: que fait exactement associateLookup()?

Oui, c'est déroutant. Fondamentalement, vous ajoutez manuellement un objet au système de recherche.

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

Utilities.actionsGlobalContext() est liée à actuellement sélectionnée (active) TopCompoment. Il renverra une instance de Beverage.class si elle existe dans le composant actif. Si vous voulez toutes les instances d'une classe donnée, vous devez utiliser lookupAll().

result.addLookupListener(this); Pourquoi ajouteriez-vous l'écouteur au résultat?

Pour être averti des modifications. Lorsque l'utilisateur sélectionne des objets Beverages il déclenche la méthode LookupListener:

void resultChanged(LookupEvent ev); 

et result.allInstances(); retournera les instances qui ont été sélectionnés.