Algorithmic Sets: Unterschied zwischen den Versionen

Aus apemap Wiki
Zur Navigation springen Zur Suche springen
imported>Mkurz
imported>Mkurz
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 12: Zeile 12:
* So if a new predicate is needed only a new implementation of Predicate<T> needs to be implemented.
* So if a new predicate is needed only a new implementation of Predicate<T> needs to be implemented.
* These Predicate<T> implementations can introduce configurable properties, for a more flexible solution.
* These Predicate<T> implementations can introduce configurable properties, for a more flexible solution.
* <b>Definition:</b> An algorithmic set is defined by its predicate instance.
* <b>An algorithmic set is defined by its predicate instance.</b>


== Performance considerations ==
== Performance considerations ==
Zeile 23: Zeile 23:


== Algorithmic sets and Notifications ==
== Algorithmic sets and Notifications ==
* We want to define the receivers of a notification with an algorithmic set.
* <b>We want to define the receivers of a notification with an algorithmic set.</b>
* This means every Notification has an algorithmic set of receivers attached to it.
* This means every Notification has an algorithmic set of receivers attached to it.
* How this algorithmic set of receivers is attached is not part of this article.
* How this algorithmic set of receivers is attached is not part of this article.
Zeile 42: Zeile 42:
</pre>
</pre>
* Every connected client queries its notifications via a REST interface.
* Every connected client queries its notifications via a REST interface.
* <b>All notifications should be grouped by their NotificationReceiverPredicate instances</b>.
* So instead of testing the predicate for every notification we only need to test every predicate instance once.
* The amount of different predicate instances is relatively low, so we should be capable of delivering the notifications to a client reasonable fast.


== Named Notifications Recipient Groups ==
* The software consultants (SWC) should be able to define named recipient groups.
* The SWCs should be able to test such a recipient group.


* If the amount of different algorithmic sets is relatively low (this is often the case), it makes sense to group
 
== Decision explanation ==
* It is required to give information to the SWC about the decision process.
* To allow this we should introduce an extended Predicate<T> interface with an optional decisision explanation parameter.

Aktuelle Version vom 8. November 2014, 10:17 Uhr

Definition Algorithmic Set

  • We want to define an algorithmic set via a Predicate deciding if an element is part of the set or not.
  • In java we could use the functional interface Predicate<T>
public interface Predicate<T>{
       // If test returns true, we consider the element be part of the algorithmic set.
       boolean test(T element);
}

  • Such a simple definition allows a polymorphic approach for defining set predicates.
  • So if a new predicate is needed only a new implementation of Predicate<T> needs to be implemented.
  • These Predicate<T> implementations can introduce configurable properties, for a more flexible solution.
  • An algorithmic set is defined by its predicate instance.

Performance considerations

  • This approach is only reasonable if all tested elements are in memory, querying them from a database would be at least suboptimal.

Logical Groups

  • For predicate aggregation we could simply implement PredicateCollections.
  • PredicateCollectionOr<T>
  • PredicateCollectionAnd<T>

Algorithmic sets and Notifications

  • We want to define the receivers of a notification with an algorithmic set.
  • This means every Notification has an algorithmic set of receivers attached to it.
  • How this algorithmic set of receivers is attached is not part of this article.
  • For identifying a receiver, we introduce a ConnectedClientTupel of the form:
public class ConnectedClientTupel{
    public Computer getComputer(); // Including the Platz.
    public User getUser(); // Including the role.
    ... // Will grow in the future.
}
  • Practically the above tupel, will be part of the session, but it seems reasonable not to use the session directly for a cleaner interface.
  • So the Predicate for Notification receivers would have the form:
public interface NotificationReceiverPredicate extends Predicate<ConnectedClientTupel>
{
}
  • Every connected client queries its notifications via a REST interface.
  • All notifications should be grouped by their NotificationReceiverPredicate instances.
  • So instead of testing the predicate for every notification we only need to test every predicate instance once.
  • The amount of different predicate instances is relatively low, so we should be capable of delivering the notifications to a client reasonable fast.

Named Notifications Recipient Groups

  • The software consultants (SWC) should be able to define named recipient groups.
  • The SWCs should be able to test such a recipient group.


Decision explanation

  • It is required to give information to the SWC about the decision process.
  • To allow this we should introduce an extended Predicate<T> interface with an optional decisision explanation parameter.