J'ai deux types de clients, un type " Observateur " et un type " Objet ". Ils sont tous deux associés à une hiérarchie de groupes .
L'observateur recevra les données (calendaires) des groupes auxquels il est associé dans les différentes hiérarchies. Ces données sont calculées en combinant les données des groupes «parents» du groupe essayant de collecter des données (chaque groupe ne peut avoir qu'un seul parent ).
Le sujet pourra créer les données (que les observateurs recevront) dans les groupes auxquels ils sont associés. Lorsque des données sont créées dans un groupe, tous les «enfants» du groupe auront également les données, et ils pourront créer leur propre version d'une zone spécifique des données , mais toujours liées aux données d'origine créées (dans mon implémentation spécifique, les données d'origine contiendront la ou les périodes et le titre, tandis que les sous-groupes spécifient le reste des données pour les récepteurs directement liés à leurs groupes respectifs).
Cependant, lorsque le sujet crée des données, il doit vérifier si tous les observateurs concernés ont des données en conflit avec cela, ce qui signifie une énorme fonction récursive, pour autant que je puisse comprendre.
Je pense donc que cela peut se résumer au fait que je dois pouvoir avoir une hiérarchie dans laquelle vous pouvez monter et descendre , et certains endroits peuvent les traiter comme un tout (récursion, essentiellement).
De plus, je ne vise pas seulement une solution qui fonctionne. J'espère trouver une solution relativement facile à comprendre (au moins en termes d'architecture) et également suffisamment flexible pour pouvoir recevoir facilement des fonctionnalités supplémentaires à l'avenir.
Existe-t-il un modèle de conception ou une bonne pratique pour résoudre ce problème ou des problèmes de hiérarchie similaires?
MODIFIER :
Voici le design que j'ai:
La classe "Phoenix" est nommée ainsi parce que je n'ai pas encore trouvé de nom approprié.
Mais en plus de cela, je dois pouvoir cacher des activités spécifiques pour des observateurs spécifiques , même s'ils y sont attachés par le biais des groupes.
Un peu hors sujet :
Personnellement, je pense que je devrais être capable de couper ce problème en petits problèmes, mais cela m'échappe comment. Je pense que c'est parce qu'il implique plusieurs fonctionnalités récursives qui ne sont pas associées les unes aux autres et différents types de clients qui doivent obtenir des informations de différentes manières. Je ne peux pas vraiment envelopper ma tête. Si quelqu'un peut me guider sur la façon de mieux encapsuler les problèmes de hiérarchie, je serais très heureux de le recevoir également.
la source
n
avec un degré de 0 alors que chaque autre sommet a un degré d'au moins 1? Chaque sommet est-il connectén
? Le chemin vers l'n
unique est-il unique? Si vous pouviez lister les propriétés de la structure de données et en résumer les opérations à une interface - une liste de méthodes - nous (I) pourrions peut-être trouver une implémentation de ladite structure de données.O(n)
algorithmes efficaces pour une structure de données bien définie, je peux y travailler. Je vois que vous n'avez pas appliqué de méthode de mutationGroup
ni de structure des hiérarchies. Dois-je supposer que ceux-ci seront statiques?Réponses:
Voici une implémentation simple de «groupe» qui vous permet de naviguer vers la racine et de naviguer dans l'arborescence de cette racine en tant que collection.
Donc - étant donné un groupe, vous pouvez parcourir l'arbre de ce groupe:
Mon espoir en publiant ceci, est qu'en montrant comment naviguer dans un arbre (et en dissipant la complexité de celui-ci), vous pourrez peut-être visualiser les opérations que vous souhaitez effectuer sur l'arbre, puis revisiter les modèles par vous-même pour voir ce qui s'applique le mieux.
la source
Avec la vue limitée que nous avons des exigences d'utilisation ou d'implémentation de votre système, il est difficile d'être trop précis. Par exemple, les éléments qui pourraient être pris en considération pourraient être:
En ce qui concerne les modèles, etc., je m'inquiéterais moins des modèles exacts qui surgissent dans votre solution et plus de la conception de la solution réelle. Je pense que la connaissance des modèles de conception est utile, mais pas la finalité: pour utiliser une analogie d'écrivain, les modèles de conception ressemblent plus à un dictionnaire de phrases courantes, plutôt qu'à un dictionnaire de phrases, vous devez écrire un livre entier de.
Votre diagramme me semble généralement correct.
Il y a un mécanisme que vous n'avez pas mentionné et c'est d'avoir une sorte de cache dans votre hiérarchie. Évidemment, vous devez l'implémenter avec grand soin, mais cela pourrait améliorer considérablement les performances de votre système. Voici une prise simple à ce sujet (caveat emptor):
Pour chaque nœud de votre hiérarchie, stockez les données héritées avec le nœud. Faites cela paresseusement ou de manière proactive, c'est à vous de décider. Lorsqu'une mise à jour est effectuée dans la hiérarchie, vous pouvez soit régénérer les données de cache pour tous les nœuds affectés là-bas, soit définir des indicateurs `` sales '' aux endroits appropriés et faire en sorte que les données affectées soient par la suite recréées si nécessaire.
Je n'ai aucune idée de la pertinence de cela dans votre système, mais cela peut valoir la peine d'être considéré.
En outre, cette question sur SO peut être pertinente:
/programming/1567935/how-to-do-inheritance-modeling-in-relational-databases
la source
Je sais que c'est un peu évident, mais je vais le dire de toute façon, je pense que vous devriez jeter un coup d'œil à
Observer Pattern
ce que vous avez mentionné que vous avez un type d'observateur et ce que vous avez ressemble un peu au modèle d'observateur pour moi.quelques liens:
DoFactory
oodesign
vérifiez-les. sinon, je voudrais simplement coder ce que vous avez dans votre diagramme, puis utiliser le modèle de conception pour simplifier si nécessaire. vous savez déjà ce qui doit arriver et comment le programme est censé fonctionner. Écrivez du code et voyez s'il convient toujours.
la source