Question

J'ai du mal à comprendre cela.Fondamentalement, cette Recherche de l'API est utilisée pour maintenir un couplage lâche entre les modules de la nature.Donc, fondamentalement, un fournisseur de services et de la consommation des modules peuvent communiquer les uns avec les autres à l'aide de la Recherche de l'API correct ?

Mais ce que je ne comprends pas, c'est:

est à la Recherche comme un sac plein d'objets pour la Classe?Quelqu'un peut-il donner une plus facile analogie ?

Donc les dépendances est créé, et vous mettre en œuvre la LookupListener dans le service consommateurs-elle correcte ?Évidemment, le consommateur a la dépendance du fournisseur.

Alors qu'est-ce que la mise en œuvre de LookupListener en train d'écouter ?C'est propre Recherche ?Donc si il y a une carte d'un autre module de classe, il sera stocké sous la forme d'un objet à l'intérieur de Recherche de la mise en œuvre de LookupListener ?

Donc recherche est comme une sorte de sac qui peut stocker un autre module de classes et de méthodes ?

Est-ce le bon processus de détermination d'une sélection ?

  1. dans le TopComponent (affichage) permet d'appliquer la Recherche à l'écoute, et l'action de l'Auditeur.
  2. vous faites un nouvel objet (à partir de l'autre module)
  3. associateLookup(Lookups.singleton(fff)); encore une fois, la confusion avec cette ligne:qu'est-ce que associateLookup() exactement en train de faire ?
  4. result = Utilities.actionsGlobalContext().lookupResult(Browser1.class); qu'est-ce que cette ligne fait ?quel est le résultat ?contient-il la Browser1 classe (à partir d'un autre module) ?
  5. result.addLookupListener (this);Pourquoi voudriez-vous ajouter un écouteur de résultat ?et que sommes-nous à l'écoute et pourquoi sur le TopComponent ?

  6. Fait ?

Et enfin, pour approfondir ma confusion , comment ne Nœud de l'API de venir en pla7y ?

Était-ce utile?

Autres conseils

Vous pouvez penser à des Recherches comme un outil de base qui prend en charge le couplage de haute principe de cohésion.

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

public interface Beverage {
   ...
}

Puis un autre module beers qui dépend de l' 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 permet d'obtenir une liste de toutes les boissons fournisseurs de partout, sans le déclarer exacte de la dépendance sur la classe spécifique ou d'avoir la dépendance de ce module.C'est super, votre code ne dépend pas de mise en œuvre spécifiques, il suffit d'avoir ces modules sur le chemin de classe, et ils "auto-magiquement" à charger dans votre application.

associateLookup(Lookups.singleton(fff)); encore une fois, la confusion avec cette ligne:qu'est-ce que associateLookup() exactement en train de faire ?

Oui, c'est déroutant.Fondamentalement, vous êtes d'ajouter manuellement un objet de recherche du système.

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

Utilities.actionsGlobalContext() est liée à actuellement sélectionné (actif) TopCompoment.Il retourne une instance de Beverage.class s'il existe dans le composant actif.Si vous voulez toutes les instances de la classe que vous devez utiliser lookupAll().

result.addLookupListener(this); Pourquoi voudriez-vous ajouter un écouteur de résultat ?

Pour recevoir des avis sur les modifications.Lorsque l'utilisateur sélectionne certains Beverages des objets, des déclencheurs LookupListener méthode:

void resultChanged(LookupEvent ev);

et result.allInstances(); sera de retour les instances qui ont été sélectionnés.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top