2010-07-15 5 views
1

Je travaille avec un type qui passe l'état à travers des variables d'instance. Donc, vous verrez des méthodes comme ça:Comment j'appelle ce style de programmation?

public MyType MyMethod() 
{ 
    DoThisMethod(); 
    DoThatMethod(); 
    AndDoThis(); 

    return _bleh; 
} 

Est-ce une approche reconnue?

C'est un peu déconcertant de travailler avec ce code car si vous ne comprenez pas complètement le code, la variable d'instance pourrait être transformée à votre insu par une autre méthode. Si à la place l'état a été passé via les paramètres de la méthode, alors vous pouvez être très sûr de la valeur du paramètre passé.

Répondre

5

Si l'ordre de ces appels de méthode est important, je qualifierais cela de «mauvaise programmation» - comme vous l'avez dit, toute méthode nécessitant un appel antérieur devrait utiliser des paramètres de méthode qui indiquent cela. Je suis assez sûr que Code Complete donne de bons exemples de cette approche.

Fondamentalement quelque chose comme le suivant, où chaque méthode nécessite le résultat de l'invocation précédente.

public MyType MyMethod() 
{ 
    thisResult = DoThisMethod(); 
    thatResult = DoThatMethod(thisResult); 
    _bleh = AndDoThis(thatResult); 

    return _bleh; 
} 

En second lieu, je tiens à garder les méthodes « orthogonale » autant que possible (c'est qu'ils ne dépendent que de l'état que vous les fournissez entre autres). Pour un excellent résumé sur le code orthogonal, voir this article.

+0

+1 pour l'orthogonalité. –

+0

+1 l'article était assez intéressant. – InsertNickHere

+2

depuis que vous avez élevé c.c .: ce livre l'appelle "cohésion séquentielle" et dit que c'est acceptable, mais devrait être recompilé pour montrer une cohésion fonctionnelle. –

1

On dirait qu'il y a une incompréhension de la raison pour laquelle les globals sont mauvais. Je ne connais pas de nom pour ce style particulier, mais sachez que c'est presque aussi mauvais que d'utiliser des globals - j'imagine que les choses vont se casser si les fonctions sont appelées dans le désordre.

+0

cHao - merci. Je cherchais une validation de mon opinion. Le code est assez mauvais pour travailler avec. La dépendance implicite sur l'ordre d'invocation est un bon point. – Ben

4

Décomposition fonctionnelle, d'une manière générale. Le modèle que vous décrivez est parfois indicatif d'un code qui est (a) trop décomposé, ce qui entraîne le problème que vous devez tracer le chemin d'exécution pour voir le comportement combiné résultant, ou (b) en faire trop. En transformant ces méthodes pour prendre des paramètres au lieu de s'appuyer sur l'état interne, vous pouvez les rendre plus testables et probablement plus lisibles. Vous pouvez muter l'état si nécessaire dans la fonction la plus externe.

2

C'est le contraire de la programmation fonctionnelle. La chose la plus proche que je puisse penser est la "programmation avec état" mais cela ne semble pas assez péjoratif. Il est probablement qualifié de programmation structurée. En passant, si vous considérez les requêtes HTTP comme étant analogues aux appels de méthode, et qu'une implémentation "Session" ressemble à une instance d'objet, c'est exactement comme cela que beaucoup de sites Web sont conçus. Et (IMHO) ce n'est pas un bon design, non plus.

0

Il est possible que le "couplage séquentiel" (http://en.wikipedia.org/wiki/Sequential_coupling) soit également reconnu si ces méthodes appelant l'ordre sont contraintes.

Questions connexes