Algorithmic Sets
Aus apemap-wiki
(Unterschied zwischen Versionen)
Mkurz (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „== Definition Algorithmic Set == * We want to define an algorithms set via a Predicate deciding if an element is part of the set.“) |
Mkurz (Diskussion | Beiträge) (→Decision explanation) |
||
(21 dazwischenliegende Versionen von einem Benutzer werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
== Definition Algorithmic Set == | == Definition Algorithmic Set == | ||
− | * We want to define an | + | * 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> | ||
+ | <pre> | ||
+ | public interface Predicate<T>{ | ||
+ | // If test returns true, we consider the element be part of the algorithmic set. | ||
+ | boolean test(T element); | ||
+ | } | ||
+ | |||
+ | </pre> | ||
+ | * 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. | ||
+ | * <b>An algorithmic set is defined by its predicate instance.</b> | ||
+ | |||
+ | == 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 == | ||
+ | * <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. | ||
+ | * 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: | ||
+ | <pre> | ||
+ | public class ConnectedClientTupel{ | ||
+ | public Computer getComputer(); // Including the Platz. | ||
+ | public User getUser(); // Including the role. | ||
+ | ... // Will grow in the future. | ||
+ | } | ||
+ | </pre> | ||
+ | * 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: | ||
+ | <pre> | ||
+ | public interface NotificationReceiverPredicate extends Predicate<ConnectedClientTupel> | ||
+ | { | ||
+ | } | ||
+ | </pre> | ||
+ | * 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. | ||
+ | |||
+ | |||
+ | == 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, 11:17 Uhr
Inhaltsverzeichnis |
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.