Programmation pour l'utilisation future des interfaces

J'ai un collègue assis à côté de moi qui a conçu une interface comme celle-ci:

public interface IEventGetter {

    public List<FooType> getFooList(String fooName, Date start, Date end)
        throws Exception;
    ....

}

Le problème est que, pour le moment, nous n'utilisons pas ce paramètre "end" dans notre code, mais simplement parce que nous aurons peut-être besoin de l'utiliser ultérieurement.

Nous essayons de le convaincre que c’est une mauvaise idée d’introduire des paramètres dans des interfaces qui ne sont d'aucune utilité pour le moment, mais il continue d'insister sur le fait que beaucoup de travail devra être fait si nous implémentons l'utilisation de la "date de fin" quelque temps plus tard et doivent adapter tout le code alors.

Maintenant, ma question est la suivante: existe-t-il des sources traitant d'un sujet comme celui des gourous du code "respectés", vers lesquelles nous pouvons le relier?

Invitez-le à en savoir plus sur YAGNI . La partie "justification" de la page Wikipedia peut être particulièrement intéressante ici:

Selon ceux qui préconisent l’approche YAGNI, la tentation d’écrire du code qui n’est pas nécessaire pour le moment, mais qui pourrait l’être à l’avenir, présente les inconvénients suivants:

• Le temps consacré à l'ajout, au test ou à l'amélioration des fonctionnalités nécessaires est pris.
• Les nouvelles fonctionnalités doivent être déboguées, documentées et prises en charge.
• Toute nouvelle fonctionnalité impose des contraintes sur ce qui peut être fait dans le futur, ainsi une fonctionnalité inutile peut empêcher les fonctionnalités nécessaires d'être ajoutées à l'avenir.
• Tant que cette fonctionnalité n’est pas réellement nécessaire, il est difficile de définir complètement ce qu’elle doit faire et de la tester. Si la nouvelle fonctionnalité n'est pas correctement définie et testée, elle risque de ne pas fonctionner correctement, même si cela est éventuellement nécessaire.
• Cela conduit à un gonflement du code; le logiciel devient plus grand et plus compliqué.
• À moins de spécifications et d'une sorte de contrôle de révision, les programmeurs pourraient ne pas connaître cette fonctionnalité.
• L'ajout de la nouvelle fonctionnalité peut suggérer d'autres nouvelles fonctionnalités. Si ces nouvelles fonctionnalités sont également implémentées, cela pourrait se traduire par un effet boule de neige.

Autres arguments possibles:

• «80% du coût à vie d'un logiciel est destiné à la maintenance» . Écrire du code juste à temps réduit le coût de la maintenance: il faut maintenir moins de code et se concentrer sur le code réellement nécessaire.

• Le code source est écrit une fois, mais lu des dizaines de fois. Un argument supplémentaire, non utilisé nulle part, conduirait à une perte de temps en termes de compréhension du pourquoi d’un argument qui n’est pas nécessaire. Étant donné qu'il s'agit d'une interface avec plusieurs implémentations possibles, les choses ne sont que plus difficiles.

• Le code source devrait être auto-documenté. La signature elle-même est trompeuse, car le lecteur penserait que cela endaffecte le résultat ou l'exécution de la méthode.

• Les personnes écrivant des implémentations concrètes de cette interface peuvent ne pas comprendre que le dernier argument ne devrait pas être utilisé, ce qui conduirait à des approches différentes:

  1. Je n'ai pas besoin end, alors je vais simplement ignorer sa valeur,

  2. Je n'ai pas besoin end, alors je vais lancer une exception si ce n'est pas le cas null,

  3. Je n'ai pas besoin end, mais je vais essayer de l'utiliser,

  4. J'écrirai beaucoup de code qui pourrait être utilisé plus tard, quand ce endsera nécessaire.

Mais sachez que votre collègue a peut-être raison.

Tous les points précédents sont basés sur le fait que la refactorisation est facile, donc ajouter un argument plus tard ne nécessitera pas beaucoup d'effort. Mais il s’agit d’une interface. Elle peut être utilisée par plusieurs équipes contribuant à d’autres parties de votre produit. Cela signifie que changer une interface peut être particulièrement pénible, auquel cas, YAGNI ne s'applique pas vraiment ici.

La réponse de hjk donne une bonne solution: ajouter une méthode à une interface déjà utilisée n’est pas particulièrement difficile, mais dans certains cas, cela a aussi un coût substantiel:

• Certains frameworks ne supportent pas les surcharges. Par exemple, et si je me souviens bien (corrigez-moi si je me trompe), le WCF de .NET ne prend pas en charge les surcharges.

• Si l'interface comporte de nombreuses implémentations concrètes, l'ajout d'une méthode à l'interface nécessiterait de passer en revue toutes les implémentations et d'ajouter la méthode également.

mais il continue d'insister sur le fait qu'il reste beaucoup de travail à faire si nous implémentons l'utilisation de la "date de fin" quelque temps plus tard et si nous devons alors adapter tout le code.

(un peu plus tard)

public class EventGetter implements IEventGetter {

    private static final Date IMPLIED_END_DATE_ASOF_20140711 = new Date(Long.MAX_VALUE); // ???

    @Override
    public List<FooType> getFooList(String fooName, Date start) throws Exception {
        return getFooList(fooName, start, IMPLIED_END_DATE_ASOF_20140711);
    }

    @Override
    public List<FooType> getFooList(String fooName, Date start, Date end) throws Exception {
        // Final implementation goes here
    }
}

C'est tout ce dont vous avez besoin, la surcharge de méthodes. La méthode supplémentaire à l'avenir peut être introduite de manière transparente sans affecter les appels à la méthode existante.

[Y a-t-il] des gourous du code "respectés" que nous pouvons associer à [pour le persuader]?

Les appels à l'autorité ne sont pas particulièrement convaincants; préférable de présenter un argument qui est valable, peu importe qui l'a dit.

Voici une reductio ad absurdum qui devrait persuader ou démontrer que votre collègue est bloqué pour avoir "raison" indépendamment de sa sensibilité:

Ce dont tu as vraiment besoin c'est

getFooList(String fooName, Date start, Date end, Date middle, 
           Date one_third, JulianDate start, JulianDate end,
           KlingonDate start, KlingonDate end)

Vous ne savez jamais quand vous devrez internationaliser pour Klingon. Vous devez donc vous en occuper maintenant, car il faudra beaucoup de travail pour le mettre à niveau et les Klingons ne sont pas réputés pour leur patience.

Du point de vue du génie logiciel, je pense que la solution appropriée à ce type de problèmes réside dans le modèle de constructeur. C'est certainement un lien des auteurs de 'gourou' pour votre collègue http://en.wikipedia.org/wiki/Builder_pattern .

Dans le modèle de générateur, l'utilisateur crée un objet contenant les paramètres. Ce conteneur de paramètres sera ensuite passé à la méthode. Cela évitera toute extension et surcharge des paramètres dont votre collègue aurait besoin à l'avenir tout en rendant le tout très stable lorsque des changements doivent être apportés.

Votre exemple deviendra:

public interface IEventGetter {
    public List<FooType> getFooList(ISearchFooRequest req) {
        throws Exception;
    ....
    }
}

public interface ISearchFooRequest {
        public String getName();
        public Date getStart();
        public Date getEnd();
        public int getOffset();
        ...
    }
}

public class SearchFooRequest implements ISearchFooRequest {

    public static SearchFooRequest buildDefaultRequest(String name, Date start) {
        ...
    }

    public String getName() {...}
    public Date getStart() {...}
    ...
    public void setEnd(Date end) {...}
    public void setOffset(int offset) {...}
    ...
}

Vous n'en avez pas besoin maintenant, alors ne l'ajoutez pas. Si vous en avez besoin plus tard, étendez l'interface:

public interface IEventGetter {

    public List<FooType> getFooList(String fooName, Date start)
         throws Exception;
    ....

}

public interface IBoundedEventGetter extends IEventGetter {

    public List<FooType> getFooList(String fooName, Date start, Date end)
        throws Exception;
    ....

}

Aucun principe de conception n'est absolu. Par conséquent, bien que je sois généralement d'accord avec les autres réponses, je pensais que je deviendrais l'avocat du diable et discuterais de certaines conditions dans lesquelles j'accepterais d'accepter la solution de votre collègue:

• S'il s'agit d'une API publique et que vous pensez que cette fonctionnalité sera utile aux développeurs tiers, même si vous ne l'utilisez pas en interne.
• S'il présente des avantages immédiats considérables, pas seulement ceux à venir. Si la date de fin implicite est Now(), l'ajout d'un paramètre supprime un effet secondaire, ce qui présente des avantages pour la mise en cache et les tests unitaires. Peut-être que cela permet une implémentation plus simple. Ou peut-être est-il plus cohérent avec les autres API de votre code.
• Si votre culture de développement a une histoire problématique. Si les processus ou la territorialité rendent trop difficile la modification d'un élément central tel qu'une interface, ce que j'ai déjà vu se passe avant que des personnes implémentent des solutions de contournement côté client au lieu de modifier l'interface, vous essayez de conserver une douzaine de dates de fin ad hoc. filtres au lieu d'un. Si ce genre de chose se produit souvent dans votre entreprise, il est logique de consacrer un peu plus d'effort à la mise à l'épreuve du futur. Ne vous méprenez pas, il est préférable de modifier vos processus de développement, mais c'est généralement plus facile à dire qu'à faire.

Cela étant dit, selon mon expérience, le plus grand corollaire de YAGNI est YDKWFYN: Vous ne savez pas de quelle forme vous aurez besoin (oui, je viens de créer cet acronyme). Même si le besoin d' un paramètre limite peut être relativement prévisible, il peut prendre la forme d'une limite de pages, d'un nombre de jours ou d'un booléen spécifiant l'utilisation de la date de fin à partir d'un tableau de préférences utilisateur, ou un nombre important d'éléments.

Étant donné que vous n'avez pas encore l'exigence, vous n'avez aucun moyen de savoir quel type doit être ce paramètre. Vous vous retrouvez souvent avec une interface délicate qui ne correspond pas tout à fait à votre exigence, ou devant la modifier de toute façon.

Il n'y a pas assez d'informations pour répondre à cette question. Cela dépend de ce que getFooListfait réellement et de la façon dont il le fait.

Voici un exemple évident de méthode qui devrait supporter un paramètre supplémentaire, utilisé ou non.

void CapitalizeSubstring (String capitalize_me, int start_index);

Implémenter une méthode qui opère sur une collection où vous pouvez spécifier le début mais pas la fin de la collection est souvent ridicule.

Il faut vraiment examiner le problème lui-même et se demander si le paramètre est absurde dans le contexte de toute l'interface et quel est le fardeau imposé par le paramètre supplémentaire.

J'ai bien peur que votre collègue ait un argument très valable. Bien que sa solution ne soit en réalité pas la meilleure.

De son interface proposée, il est clair que

public List<FooType> getFooList(String fooName, Date start, Date end) throws Exception;

renvoie des instances trouvées dans un intervalle de temps. Si les clients n'utilisent pas actuellement le paramètre end, cela ne change rien au fait qu'ils s'attendent à des instances trouvées dans un intervalle de temps. Cela signifie simplement que tous les clients utilisent actuellement des intervalles ouverts (du début à la fin).

Donc, une meilleure interface serait:

public List<FooType> getFooList(String fooName, Interval interval) throws Exception;

Si vous fournissez intervalle avec une méthode fabrique statique:

public static Interval startingAt(Date start) { return new Interval(start, null); }

alors les clients ne ressentent même plus le besoin de spécifier une heure de fin.

Dans le même temps, votre interface indique plus correctement ce qu’elle fait, car getFooList(String, Date)elle ne communique pas qu’elle traite d’un intervalle.

Notez que ma suggestion découle de ce que la méthode fait actuellement, et non de ce qu'elle devrait ou pourrait faire à l'avenir, et en tant que tel, le principe de YAGNI (qui est en effet très valable) ne s'applique pas ici.

Ajouter un paramètre inutilisé est déroutant. Les gens peuvent appeler cette méthode en supposant que cette fonctionnalité fonctionnera.

Je ne l'ajouterais pas. Il est trivial de l'ajouter plus tard en utilisant une refactorisation et en réparant mécaniquement les sites d'appels. Dans un langage typé statiquement, cela est facile à faire. Pas nécessaire de l'ajouter avec empressement.

S'il est une raison d'avoir ce paramètre , vous pouvez éviter la confusion: Ajouter une assertion dans la mise en œuvre de cette interface pour faire respecter que ce paramètre soit passé comme la valeur par défaut. Si quelqu'un utilise accidentellement ce paramètre au moins, il remarquera immédiatement lors des tests que cette fonctionnalité n'est pas implémentée. Cela supprime le risque de glisser un bogue dans la production.