La modification d'un paramètre entrant est-elle un antipattern? [fermé]

Je programme en Java et je fabrique toujours des convertisseurs comme ceci:

public OtherObject MyObject2OtherObject(MyObject mo){
    ... Do the conversion
    return otherObject;
}

Sur le nouveau lieu de travail, la tendance est la suivante:

public void MyObject2OtherObject(MyObject mo, OtherObject oo){
    ... Do the conversion
}

Pour moi, cela sent un peu mauvais, car je me suis habitué à ne pas changer les paramètres entrants. Cette modification de paramètre entrante est-elle un antipattern ou est-ce correct? At-il de sérieux inconvénients?

Ce n'est pas un anti-modèle, c'est une mauvaise pratique.

La différence entre un anti-modèle et une simple mauvaise pratique est la suivante: définition anti-modèle .

Selon le nouveau code de Oncle Bob, le nouveau style de travail que vous montrez est une mauvaise pratique , vestigiale ou pré-OOP.

Les arguments sont naturellement interprétés comme des entrées dans une fonction.

Tout ce qui vous oblige à vérifier la signature de la fonction équivaut à une double-prise. C'est une rupture cognitive et devrait être évitée. Dans les jours précédents la programmation orientée objet, il était parfois nécessaire de disposer d'arguments de sortie. Cependant, une grande partie du besoin d'arguments de sortie disparaît dans les langages OO

Citant le célèbre livre de Robert C. Martin "Clean Code":

Les arguments de sortie doivent être évités

Les fonctions doivent avoir un petit nombre d'arguments

Le second modèle enfreint les deux règles, en particulier l'argument "argument de sortie". En ce sens, il est pire que le premier schéma.

Le deuxième idiome peut être plus rapide, car l'appelant peut réutiliser une variable sur une longue boucle, au lieu de chaque itération créant une nouvelle instance.

Je ne l'emploierais généralement pas, mais par exemple. la programmation de jeu a sa place. Par exemple, le nombre d'opérations Vector3f de JavaMonkey permet de transmettre des instances qui doivent être modifiées et renvoyées comme résultat.

Je ne pense pas que ce sont deux morceaux de code équivalents. Dans le premier cas, vous devez créer le fichier otherObject. Vous pouvez modifier l'instance existante dans la seconde. Les deux ont ses utilisations. L'odeur de code serait préférer l'un à l'autre.

Cela dépend vraiment de la langue.

En Java, la seconde forme peut être un anti-motif, mais certains langages traitent le passage de paramètre différemment. En Ada et VHDL par exemple, au lieu de passer par valeur ou par référence, les paramètres peuvent avoir des modes in, outou in out.

C'est une erreur de modifier un inparamètre ou de lire un outparamètre, mais toute modification apportée à un in outparamètre est renvoyée à l'appelant.

Donc, les deux formes en Ada (ce sont aussi des VHDL légales) sont

function MyObject2OtherObject(mo : in MyObject) return OtherObject is
begin
    ... Do the conversion
    return otherObject;
end MyObject2OtherObject;

et

procedure MyObject2OtherObject(mo : in MyObject; oo : out OtherObject) is
begin
    ... Do the conversion
    oo := ... the conversion result;
end MyObject2OtherObject;

Les deux ont leurs utilisations; une procédure peut renvoyer plusieurs valeurs dans plusieurs Outparamètres, tandis qu'une fonction ne peut renvoyer qu'un seul résultat. Étant donné que l'objectif du deuxième paramètre est clairement indiqué dans la déclaration de procédure, aucune objection ne peut être opposée à ce formulaire. J'ai tendance à préférer la fonction pour la lisibilité. mais il y aura des cas où la procédure est meilleure, par exemple, lorsque l'appelant a déjà créé l'objet.

Cela semble effectivement malodorant, et sans plus de contexte, il est impossible de le dire avec certitude. Il pourrait y avoir deux raisons pour cela, bien qu'il existe des alternatives pour les deux.

Tout d'abord, il s'agit d'une manière concise d'implémenter une conversion partielle ou de laisser le résultat avec des valeurs par défaut en cas d'échec de la conversion. C'est-à-dire que vous pourriez avoir ceci:

public void ConvertFoo(Foo from, Foo to) {
    if (can't convert) {
        return;
    }
    ...
}

Foo a;
Foo b = DefaultFoo();
ConvertFoo(a, b);
// If conversion fails, b is unchanged

Bien entendu, cela est généralement traité à l'aide d'exceptions. Cependant, même si des exceptions doivent être évitées pour une raison quelconque, il existe un meilleur moyen de procéder: le modèle TryParse étant une option.

Une autre raison est que cela pourrait être uniquement pour des raisons de cohérence. Par exemple, cela fait partie d'une API publique dans laquelle cette méthode est utilisée pour toutes les fonctions de conversion pour une raison quelconque (telle que d'autres fonctions de conversion ayant plusieurs sorties).

Java n'a pas l'habitude de gérer plusieurs sorties - il ne peut pas avoir de paramètres de sortie comme certaines langues, ni avoir plusieurs valeurs de retour comme d'autres - mais vous pouvez quand même utiliser des objets de retour.

La raison de la cohérence est plutôt boiteuse mais malheureusement, elle est peut-être la plus courante.

• Peut-être que les flics de style sur votre lieu de travail (ou votre base de code) proviennent d'un contexte autre que Java et ont été réticents à changer.
• Votre code peut avoir été un port d'une langue où ce style est plus idiomatique.
• Votre entreprise peut avoir besoin de maintenir la cohérence des API dans différentes langues. Il s’agissait du style avec le plus petit dénominateur commun (c'est idiot, mais cela arrive même pour Google ).
• Ou peut-être que le style avait plus de sens dans un passé lointain et était transformé dans sa forme actuelle (par exemple, il pourrait s'agir du modèle TryParse mais un prédécesseur bien intentionné a supprimé la valeur de retour après avoir découvert que personne ne l'avait cochée du tout).

L’avantage du second modèle est qu’il oblige l’appelant à assumer la propriété et la responsabilité de l’objet créé. Il n'est pas question de savoir si la méthode a créé ou non l'objet ou l'a obtenu à partir d'un pool réutilisable. L'appelant sait qu'il est responsable de la durée de vie et de la disposition du nouvel objet.

Les inconvénients de cette méthode sont les suivants:

1. Ne peut pas être utilisé en tant que méthode d'usine, l'appelant doit connaître le sous-type exact dont OtherObjectil a besoin et le construire à l'avance.
2. Ne peut pas être utilisé avec des objets nécessitant des paramètres dans leur constructeur si ces paramètres proviennent de MyObject. OtherObjectdoit être constructible sans savoir MyObject.

La réponse est basée sur mon expérience en c #, j'espère que la logique se traduira en Java.

Compte tenu de la sémantique vague - qui myObjectToOtherObjectpourrait également signifier que vous déplacez certaines données du premier objet vers le deuxième ou que vous les convertissez entièrement à nouveau, la deuxième méthode semble plus appropriée.

Cependant, si le nom de la méthode était Convert(ce qui devrait être le cas si nous examinons la partie "... faites la conversion"), je dirais que la deuxième méthode n'aurait aucun sens. Vous ne convertissez pas une valeur en une autre valeur existante, IMO.