Des problèmes avec la circulaire de la dépendance et de la programmation orientée objet en AngularJS

AngularJS + la programmation orientée objet est un peu sexy fonctionnalité à utiliser

Salut, je suis avec succès à l'aide de la programmation orientée objet avec AngularJs pour un certain temps déjà (d'abord commencé avec angularjs avec l'héritage de la programmation orientée objet en action), la démarche permet de définir vos classes angulaire de services, que vous pourrez ensuite prolonger ou d'hériter de ce genre: 

Application.factory('AbstractObject', [function () {
    var AbstractObject = Class.extend({
        virtualMethod: function() {
           alert("Hello world");
        },
        abstractMethod: function() { //You may omit abstract definitions, but they make your interface more readable
           throw new Error("Pure abstract call");
        }
    });

    return AbstractObject; //You return class definition instead of it's instance
}]);

Application.factory('DerivedObject', ['AbstractObject', function (AbstractObject) {
    var DerivedObject = AbstractObject.extend({
        virtualMethod: function() { //Shows two alerts: `Hey!` and `Hello world`
            alert("Hey!");

            this._super();
        },
        abstractMethod: function() {
            alert("Now I'm not abstract");
        }
    });

    return DerivedObject;
}]);

Plunker: http://plnkr.co/edit/rAtVGAsNYggBhNADMeoT

en utilisant l'approche décrite, vous donne la possibilité de définir des classes qui magnifiquement intégrer dans angulaire de l'infrastructure. Vous obtenez toutes sortes de fonctionnalités intéressantes à partir de deux mondes - POO et AngularJs. L'injection de dépendance est gratuit pour vos classes, et il rend vos classes très simple, permet de mettre beaucoup de texte standard contrôleur de code dans certains de la classe de base qui peut ensuite être réutilisé.

Cependant

AngularJs infrastructure blocs précédemment décrit approche de déploie ses ailes sur tous les 100%. Le problème se produit lorsque vous essayez de définir récursive définitions de classe (c'est à dire récursive de l'agrégation), disons que vous avez deux définitions de classe comme Blog et Tag

Application.factory('Blog', ['Tag', function (Tag) {
    var Blog = Class.extend({
        tags: function() {
            return this.tags;
        }
    });

    return Blog;
}]);

Application.factory('Tag', ['Blog', function (Blog) {
    var Tag = Class.extend({
        Blogs: function() {
           return this.blogs;
        }
    });

    return Tag;
}]);

Ça ne marchera pas parce que les deux Blog et Tag sont auto-référencement eux-mêmes, provoquant la dépendance circulaire.

P. S

La dernière chose, j'ai trouvé un peu laid solution qui résout mon problème, dans mon cas précis, mais ne fonctionne pas, en général, et comme je l'ai dit, il n'est pas assez:

Application.factory('BlogNamespace', [function () {
    var Blog = Class.extend({
        tags: function() {
            return this.tags;
        }
    });

    var Tag = Class.extend({
        Blogs: function() {
           return this.blogs;
        }
    });

    return {
        Tag: Tag,
        Blog: Blog
    };
}]);

Question

Le correctif ci-dessus ne fonctionnera pas parce que les espaces de noms peuvent aussi être un objet de dépendance circulaire. Cela signifie qu'il n'est pas la solution au problème décrit, mais plutôt un niveau plus profond problème maintenant.

Des suggestions sur la façon dont il est possible de résoudre ce problème décrit dans le cas général?

InformationsquelleAutor Lu4 | 2013-10-13
  1. 67

    Une dépendance circulaire est toujours le signe de mélange de préoccupations, qui est vraiment une mauvaise chose. Miško Hevery, l'un des auteurs de AngularJS, explique une belle solution sur son blog génial. En bref, vous avez probablement un troisième service caché quelque part, qui est la seule partie de votre code vraiment nécessaire par les deux autres.

    • Blackhole, c'est très intéressant post que vous avez fournies, mon cas avec Tag et Blog prouve que Misko est juste, parce que ce sont des sortes d'entités de base de données qui se rapportent l'un à l'autre comme N:M et dans des bases relationnelles monde ce genre de situation est également résolu par le représentant de la troisième table relationnelle qui contient la référence à la fois à Tag et Blog comme BlogTags
    • Jusqu'ici tout va bien... Le vol est stable, l'approche décrite aide vraiment à l'identification des problématiques de mise en œuvre.
    • Je pense que votre approche est correcte et avoir circulaire deps dans le code est un peu de mauvaise chose à faire, donc la réponse va vous
    • avez-vous résoudre ce problème en ajoutant un BlogTags usine qui Blog et Tag obtenir injecté avec? J'aurais vraiment préféré ne pas ajouter de "se joindre à la table des classes" dans ma base de code si je peux l'aider... Si ma seule autre option est de dépendances circulaires à l'aide de $injetor.get comme vous l'avez souligné, je peut juste s'en tenir à cela.
    • Ouais j'ai un service ou d'un modèle nécessite un compte (vraiment une hiérarchie carte de n structures profondes) à partir d'autres modèles pour générer des "widgets" pour l'affichage des données. L'contenant des données a toute la logique métier à part, mais de générer de nouveaux widget cas lié à ces modèles, j'ai besoin de recherche premier les méta-données, avant de générer eux... je me sentirais en sécurité $de l'injecteur.obtenir pour ce cas d'utilisation.
    InformationsquelleAutor Blackhole
  2. 54

    Je vais répondre à ma propre question juste parce que j'ai trouvé un moyen technique de résolution de la question que j'ai posté sur. Mais avant cela, je vous encourage fortement à utiliser sa suggestion, puisqu'il permet de résoudre un ensemble de problèmes qui sont généralement causées par une mauvaise architecture. Veuillez vous préférez l'utilisation de son approche en premier, et le retour de courant dans le cas où vous savez ce que vous faites.

    Voilà:

    Vous pouvez utiliser $injector service et injecter les définitions nécessaires au moment de l'exécution, ce qui est légal du point de vue technique, mais encore une fois selon cette post (difficile d'imaginer qu'il est écrit en 2008), c'est comme une magie noire, le faire et il va vous frapper en arrière:

    Application.factory('Blog', ['$injector', function ($injector) {
    var Tag = $injector.get('Tag'); //Here is your tag

    ...    
}]);

Application.factory('Tag', ['Blog', function (Blog) {
    ...
}]);

    Modifier

    Il s'est avéré que l'approche actuelle est un exemple de Service Locator modèle, qui est du Cio Antipattern.

    • Cette réponse sauver ma journée! +1
    • Rejoignez le côté obscur 🙂
    • Je suggère de ne pas se soucier de l'anti-modèle commentaires/opinions sur le Service de localisation, comme pas tout le monde (moi y compris) est d'accord avec elle. En revanche ce que vous essayez de faire ici est juste de la modélisation des objets et de leurs relations à l'aide d'un Angulaire mécanisme spécifique pour l'atteindre (dont le but initial est d'autres), et à cet effet, vous ne devriez pas avoir à vous soucier de la suppression de cyclisme dépendances (à moins que vous ne pouvez pas trouver une solution, que l'on a déjà trouvé).
    • votre suggestion est une suggestion d'un de vraiment jeune et passionnée développeur 🙂 C'est vraiment cool que vous avez soumis des dogmes et des paradigmes, cela signifie que vous choisissez votre propre chemin. Cependant, pour moi, c'est drôle parce que je suis déjà trop vieux pour le suivre. Merci de ne pas prendre mes paroles comme une insulte, au lieu de les traiter comme la voix de l'expérience, le son de votre avenir. J'ai trouver une multitude de raisons de m'inquiéter au sujet de votre proposition. L'un d'eux est le fait que je sais qu'ils ont été écrits par le sang de nombreux innocents développeurs. Et je n'ai pas besoin tout le monde d'accord avec ce fait, j'ai juste besoin de gars intelligent
    • Bien sûr, la chose est que, dans ce cas (qui est celle de l'utilisation d'AngularJS les fournisseurs pour la mise en œuvre de la programmation orientée objet), vous ne devriez pas vous inquiéter à propos du changement de votre OO modèle (et donc s'éloigner de votre modèle mental?) lors de la raison pour cela est que vous êtes des conseils qui ont été conçus pour quelque chose d'autre. Si vous étiez à la mise en œuvre d'une application à l'aide de tout (oui, tout) d'injection de dépendance dans le cadre d'une langue à l'origine de la conception à la programmation orientée objet à l'esprit, vous n'auriez pas ce genre de questions, parce que vous ne seriez pas en essayant de "injecter" une définition de classe (vous pouvez probablement utiliser une instruction import).
    • Je suis d'accord que JS n'a pas été initialement réparer pour la programmation orientée objet, et c'est plus un manque plutôt que de bénéfices. Même dans ces mal supporté la situation, en ne suivant pas les règles de la programmation orientée objet, vous ne serez pas en mesure de formaliser la conception de votre logiciel, ne sera pas en mesure de les analyser à l'aide de logiciels typiques développement de l'outil. Vous allez finir par se tirer dans la jambe, votre logiciel contient une quantité massive de semblable, mais non réutilisables et non refactorable code. Vous perdrez le contrôle de votre code dès que la taille de votre équipe va dépasser les 3 développeurs. C'est vraiment grave limitation, l'entreprise ne peut pas se le permettre...
    • Cela ne fonctionne pas, $injecteur est littéralement ce que les rapports cycliques des dépendances à commencer par jsfiddle.net/iamwhitebox/1z2kua70
    • Il ne fonctionne pas pour les tests unitaires, mais si vous l'utilisez après le module est d'abord initialisé (en utilisant par exemple à l'intérieur d'une fonction dans le module), il fonctionne très bien. Je pense que Lu4 simplifié le cas quand il a écrit la réponse de sorte qu'il sera de courte durée.
    • J'ai un cas d'utilisation où je me sentirais en sécurité dans cette. Ont des modèles ou des services qui sont tous autonomes, logiquement. Mais j'ai génériques de conteneurs qui ont générés et de connaître les modèles qui lient pour. Ces vues peuvent représenter tous les modèles (qui adhèrent à une Interface spécifique), mais j'ai besoin de mon "widget" modèle à avoir accès à chaque modèle, afin de récupérer leur hiérarchie schéma à l'avant (donc nous savons combien les widgets de faire en premier lieu). Je ne peux pas avoir mon widget service être agnostique à d'autres modèles/services.
    • Tnx, j'ai essayé quelques autres manières de le faire, mais jusqu'à présent, c'est le seul qui fonctionne bien et n'est pas si mal que ça 🙁 🙂

    InformationsquelleAutor Lu4
  3. 1

    DERNIER RECOURS: NE PAS ENCOURAGER LES

    Dans mon cas, la meilleure façon de se déplacer d'une circulaire de la dépendance à des problème de ce genre dans angulaire, est à la fonction de déclenchement des appels via $rootScope-émissions. L'autre service peut ensuite écouter cette émission et de réagir avec la fonction souhaitée appel. Il peut ne pas être la solution la plus élégante, mais dans certains cas où l'interaction entre les services est essentiellement unidirectionnelle, de toute façon, il peut être une alternative raisonnable. (notez que cela permet également de retour-les valeurs à être passé à la fonction de diffuseur via des rappels uniquement)

    Un pseudo-exemple de ceci serait:

    angular.module('myApp').factory('service1', ["$rootScope",
  function($rootScope) {
    function func1() {
      //do something
    }
    $rootScope.$broadcast("callFunc2"); //calls func2 from service 1

    return {
      func1: func1
    }
  }
]);
angular.module('myApp').factory('service2', ["service1", "$rootScope",
  function(service1, $rootScope) {
    function func2() {
      //do something
    }
    service1.func1();  //calls func1 from service 2
    $rootScope.on("callFunc2", func2);
  }
]);
    • toute critique constructive?
    • J'ai pensé que j'ai atteint une limite dans les "ténèbres" lors de posté ma réponse à ma propre question (je fais référence à "côté obscur" blague dans les commentaires), mais maintenant je vois clairement ma réponse brille comme électrique ampoule de 100 watts par rapport à la vôtre )))
    • Sérieusement ce genre de code (c'est à dire la $broadcast) n'était pas sensée être largement utilisé dans la production (je veux dire de la façon dont vous le proposer) c'est pourquoi il a cette $ signe de dollar avant. $broadcast est l'un des plus grands défauts de conception qui n'a jamais été introduit angulaire. Il a gagné en popularité parmi embryon de communauté uniquement en raison d'un manque de compréhension / de la documentation et des exemples pour les premières versions de anguleux. Pour la plupart presque tous les cas d'utilisation qui implique $broadcast peut être réécrite en direct de l'appel de fonction. L'utilisation de $broadcast est un signe d'un problème dans votre application architecture.
    • La seule chose qui $broadcast fait bien à l'est de votre code opaque et imprévisible. Regarder quelqu'un de code, vous ne savez jamais ce cas, vous devez vous abonner. Vous ne pouvez jamais être sûr que vous avez les abonnés abonnez. Et lorsque l'événement se produit, vous ne savez jamais qui l'a initié. Il est toujours près à la magie noire, la magie noire. Ne l'utilisez pas, il fera de votre projet jusqu'mauvais, vraiment mauvais.
    • Une autre chose est le "factory", il est utilisé comme une instance de l'objet, c'est le deuxième plus grand problème de l'angle a. Le problème avec angulaire du service "pattern" est le fait que c'est juste un singleton (en raison de la façon DI œuvres angulaire) Et la construction de votre architecture de l'application en utilisant l'instance du singleton objets entraînera naïve de l'architecture de l'application. Il y a des tonnes d'autres motifs que peut et doit devenir utile au cours du développement par exemple aller pour le GoF. Mais qui suis-je pour donner des conseils, choisissez votre propre voie, coup sur votre propre bosses comme je l'ai fait et ensuite juger les gens réponses 🙂
    • eh bien, les leçons apprises ^^ je suppose que maintenant nous avons un bon anti-exemple de comment ne pas résoudre ce problème.. je vais revoir mon architecture et voir si je peux peut-être éviter complètement le problème. Donc oui: bienvenue dans le côté obscur.

    InformationsquelleAutor Lars Frölich