C de la question de la conception des programmes

Question

Dans quelques projets récents que j'ai participé j'étais presque accro au motif de codage suivant: (Je ne sais pas s'il y a un nom propre pour cela, mais quand même ...)

Disons un objet est dans un état déterminé et nous wan't de changer cet état de l'extérieur. Ces changements pourraient signifier tout comportement, pourraient invoquer des algorithmes, mais le fait est qu'ils se concentrent sur l'évolution de l'état (Etat membre, état de données, etc ...) d'un objet.

appel que l'un de façon discrète de changer les objet d'un Mutator. Mutators sont appliqués une fois (en général) et ils ont une méthode interne comme apply(Target& target, ...), qui provoque instantanément changer l'état de l'objet (en fait, ils sont une sorte d'objets fonctionnels).

Ils pourraient aussi être facilement assimilé dans chaînes et appliqué un par un (Mutator m1, m2, ...); ils pourraient également découler de certains BasicMutator de base avec la méthode virtual void apply(...).

J'ai introduit des classes appelées InnerMutator et ExplicitMutator qui diffèrent en termes d'accès - premier d'entre eux peuvent aussi changer le état interne de l'objet et doit être déclarée comme ami (friend InnerMutator::access;)

---

Dans ces projets ma logique se travailler de la manière suivante:

1. Préparer muteurs possibles, choisissez d'appliquer
2. Créer et mettre le object à un état déterminé
3. foreach (mutator) mutator.apply(object);

Maintenant la question.

  

Ce régime turnes à bien travailler et    (pour moi) semble qu'un échantillon d'une certaine conception non standard mais utile   modèle.

     

Ce qui me rend mal à l'aise est ce genre de choses de InnerMutator. Je ne ai pas   pensez déclarant mutator un ami à   chaque objet qui pourrait être l'état   changé est une bonne idée et je wan't à   trouver la solution appropriée.

     

Cette situation pourrait être résolue en termes de Mutators ou pourriez-vous   conseiller un certain modèle alternatif avec   le même résultat?

Merci.

Answer 1

J'espère que ce ne sont pas prises offensivement, mais je ne peux que penser cette conception est une solution trop de fantaisie pour un problème assez simple.

Pourquoi avez-vous besoin de mutators globaux, par exemple? On peut simplement écrire:

template <class T>
void mutate(T& t)
{
    t.mutate1(...);
    t.mutate2(...);
    t.mutate3(...);
}

Il est votre mutator total, seulement il est un modèle simple de fonction reposant sur le polymorphisme statique plutôt qu'une liste combinée de mutators faisant un super-mutator.

Une fois, je l'ai fait quelque chose qui aurait pu être assez similaire. Je fis des objets fonctionnels qui peuvent être combinées par l'opérateur && en super objets fonctionnels qui ont appliqué les deux opérandes (dans l'ordre de gauche à droite), de sorte que l'on peut écrire du code comme:

foreach(v.begin(), v.end(), attack && burn && drain);

Il était vraiment bien et m'a semblé très intelligent au moment et il était assez efficace car elle a généré de nouveaux objets de fonction à la volée (aucun mécanisme d'exécution impliqués), mais quand mes collègues l'ont vu, ils ont pensé que j'étais insensé. Avec le recul, je tentais de caser tout dans la programmation de style fonctionnel qui a son utilité, mais probablement ne devrait pas être trop compté dans C ++. Il aurait été assez facile à écrire:

BOOST_FOR_EACH(Something& something, v)
{
    attack(something);
    burn(something);
    drain(something);
}

Certes, il est plus de lignes de code, mais il a l'avantage d'être centralisé et facile à déboguer et à ne pas introduire des concepts étrangers à d'autres personnes travaillant avec mon code. Je l'ai trouvé beaucoup plus bénéfique au lieu de se concentrer sur la logique serrée plutôt que d'essayer de réduire avec force les lignes de code.

Je vous recommande de réfléchir profondément à ce sujet et vraiment considérer si cela vaut la peine de continuer avec cette conception à base mutator, peu importe comment intelligent et serré, il est. Si d'autres personnes ne peuvent pas comprendre rapidement, à moins que vous avez l'autorité des auteurs de stimuler, il va être difficile de convaincre les gens à l'aimer.

En ce qui concerne InnerMutator, je pense que vous devriez éviter comme la peste. Avoir des cours mutator externes qui peuvent modifier les éléments internes d'une classe aussi directement que possible défaites ici beaucoup de but d'avoir du tout internals.

Answer 2

Ne serait-il pas préférable de simplement faire ces méthodes Mutators des classes ils changent? S'il y a des fonctionnalités communes que vous voulez que plusieurs classes ont alors pourquoi ne pas les faire hériter de la même classe de base? Faire cela traitera tous les malaises imitatrice intérieure j'imagine.

Si vous voulez faire la queue changements que vous pouvez les stocker sous forme d'ensembles d'appels de fonction aux méthodes dans les classes.