Est-ce que vous regardez les variables utilisées par une méthode avant de refactoriser une grande classe en plus petites?

Question

Je suis intéressé à explorer l'idée que la relation entre les méthodes et les membres varialbes qu'ils utilisent peut donner un indice sur la façon dont la classe pourrait être divisée en plus petits morceaux. L'idée est qu'un groupe de variables sera étroitement lié à une responsabilité et devrait être contenu dans une classe selon la SRP.

Pour un exemple trivial, une classe telle que:

public class Rectangle { 
    private int width; 
    private int height; 
    private int red,green,blue; 
    public int area() { return width * height; } 
//just an example, didn't check the api. 
    public Color color() { return new Color (red, green, blue); } 
} 

Devrait être remaniée:

public class Rectangle { 
    private Dimension size; 
    private Color color; 
    ... 
} 

Parce que le bas de rupture serait:

Zone: largeur, hauteur Couleur: rouge, vert, bleu

Puisque ces variables sont nous ed dans la même méthode, ils sont clairement liés et pourraient être transformés en une classe à part. Je sais que cet exemple pourrait être trop trivial mais supporter avec moi et essayer et penser plus grand ici. Si d'autres méthodes utilisent également ces variables, elles sont très probablement également liées et peuvent également être déplacées dans la nouvelle classe.

Juste pour le plaisir que j'ai créé un peu plugin for Eclipse qui essaye de faire ceci. Il aura une décomposition sur méthodes-> variables, variables-> et essayera aussi de regrouper les méthodes après quelles variables elles utilisent directement ou indirectement.

Est-ce quelque chose que vous faites lors du codage, et est-ce vraiment utile?

Answer 1

On dirait que quelqu'un a lu le Law of Demeter et tente de le prendre à l'extrême. Je dois dire que je traite toujours les fanatiques du «découplage» avec une certaine méfiance, notamment parce que certains préconisent un «couplage nul» dans la conception, tout en ignorant le fait que sans aucun couplage, un système est inutile. Néanmoins, en réduisant les dépendances dans le code, il est plus facile à tester et plus résilient aux autres refactoring, et je trouve qu'il a tendance à conduire à un code plus simple et plus évident. Un équilibre sain est l'objectif à atteindre.

Answer 2

Je ne peux pas dire que cela a déjà été quelque chose que j'ai pensé pendant le codage. Oui, cela pourrait entraîner une certaine amélioration, mais je pense que ce que vous pourriez faire en pratique, c'est créer un grand nombre de cours qui seraient encore plus difficiles à gérer. Cependant, il peut y avoir un certain mérite en tant que «odeur de code». Si vous voyez une classe avec des tonnes de variables membres, et la plupart ne sont utilisées que par une poignée de méthodes, c'est généralement un mauvais signe.

Answer 3

Cela semble être une mauvaise idée dans l'ensemble. Tout d'abord, une classe représente une collection de données et/ou de méthodes associées. Il n'a pas du tout besoin d'avoir des méthodes pour être toujours une classe utile. Pour une bonne encapsulation, vous pourriez vouloir des getters et setters; ces méthodes par définition n'accèderont pas à plus d'une variable. Cela n'implique en rien que ces variables appartiennent ou non à la même classe. Enfin, une méthode appartient à la classe si elle fournit un moyen de manipuler la classe, de calculer quelques informations sur elle-même, de construire la classe, etc .; Il existe des raisons infinies pour qu'une méthode appartienne à une classe mais n'accède pas à la plupart des variables membres. Ensuite, il y a des méthodes statiques; devraient-ils par définition être dans d'autres classes?

Une classe doit être divisée si elle contient trop de concepts. Mais ces concepts ne correspondent qu'aux méthodes et aux variables. Le comptage des utilisations variables est un moyen infaillible de compliquer votre hiérarchie de classe sans bénéfice.

Answer 4

Je pense que chaque classe devrait être organisée par ce qu'elle fait, et non par les variables qu'elle utilisera. Je recommanderais de faire en sorte que chaque cours ait un seul but (principe de responsabilité unique). Au lieu de casser les choses en fonction de leur utilisation de variables, les classes séparées en fonction de leur responsabilité ou de leur but. À mon avis, écrire du code propre n'est pas seulement un bon aspect du code, mais aussi sa facilité de lecture. Le code doit être groupé logiquement et avoir un style cohérent. Gardez à l'esprit que certaines classes ne vont pas utiliser toutes les variables. En Java, vous avez des méthodes de mutateur et d'accesseur. Ces méthodes sont utilisées pour obtenir ou définir une seule variable.

Exemple:

public class Rectangle { 

    private int lenght = 0; 
    private int width = 0; 

    public Rectangle (int length, width) 
     { 
     this.length = length; 
     this.width = width; 
    } 

    public int getLength(int length) 
    { 
     return length; 
    } 

    public int getWidth(int width) 
    { 
     return wdith; 
    } 


    public void setLength(int length) 
    { 
     this.length = length; 
    } 

    public void setWidth(int width) 
    { 
     this.width = width; 
    } 
} 

Je ne cassera pas cette classe dans une classe RectangleLength et RectangleWidth. Ces méthodes servent une seule responsabilité et c'est de représenter un rectangle. Si cette classe contenait des fonctions mathématiques, vous pourriez vouloir la décomposer en classe RectangleGeometry.

Answer 5

Je peux imaginer une situation où c'est une odeur de code raisonnable. Les simples setters/getters dans notre exemple ne sont pas trop persuasifs. Par exemple, refactoring fait qu'un objet plus complexe qui porte a et b autour de:

public class A { 
    private String a1; 
    public void aMeth() { 
    print(a1); 
    } 
} 
public class B { 
    private String b1; 
    public void bMeth() { 
    print(b1); 
    } 
} 

public class A { 
    private A a; 
    private B b; 
    ... insert infinite regress 
} 

Cependant, je peux voir cela comme un guide où vous avez des ensembles de variables empêtrés dans les grandes classes de monstres, où les groupements variables correspondent à la décomposition conceptuelle. Pensez-vous plus à quelque chose comme ça?

public class Rectangle { 
    private int width; 
    private int height; 
    private int red,green,blue; 
    public int area() { return width * height; } 
//just an example, didn't check the api. 
    public Color color() { return new Color (red, green, blue); } 
} 

Lorsque le rectangle doit avoir une dimension et une couleur. Il me semble que si vous pouvez clairement trouver des ensembles de variables privées qui s'emmêlent seulement les uns avec les autres, c'est une chose utile, tant que vous omettez les variables non enchevêtrées (ie Si vous pensez aux variables comme des sommets de graphes, je pense vous voudriez détecter les sous-graphes connectés mais omettez les sous-graphes de taille 1)

Answer 6

J'ai fait ceci. Même créé un tableau, les méthodes de la première colonne, les variables d'instance en haut, avec un X pour indiquer qui utilise qui. Puis trier - sorte de heatmaps comme sont triés, mais plus à la légère, plus manuellement - pour voir quelles variables, et quelles méthodes, suivre ensemble. Cela fonctionne et c'est utile. Mais c'est au fond de mon sac de trucs; Je l'ai rarement utilisé. Je vais devoir vérifier votre plugin; si c'était moins de travail pour le faire, je pourrais le faire plus.

Answer 7

C'est certainement une bonne approche de refactoring. Dans Working Effectively With Legacy Code, Michael Feathers décrit une technique pour cela dans une section intitulée Responsabilités Seeing:

Heuristique # 4 Rechercher des relations internes

Rechercher les relations entre les variables et les méthodes exemple. Certaines variables d'instance sont-elles utilisées par certaines méthodes et pas d'autres?

Il va ensuite décrire une méthode où vous dessinez un diagramme appelé esquisse de la fonction , qui est un graphique montrant les méthodes d'une classe et des appels de méthode internes. À partir du diagramme, vous pouvez facilement identifier visuellement des groupes d'appels de méthode interconnectés qui sont candidats à la refactorisation dans une nouvelle classe plus cohérente.

Il serait très cool que votre plugin Eclipse puisse générer rapidement un graphe comme décrit dans le livre - je pourrais le voir comme un outil de refactoring utile.