Je garde mes propres affaires à la maison et ma femme vient à moi et dit

Chérie .. Pouvez-vous imprimer toutes les économies réalisées dans le monde entier pour la lumière du jour pour 2018 sur la console? J'ai besoin de vérifier quelque chose.

Et je suis super heureux parce que c’était ce que j’attendais de toute ma vie avec mon expérience de Java et de proposer:

import java.time.*;
import java.util.Set;

class App {
    void dayLightSavings() {
        final Set<String> availableZoneIds = ZoneId.getAvailableZoneIds();
        availableZoneIds.forEach(
            zoneId -> {
                LocalDateTime dateTime = LocalDateTime.of(
                    LocalDate.of(2018, 1, 1), 
                    LocalTime.of(0, 0, 0)
                );
                ZonedDateTime now = ZonedDateTime.of(dateTime, ZoneId.of(zoneId));
                while (2018 == now.getYear()) {
                    int hour = now.getHour();
                    now = now.plusHours(1);
                    if (now.getHour() == hour) {
                        System.out.println(now);
                    }
                }
            }
        );
    }
}

Mais ensuite, elle dit qu'elle testait juste si j'étais un ingénieur en logiciel ayant une formation éthique et me dit qu'il me semble que je ne le suis plus depuis (pris d' ici ).

Il convient de noter qu'aucun ingénieur en logiciel formé sur le plan éthique n'accepterait jamais d'écrire une procédure DestroyBaghdad. Une éthique professionnelle de base l'obligerait plutôt à écrire une procédure DestroyCity, à laquelle Bagdad pourrait être paramétré.

Et je suis comme, d'accord, d'accord, tu m'as obtenu .. Passe l' année que tu veux, voilà:

import java.time.*;
import java.util.Set;

class App {
    void dayLightSavings(int year) {
        final Set<String> availableZoneIds = ZoneId.getAvailableZoneIds();
        availableZoneIds.forEach(
            zoneId -> {
                LocalDateTime dateTime = LocalDateTime.of(
                    LocalDate.of(year, 1, 1), 
                    LocalTime.of(0, 0, 0)
                );
                ZonedDateTime now = ZonedDateTime.of(dateTime, ZoneId.of(zoneId));
                while (year == now.getYear()) {
                    // rest is same..

Mais comment savoir combien (et quoi) paramétrer? Après tout, pourrait-elle dire…

• elle veut passer un formateur de chaîne personnalisé, peut-être qu'elle n'aime pas le format dans lequel je suis déjà en train d'imprimer: 2018-10-28T02:00+01:00[Arctic/Longyearbyen]

void dayLightSavings(int year, DateTimeFormatter dtf)

• elle ne s'intéresse qu'à certains mois

void dayLightSavings(int year, DateTimeFormatter dtf, int monthStart, int monthEnd)

• elle s'intéresse à certaines heures

void dayLightSavings(int year, DateTimeFormatter dtf, int monthStart, int monthEnd, int hourStart, int hourend)

Si vous cherchez une question concrète:

Si destroyCity(City city)c'est mieux que destroyBaghdad(), c'est takeActionOnCity(Action action, City city)encore mieux? Pourquoi pourquoi pas?

Après tout, je peux d' abord l' appeler avec Action.DESTROYalors Action.REBUILD, est - ce pas?

Mais agir sur les villes ne me suffit pas, que diriez-vous takeActionOnGeographicArea(Action action, GeographicalArea GeographicalArea)? Après tout, je ne veux pas appeler:

takeActionOnCity(Action.DESTORY, City.BAGHDAD);

ensuite

takeActionOnCity(Action.DESTORY, City.ERBIL);

et ainsi de suite quand je peux faire:

takeActionOnGeographicArea(Action.DESTORY, Country.IRAQ);

PS J'ai construit ma question uniquement autour de la citation que j'ai mentionnée, je n'ai rien contre aucun pays, religion, race ou quoi que ce soit dans le monde. J'essaie juste de faire valoir un point.

C'est des tortues tout en bas.

Ou des abstractions dans ce cas.

Le codage de bonne pratique est une chose qui peut être appliquée à l'infini, et à un moment donné, vous abstenez dans un souci d'abstraction, ce qui signifie que vous l'avez poussé trop loin. Trouver cette ligne n’est pas chose facile à mettre en pratique, cela dépend beaucoup de votre environnement.

Par exemple, des clients connus pour demander d’abord des applications simples, puis des extensions. Nous avons également eu des clients qui demandent ce qu'ils veulent et qui ne nous reviennent généralement jamais pour une expansion.
Votre approche variera par client. Pour le premier client, il sera avantageux de prélever le code de manière préventive, car vous êtes raisonnablement certain que vous devrez le consulter ultérieurement. Pour le deuxième client, vous pouvez ne pas vouloir investir cet effort supplémentaire si vous vous attendez à ce qu’ils ne veuillent pas développer l’application à tout moment (remarque: cela ne signifie pas que vous ne respectez aucune bonne pratique, mais simplement que vous évitez de faire plus que ce qui est actuellement nécessaire.

Comment savoir quelles fonctionnalités implémenter?

La raison pour laquelle je mentionne ce qui précède est que vous êtes déjà tombé dans ce piège:

Mais comment savoir combien (et quoi) paramétrer? Après tout, pourrait-elle dire .

"Elle pourrait dire" n'est pas une exigence commerciale actuelle. C'est une supposition à un besoin commercial futur. En règle générale, ne vous basez pas sur des suppositions, développez seulement ce qui est actuellement requis.

Cependant, le contexte s'applique ici. Je ne connais pas ta femme. Peut-être que vous avez bien mesuré qu’elle le voudrait. Mais vous devez toujours confirmer avec le client que c'est bien ce qu'il veut, car sinon vous passerez du temps à développer une fonctionnalité que vous n'utiliserez jamais.

Comment savoir quelle architecture mettre en œuvre?

C'est plus compliqué. Le client ne se soucie pas du code interne, vous ne pouvez donc pas lui demander s'il en a besoin. Leur opinion sur la question est en grande partie hors de propos.

Cependant, vous pouvez toujours en confirmer la nécessité en posant les bonnes questions au client. Au lieu de poser des questions sur l'architecture, demandez-leur quelles sont leurs attentes en matière de développement futur ou de développement de la base de code. Vous pouvez également demander si l'objectif actuel est assorti d'une date limite, car vous ne pourrez peut-être pas mettre en œuvre votre architecture sophistiquée dans les délais nécessaires.

Comment savoir quand extraire davantage mon code?

Je ne sais pas où je l'ai lu (si quelqu'un le sait, faites-le-moi savoir et je le remercierai), mais en règle générale, les développeurs devraient compter comme un homme des cavernes: un, deux, beaucoup .

XKCD # 764

En d’autres termes, lorsqu’un certain algorithme / modèle est utilisé pour la troisième fois, il doit être résumé afin qu’il soit réutilisable (= utilisable plusieurs fois).

Juste pour être clair, je ne veux pas dire que vous ne devriez pas écrire de code réutilisable quand il n'y a que deux instances de l'algorithme utilisé. Bien sûr, vous pouvez aussi résumer, mais la règle devrait être que, dans trois cas, vous devez résumer.

Encore une fois, cela tient compte de vos attentes. Si vous savez déjà que vous avez besoin de trois instances ou plus, vous pouvez naturellement résumer immédiatement. Mais si vous devinez seulement que vous souhaiterez peut-être l'implémenter plusieurs fois, l'exactitude de l'implémentation de l'abstraction dépend entièrement de l'exactitude de votre conjecture.
Si vous avez bien deviné, vous avez économisé du temps. Si vous avez mal compris, vous avez perdu une partie de votre temps et de vos efforts et vous avez peut-être compromis votre architecture pour mettre en œuvre quelque chose dont vous n'avez finalement pas besoin.

Si destroyCity(City city)c'est mieux que destroyBaghdad(), c'est takeActionOnCity(Action action, City city)encore mieux? Pourquoi pourquoi pas?

Cela dépend beaucoup de plusieurs choses:

• Existe-t-il plusieurs actions pouvant être entreprises dans n'importe quelle ville?
• Ces actions peuvent-elles être utilisées de manière interchangeable? Parce que si les actions "détruire" et "reconstruire" ont des exécutions complètement différentes, il ne sert à rien de fusionner les deux en une seule takeActionOnCityméthode.

Sachez également que si vous abstenez récursivement ceci, vous allez vous retrouver avec une méthode tellement abstraite qu'il ne s'agit que d'un conteneur dans lequel exécuter une autre méthode, ce qui signifie que vous avez rendu votre méthode non pertinente et dénuée de sens.
Si tout votre takeActionOnCity(Action action, City city)corps de méthode finit par n'être rien de plus que action.TakeOn(city);, vous devriez vous demander si la takeActionOnCityméthode a vraiment un but ou n'est pas simplement une couche supplémentaire qui n'ajoute rien de valeur.

Mais agir sur les villes ne me suffit pas, que diriez-vous takeActionOnGeographicArea(Action action, GeographicalArea GeographicalArea)?

La même question se pose ici:

• Avez-vous un cas d'utilisation pour les régions géographiques?
• L'exécution d'une action sur une ville et une région est-elle la même?
• Des actions peuvent-elles être entreprises dans n’importe quelle région / ville?

Si vous pouvez définitivement répondre «oui» aux trois questions, une abstraction est justifiée.

Entraine toi

Il s’agit de Software Engineering SE, mais l’élaboration de logiciels est beaucoup plus artistique que technique. Il n'y a pas d'algorithme universel à suivre ni de mesure à prendre pour déterminer combien de capacité de réutilisation est suffisante. Comme avec n'importe quoi, plus vous maîtriserez les programmes de conception, plus vous y arriverez. Vous aurez une meilleure idée de ce qui est "suffisant" car vous verrez ce qui ne va pas et ce qui ne va pas quand vous paramétrez trop ou trop peu.

Ce n'est pas très utile maintenant , alors que diriez-vous de certaines lignes directrices?

Revenez à votre question. Il y a beaucoup de "elle pourrait dire" et "je pourrais". Beaucoup d'énoncés théorisant sur un besoin futur. Les humains sont fous de prédire l'avenir. Et vous (probablement) êtes un humain. Le problème fondamental de la conception de logiciels est de tenter de rendre compte d’un avenir que vous ne connaissez pas.

Ligne directrice 1: Vous n'en aurez pas besoin

Sérieusement. Arrête. Plus souvent qu'autrement, ce problème futur imaginé n'apparaît pas - et il n'apparaîtra certainement pas comme vous l'avez imaginé.

Directive 2: Coût / bénéfice

Cool, ce petit programme vous a pris quelques heures pour écrire peut-être? Alors , que si votre femme ne revient et demander ces choses? Dans le pire des cas, vous passez encore quelques heures à lancer un autre programme. Dans ce cas, ce n’est pas beaucoup de temps pour rendre ce programme plus flexible. Et cela ne va pas ajouter grand chose à la vitesse d'exécution ou à l'utilisation de la mémoire. Mais les programmes non-triviaux ont des réponses différentes. Différents scénarios ont des réponses différentes. À un moment donné, les coûts ne valent manifestement pas le bénéfice, même avec des compétences imparfaites en énonciation future.

Directive 3: Concentration sur les constantes

Retournez à la question. Dans votre code d'origine, il y a beaucoup d'ints constants. 2018, 1. Ints constants, chaînes constantes ... Ce sont les choses les plus susceptibles de nécessiter une non-constante . Mieux encore, ils ne prennent que peu de temps à paramétrer (ou au moins à définir comme constantes réelles). Mais il faut également se méfier d'un comportement constant . leSystem.out.printlnpar exemple. Ce type d’hypothèse sur l’utilisation a tendance à changer et à être très coûteuse à corriger. Non seulement cela, mais IO comme cela rend la fonction impure (avec le fuseau horaire aller chercher un peu). Le paramétrage de ce comportement peut rendre la fonction plus pure et aboutir à une flexibilité et une testabilité accrues. Gros avantages pour un coût minimal (surtout si vous créez une surcharge qui utilise System.outpar défaut).

Premièrement: aucun développeur de logiciel soucieux de la sécurité n’écrirait une méthode DestroyCity sans passer un jeton d’autorisation pour quelque raison que ce soit.

Moi aussi, je peux écrire n'importe quoi comme un impératif qui a une sagesse évidente sans que cela soit applicable dans un autre contexte. Pourquoi est-il nécessaire d'autoriser une concaténation de chaînes?

Deuxièmement: Tous les codes exécutés doivent être entièrement spécifiés .

Peu importe que la décision soit codée en dur ou reportée à une autre couche. À un moment donné, il existe un morceau de code dans une langue qui sait à la fois ce qui doit être détruit et comment l’instruire.

Cela pourrait se trouver dans le même fichier d’objet destroyCity(xyz), et dans un fichier de configuration:, destroy {"city": "XYZ"}"ou il pourrait s’agir d’une série de clics et de pressions de touches dans une interface utilisateur.

Troisièmement:

Chérie .. Pouvez-vous imprimer toutes les économies réalisées dans le monde entier pour la lumière du jour pour 2018 sur la console? J'ai besoin de vérifier quelque chose.

est un ensemble très différent d'exigences à:

elle veut passer un formateur de chaînes personnalisé, ... intéressé par certaines périodes de mois, ... [et] intéressé par certaines périodes ...

Maintenant, le second ensemble d’exigences rend évidemment l’outil plus flexible. Il a un public cible plus large et un domaine d'application plus large. Le danger ici est que l'application la plus flexible au monde est en fait un compilateur de code machine. Il s'agit littéralement d'un programme si générique qu'il peut tout construire pour que l'ordinateur devienne ce dont vous avez besoin (dans les limites de son matériel).

En règle générale, les personnes qui ont besoin d'un logiciel ne veulent pas de produits génériques; ils veulent quelque chose de spécifique. En leur donnant plus d’options, vous leur rendez la vie plus compliquée. S'ils voulaient cette complexité, ils utiliseraient plutôt un compilateur, sans vous le demander.

Votre femme demandait des fonctionnalités et sous-spécifiait ses exigences. Dans ce cas, c'était apparemment délibéré, et en général c'est parce qu'ils ne savent pas mieux. Sinon, ils auraient juste utilisé le compilateur eux-mêmes. Le premier problème est que vous n'avez pas demandé plus de détails sur ce qu'elle voulait faire. Voulait-elle gérer cela pendant plusieurs années? Est-ce qu'elle le voulait dans un fichier CSV? Vous n'avez pas su quelles décisions elle voulait prendre, ni ce qu'elle vous demandait de comprendre et de décider pour elle. Une fois que vous avez déterminé quelles décisions doivent être différées, vous pouvez déterminer comment communiquer ces décisions à l'aide de paramètres (et d'autres moyens configurables).

Cela étant dit, la plupart des clients manquent de communication, présument ou ignorent certains détails (décisions.) Qu’ils aimeraient vraiment prendre eux-mêmes ou qu’ils ne voulaient vraiment pas prendre (mais cela semble génial). C'est pourquoi les méthodes de travail telles que PDSA (plan-develop-study-study-act) sont importantes. Vous avez planifié le travail conformément aux exigences, puis vous avez développé un ensemble de décisions (code). Il est maintenant temps de l'étudier, seul ou avec votre client, et d'apprendre de nouvelles choses, qui éclairent votre réflexion. Enfin, agissez en fonction de vos nouvelles connaissances - mettez à jour les exigences, affinez le processus, obtenez de nouveaux outils, etc. Ensuite, recommencez la planification. Cela aurait révélé toutes les exigences cachées au fil du temps et prouverait les progrès réalisés à de nombreux clients.

Finalement. Votre temps est important ; c'est très réel et très fini. Chaque décision que vous prenez implique de nombreuses autres décisions cachées, et c’est en cela que consiste le développement de logiciels. Retarder une décision sous forme d'argument peut simplifier la fonction actuelle, mais rend quelque part plus complexe. Cette décision est-elle pertinente dans cet autre endroit? Est-ce plus pertinent ici? À qui appartient cette décision? Vous décidez ceci; c'est du codage. Si vous répétez fréquemment des ensembles de décisions, il serait très avantageux de les codifier dans une abstraction. XKCD a une perspective utile ici. Et ceci est pertinent au niveau d’un système, qu’il s’agisse d’une fonction, d’un module, d’un programme, etc.

Les conseils donnés au départ impliquent que les décisions que votre fonction n'a pas le droit de prendre doivent être transmises en tant qu'argument. Le problème est qu’une DestroyBaghdadfonction peut en fait être celle qui a ce droit.

Il y a beaucoup de réponses fastidieuses ici, mais honnêtement, je pense que c'est super simple

Toute information codée en dur que vous avez dans votre fonction et qui ne fait pas partie du nom de la fonction doit être un paramètre.

donc dans votre fonction

class App {
    void dayLightSavings() {
        final Set<String> availableZoneIds = ZoneId.getAvailableZoneIds();
        availableZoneIds.forEach(zoneId -> {
            LocalDateTime dateTime = LocalDateTime.of(LocalDate.of(2018, 1, 1), LocalTime.of(0, 0, 0));
            ZonedDateTime now = ZonedDateTime.of(dateTime, ZoneId.of(zoneId));
            while (2018 == now.getYear()) {
                int hour = now.getHour();
                now = now.plusHours(1);
                if (now.getHour() == hour) {
                    System.out.println(now);
                }
            }
        });
    }
}

Tu as:

The zoneIds
2018, 1, 1
System.out

Je déplacerais donc tous ces paramètres vers des paramètres sous une forme ou une autre. Vous pouvez faire valoir que les zonesId sont implicites dans le nom de la fonction. Peut-être voudriez-vous le rendre encore plus en le changeant en "DaylightSavingsAroundTheWorld" ou quelque chose du genre

Vous n'avez pas de chaîne de format; par conséquent, en ajouter une est une demande de fonctionnalité et vous devriez référer votre femme à l'instance de votre famille Jira. Il peut être mis sur l'arriéré et hiérarchisé lors de la réunion du comité de gestion de projet appropriée.

En bref, ne concevez pas votre logiciel pour qu'il soit réutilisable, car aucun utilisateur final ne se soucie de savoir si vos fonctions peuvent être réutilisées. À la place, ingénieur pour la compréhensibilité de la conception - mon code est-il facile à comprendre pour quelqu'un d'autre ou mon futur moi oublieux à comprendre? - et flexibilité de conception- lorsque je dois inévitablement corriger des bogues, ajouter des fonctionnalités ou modifier d'autres fonctionnalités, dans quelle mesure mon code résistera-t-il aux modifications? La seule chose qui compte pour votre client est la rapidité avec laquelle vous pouvez répondre quand elle signale un bogue ou demande un changement. Le fait de poser ces questions sur votre conception a tendance à générer un code réutilisable, mais cette approche vous permet d'éviter les véritables problèmes que vous rencontrerez tout au long de la vie de ce code afin de pouvoir mieux servir l'utilisateur final plutôt que de rechercher des solutions fastidieuses et peu pratiques. "ingénierie" idéaux pour plaire à la barbe.

Pour quelque chose d'aussi simple que l'exemple que vous avez fourni, votre implémentation initiale est bonne à cause de sa petite taille, mais cette conception simple deviendra difficile à comprendre et fragile si vous essayez d'incorporer trop de flexibilité fonctionnelle (par opposition à une flexibilité de conception) dans une procédure. Vous trouverez ci-dessous une explication de l’approche que je privilégie pour la conception de systèmes complexes aux fins de la compréhensibilité et de la flexibilité, ce qui, j’espère, démontrera ce que j’entends par eux. Je n’utiliserais pas cette stratégie pour quelque chose qui pourrait être écrit en moins de 20 lignes en une seule procédure car quelque chose de si petit répond déjà à mes critères de compréhensibilité et de flexibilité.

Des objets, pas des procédures

Plutôt que d'utiliser des classes telles que des modules de la vieille école avec un ensemble de routines que vous appelez pour exécuter les tâches que votre logiciel doit faire, envisagez de modéliser le domaine en tant qu'objets qui interagissent et coopèrent pour accomplir la tâche à accomplir. Les méthodes d'un paradigme orienté objet ont été créées à l'origine pour être des signaux entre objets afin que Object1chacun Object2puisse faire son travail, quel qu'il soit, et éventuellement recevoir un signal de retour. En effet, le paradigme orienté objet concerne intrinsèquement la modélisation des objets de votre domaine et de leurs interactions plutôt qu'un moyen sophistiqué d’organiser les mêmes fonctions et procédures anciennes du paradigme Imperative. Dans le cas duvoid destroyBaghdadPar exemple, au lieu d’essayer d’écrire une méthode générique sans contexte pour gérer la destruction de Bagdad ou de toute autre chose (qui pourrait devenir rapidement complexe, difficile à comprendre et cassante), tout ce qui peut être détruit devrait permettre de comprendre comment se détruire. Par exemple, vous avez une interface qui décrit le comportement de choses pouvant être détruites:

interface Destroyable {
    void destroy();
}

Ensuite, vous avez une ville qui implémente cette interface:

class City implements Destroyable {
    @Override
    public void destroy() {
        ...code that destroys the city
    }
}

Rien qui appelle à la destruction d'une instance de Cityne sera jamais soin comment cela se passe, donc il n'y a aucune raison pour que le code d'exister partout en dehors de City::destroy, et en effet, la connaissance intime des rouages de l' Cityextérieur de lui - même serait un couplage étroit qui réduit félicité puisque vous devez tenir compte de ces éléments extérieurs au cas où vous auriez besoin de modifier le comportement de City. C'est le but véritable de l'encapsulation. Pensez-y comme si chaque objet avait sa propre API, ce qui devrait vous permettre de faire tout ce dont vous avez besoin pour pouvoir le laisser vous soucier de répondre à vos demandes.

Délégation, pas "contrôle"

Maintenant, que votre classe d'implémentation Citysoit Baghdaddépendante ou non du degré de générique du processus de destruction de la ville. Selon toute probabilité, un Citysera composé de plus petites pièces qui devront être détruites individuellement pour accomplir la destruction totale de la ville. Ainsi, dans ce cas, chacune de ces pièces serait également mise en œuvre Destroyableet chacune d'elles aurait pour instruction Cityde détruire de la même manière que quelqu'un de l'extérieur a demandé Cityà se détruire.

interface Part extends Destroyable {
    ...part-specific methods
}

class Building implements Part {
    ...part-specific methods
    @Override
    public void destroy() {
       ...code to destroy a building
    }
}

class Street implements Part {
    ...part-specific methods
    @Override
    public void destroy() {
        ...code to destroy a building
    }
}

class City implements Destroyable {
    public List<Part> parts() {...}

    @Override
    public void destroy() {
        parts().forEach(Destroyable::destroy);            
    }
}

Si vous voulez devenir vraiment fou et mettre en œuvre l'idée d'un objet Bombdéposé sur un emplacement et détruisant tout dans un rayon donné, cela pourrait ressembler à ceci:

class Bomb {
    private final Integer radius;

    public Bomb(final Integer radius) {
        this.radius = radius;
    }

    public void drop(final Grid grid, final Coordinate target) {
        new ObjectsByRadius(
            grid,
            target,
            this.radius
        ).forEach(Destroyable::destroy);
    }
}

ObjectsByRadiusreprésente un ensemble d'objets qui est calculé pour les Bombentrées depuis, car la Bombmanière dont ce calcul est effectué ne se soucie pas tant qu'il peut fonctionner avec les objets. Ceci est d'ailleurs réutilisable, mais l'objectif principal est d'isoler le calcul des processus de suppression Bombet de destruction des objets afin que vous puissiez comprendre chaque élément et son agencement et modifier le comportement d'un élément individuel sans avoir à remodeler l'ensemble de l'algorithme. .

Des interactions, pas des algorithmes

Plutôt que d'essayer de deviner le bon nombre de paramètres pour un algorithme complexe, il est plus judicieux de modéliser le processus en tant qu'ensemble d'objets en interaction, chacun avec des rôles extrêmement étroits, car il vous permettra de modéliser la complexité de votre processus à travers les interactions entre ces objets bien définis, faciles à comprendre et presque immuables. Lorsque cela est fait correctement, cela rend même certaines des modifications les plus complexes aussi triviales que l'implémentation d'une interface ou deux et la modification des objets instanciés dans votre main()méthode.

Je donnerais quelque chose à votre exemple initial, mais honnêtement, je ne peux pas comprendre ce que signifie "imprimer ... Day Light Savings". Ce que je peux dire à propos de cette catégorie de problème, c'est que chaque fois que vous effectuez un calcul, le résultat de celui-ci peut être formaté de différentes manières, la méthode que je préfère pour décomposer cela est la suivante:

interface Result {
    String print();
}

class Caclulation {
    private final Parameter paramater1;

    private final Parameter parameter2;

    public Calculation(final Parameter parameter1, final Parameter parameter2) {
        this.parameter1 = parameter1;
        this.parameter2 = parameter2;
    }

    public Result calculate() {
        ...calculate the result
    }
}

class FormattedResult {
    private final Result result;

    public FormattedResult(final Result result) {
        this.result = result;
    }

    @Override
    public String print() {
        ...interact with this.result to format it and return the formatted String
    }
}

Étant donné que votre exemple utilise des classes de la bibliothèque Java qui ne prennent pas en charge cette conception, vous pouvez simplement utiliser l'API ZonedDateTimedirectement. L'idée ici est que chaque calcul est encapsulé dans son propre objet. Il ne fait aucune hypothèse sur le nombre de fois qu'il devrait être exécuté ou comment il devrait formater le résultat. Il s’agit exclusivement de réaliser la forme la plus simple du calcul. Cela rend le changement facile à comprendre et flexible. De même, le Resultest exclusivement concerné par l’encapsulation du résultat du calcul, et le FormattedResultexclusivement sur l’interaction avec le Resultpour le formater selon les règles que nous définissons. De cette façon,nous pouvons trouver le nombre parfait d'arguments pour chacune de nos méthodes, car elles ont chacune une tâche bien définie . Il est également beaucoup plus simple de modifier l’avenir tant que les interfaces ne changent pas (ce qui est moins le cas si vous avez correctement minimisé les responsabilités de vos objets). Notremain()méthode pourrait ressembler à ceci:

class App {
    public static void main(String[] args) {
        final List<Set<Paramater>> parameters = ...instantiated from args
        parameters.forEach(set -> {
            System.out.println(
                new FormattedResult(
                    new Calculation(
                        set.get(0),
                        set.get(1)
                    ).calculate()
                ).print()
            );
        });
    }
}

En fait, la programmation orientée objet a été spécialement inventée pour résoudre le problème de complexité / flexibilité du paradigme de l’impératif, car il n’ya pas de bonne réponse (que tout le monde peut s’entendre ou arriver à un accord de façon indépendante) sur la manière optimale de fonctionner. spécifier les fonctions et les procédures impératives dans l'idiome.

Expérience , connaissance du domaine et revues de code.

Et, quels que soient votre niveau d' expérience , votre connaissance du domaine ou votre équipe , vous ne pouvez éviter le besoin de refactoriser au besoin.

Avec Experience , vous allez commencer à reconnaître les modèles dans les méthodes (et les classes) non spécifiques à un domaine que vous écrivez. Et, si vous êtes intéressé par le code DRY, vous éprouverez de la tristesse lorsque vous écrivez une méthode dont vous savez instinctivement que vous allez écrire des variations dans le futur. Ainsi, vous écrirez intuitivement à la place un plus petit dénominateur commun paramétré.

_{(Cette expérience peut également être instinctive dans certains objets et méthodes de votre domaine.)}

Avec la connaissance du domaine , vous aurez une idée des concepts d’entreprise étroitement liés, des concepts qui ont des variables, qui sont relativement statiques, etc.

Avec les revues de code, la sous-paramétrisation et la sur-paramétrisation seront plus facilement détectées avant de devenir un code de production, car vos pairs auront (espérons-le) des expériences et des perspectives uniques, à la fois sur le domaine et sur le codage.

Cela dit, les nouveaux développeurs n'auront généralement pas ces Spidey Senses ou un groupe de pairs expérimentés sur lesquels s'appuyer tout de suite. Et même les développeurs expérimentés bénéficient d'une discipline de base leur permettant de se familiariser avec les nouvelles exigences - ou avec les journées brumeuses. Alors, voici ce que je suggérerais pour commencer :

• Commencez par la mise en œuvre naïve, avec une paramétrisation minimale.
  _{(Incluez évidemment tous les paramètres dont vous savez déjà qu'ils auront besoin ...)}
• Supprimez les nombres et les chaînes magiques, en les déplaçant vers des configurations et / ou des paramètres
• Factorisez les "grandes" méthodes en méthodes plus petites et bien nommées
• Refactoriser les méthodes hautement redondantes (si cela convient) en un dénominateur commun, en paramétrant les différences.

Ces étapes ne se produisent pas nécessairement dans l'ordre indiqué. Si vous vous assoyez pour écrire une méthode que vous savez déjà hautement redondante avec une méthode existante , passez directement au refactoring si cela vous convient. (Si cela ne prend pas beaucoup plus de temps à refactoriser qu'à écrire, tester et maintenir deux méthodes.)

Mais, en plus d’avoir beaucoup d’expérience et ainsi de suite, je conseille un code assez minimaliste DRY-ing. Il n’est pas difficile de repenser les violations évidentes. Et si vous êtes trop zélé , vous pouvez vous retrouver avec un code "trop ​​sec" qui est encore plus difficile à lire, à comprendre et à maintenir que son équivalent "WET".

Même réponse que pour la qualité, la convivialité, la dette technique, etc.:

Comme réutilisable vous, l'utilisateur, ¹ ont besoin d'être

Il s’agit essentiellement de faire preuve de discernement - si le coût de la conception et de la maintenance de l’abstraction sera remboursé (= temps et efforts), cela vous fera économiser en bout de ligne.

• Notez la phrase "en bas de la ligne": il existe un mécanisme de paiement ici, donc cela dépendra de la quantité de travail que vous ferez avec ce code. Par exemple:
  • S'agit-il d'un projet ponctuel ou va-t-il être amélioré progressivement sur une longue période?
  • Êtes-vous confiant dans votre conception ou devrez-vous probablement la supprimer ou la modifier radicalement pour le prochain projet / jalon (par exemple, essayer un autre cadre)?
• L'avantage prévu dépend également de votre capacité à prédire l'avenir (modifications apportées à l'application). Parfois, vous pouvez raisonnablement voir le (s) lieu (x) de votre application. Plus de fois, vous pensez que vous pouvez, mais vous ne pouvez pas. Les règles de base sont le principe de YAGNI et la règle de trois - les deux insistent sur le fait de travailler à partir de ce que vous savez, maintenant.

¹ _{Ceci est une construction de code, vous êtes donc "l'utilisateur" dans ce cas - l'utilisateur du code source}

Vous pouvez suivre un processus clair:

• Ecrivez un test d'échec pour une seule fonctionnalité qui est en soi une "chose" (c'est-à-dire, pas une division arbitraire d'une fonctionnalité où aucune des deux n'a de sens).
• Écrivez le code minimum absolu pour le rendre vert, pas une ligne de plus.
• Rincer et répéter.
• (Refacturez implacablement si nécessaire, ce qui devrait être facile en raison de la grande couverture de test.)

Au moins, de l'avis de certaines personnes, cela donne un code plutôt optimal, puisqu'il est aussi petit que possible, chaque fonction finie prend le moins de temps possible (ce qui peut être vrai ou non si vous regardez le produit fini. produit après refactoring), et sa couverture de test est très bonne. Cela évite aussi sensiblement les méthodes ou les classes trop génériques trop sophistiquées.

Cela vous donne également des instructions très claires quand il faut faire des choses génériques et quand se spécialiser.

Je trouve votre exemple de ville bizarre. Je serais très probablement jamais jamais hardcode un nom de ville. Il est tellement évident que d’autres villes seront incluses plus tard, quoi que vous fassiez. Mais un autre exemple serait les couleurs. Dans certaines circonstances, le codage en dur "rouge" ou "vert" serait une possibilité. Par exemple, les feux de signalisation sont une couleur si omniprésente que vous pouvez simplement vous en sortir (et vous pouvez toujours les refactoriser). La différence est que "rouge" et "vert" ont une signification universelle, "codée en dur" dans notre monde, il est incroyablement improbable que cela change jamais et il n'y a pas vraiment d'alternative non plus.

Votre méthode de première heure avancée est tout simplement cassée. Bien que conforme au cahier des charges, le code 2018 codé en dur est particulièrement mauvais, car a) il n'est pas mentionné dans le "contrat" ​​technique (dans le nom de la méthode, dans ce cas), et b) il sera bientôt obsolète, est inclus dès le départ. Pour les choses qui sont liées à l’heure / la date, il serait très rarement logique de coder en dur une valeur spécifique car, eh bien, le temps passe. Mais à part cela, tout le reste est en discussion. Si vous donnez une année simple et calculez toujours l'année complète, continuez. La plupart des choses que vous avez énumérées (formatage, choix d'une plage plus petite, etc.) indiquent que votre méthode en fait trop et qu'elle devrait plutôt renvoyer une liste / un tableau de valeurs afin que l'appelant puisse se formater / filtrer lui-même.

Mais au bout du compte, il s’agit essentiellement d’opinion, de goût, d’expérience et de préjugés personnels. Ne vous inquiétez donc pas.

Je suis venu à l'opinion qu'il existe deux sortes de code réutilisable:

• Code qui est réutilisable parce que c'est une chose fondamentale et fondamentale.
• Code qui est réutilisable car il a des paramètres, des remplacements et des crochets pour partout.

Le premier type de réutilisabilité est souvent une bonne idée. Cela s'applique à des choses comme des listes, des hashmaps, des magasins de clés / valeurs, des correspondeurs de chaînes (regex, glob, ...), des tuples, unification, des arbres de recherche (profondeur d'abord, largeur d'abord, approfondissement itératif, ...) , combinateurs d’analyseurs, caches / memoisers, lecteurs / graveurs de format de données (expressions-s, XML, JSON, protobuf, ...), files de tâches, etc.

Ces choses sont tellement générales, d’une manière très abstraite, qu’elles sont réutilisées partout dans la programmation quotidienne. Si vous vous trouvez en train d'écrire un code à usage spécifique, ce qui serait plus simple s'il était plus abstrait / général (par exemple, si nous avons "une liste de commandes de clients", nous pourrions jeter la "commande de client" pour obtenir "une liste" ) alors ce pourrait être une bonne idée de le retirer. Même s'il n'est pas réutilisé, il nous permet de découpler les fonctionnalités non liées.

Le deuxième type est celui où nous avons un code concret, qui résout un problème réel, mais le fait en prenant toute une série de décisions. Nous pouvons le rendre plus général / réutilisable en "codant de manière souple" ces décisions, par exemple en les transformant en paramètres, en compliquant la mise en œuvre et en cuisant des détails encore plus concrets (c.-à-d. Savoir quels crochets nous pourrions souhaiter pour des dérogations). Votre exemple semble être de cette sorte. Le problème avec ce type de réutilisabilité est que nous pouvons finir par essayer de deviner les cas d'utilisation d'autres personnes, ou notre avenir. Nous pourrions finir par avoir tellement de paramètres que notre code n'est pas utilisable, encore moins réutilisable! En d’autres termes, lorsqu’il appelle, cela demande plus d’efforts que d’écrire sa propre version. C'est là que YAGNI (vous n'en aurez pas besoin) est important. Souvent, de telles tentatives de code "réutilisable" finissent par ne pas être réutilisées, car elles peuvent être incompatibles avec ces cas d'utilisation plus fondamentalement que ne peuvent en tenir les paramètres, ou ces utilisateurs potentiels préfèrent lancer leurs propres (heck, regardez tous les normes et bibliothèques dont les auteurs préfixés par le mot "Simple", pour les distinguer des prédécesseurs!).

Cette deuxième forme de "réutilisabilité" devrait essentiellement être effectuée selon les besoins. Bien sûr, vous pouvez y insérer des paramètres "évidents", mais n'essayez pas de prédire l'avenir. YAGNI.

Il existe déjà de nombreuses réponses excellentes et élaborées. Certaines d’entre elles vont profondément dans les détails, exposent certains points de vue sur les méthodologies de développement de logiciels en général, et certaines d’entre elles ont certainement des éléments controversés ou des "opinions" parsemées.

La réponse de Warbo a déjà souligné différents types de réutilisabilité. À savoir, si quelque chose est réutilisable parce que c'est un élément fondamental, ou si quelque chose est réutilisable parce que c'est "générique" d'une certaine manière. En référence à ce dernier point, il y a quelque chose que je considérerais comme une sorte de mesure de réutilisation:

Si une méthode peut en imiter une autre.

En ce qui concerne l’exemple tiré de la question: imaginons que la méthode

void dayLightSavings()

était la mise en œuvre d'une fonctionnalité demandée par un client. Ce sera donc quelque chose que d' autres programmeurs sont supposés utiliser , et donc être une méthode publique , comme dans

publicvoid dayLightSavings()

Cela pourrait être mis en œuvre comme vous l'avez montré dans votre réponse. Maintenant, quelqu'un veut le paramétrer avec l'année. Vous pouvez donc ajouter une méthode

publicvoid dayLightSavings(int year)

et changer l'implémentation d'origine juste

public void dayLightSavings() {
    dayLightSavings(2018);
}

Les prochaines "demandes de fonctionnalités" et les généralisations suivent le même schéma. Donc, si et seulement s'il existe une demande pour la forme la plus générique, vous pouvez l'implémenter, sachant que cette forme la plus générique permet des implémentations triviales de celles plus spécifiques:

public void dayLightSavings() {
    dayLightSavings(2018, 0, 12, 0, 12, new DateTimeFormatter(...));
}

Si vous aviez prévu des extensions et des demandes de fonctionnalités futures, et si vous aviez du temps à votre disposition et que vous vouliez passer un week-end ennuyeux avec des généralisations (potentiellement inutiles), vous auriez pu commencer par la plus générique dès le début. Mais seulement comme une méthode privée . Tant que vous exposez uniquement la méthode simple demandée par le client en tant que méthode publique , vous êtes en sécurité.

tl; dr :

En réalité, la question n'est pas tant de savoir "à quel point une méthode doit être réutilisable". La question est de savoir combien de cette réutilisabilité est exposée et à quoi ressemble l'API. Créer une API fiable et capable de résister à l'épreuve du temps (même si d'autres exigences se présentent ultérieurement) est un art et un métier, et le sujet est beaucoup trop complexe pour être couvert ici. Jetez un œil à cette présentation de Joshua Bloch ou au wiki du livre de conception d'API pour commencer.

En règle générale, votre méthode doit être aussi réutilisable que… réutilisable.

Si vous prévoyez d'appeler votre méthode à un seul endroit, il ne doit contenir que des paramètres connus du site d'appels et non disponibles pour cette méthode.

Si vous avez plus d’appelants, vous pouvez introduire de nouveaux paramètres à condition que d’autres appelants puissent les transmettre; sinon vous avez besoin d'une nouvelle méthode.

Comme le nombre d’appelants peut augmenter avec le temps, vous devez être prêt à refactoriser ou à surcharger. Dans de nombreux cas, cela signifie que vous devez vous sentir en sécurité pour sélectionner une expression et exécuter l'action “extraire le paramètre” de votre IDE.

Réponse ultra-courte: Moins le couplage ou la dépendance à un autre code de votre module générique est important, plus il peut être réutilisé.

Votre exemple ne dépend que de

import java.time.*;
import java.util.Set;

donc, en théorie, il peut être très réutilisable.

En pratique, je ne pense pas que vous ayez jamais un deuxième dossier utilisateur qui a besoin de ce code, donc, suivant le principe de yagni , je ne le rendrais pas réutilisable s’il n’ya pas plus de 3 projets différents qui ont besoin de ce code.

Les autres aspects de la réutilisation sont la facilité d’utilisation et la documentation qui sont liées au développement piloté par les tests : il est utile de disposer d’un test unitaire simple qui démontre / documente une utilisation facile de votre module générique comme exemple de codage pour les utilisateurs de votre bibliothèque.

C’est une bonne occasion d’énoncer une règle que j’ai inventée récemment:

Être un bon programmeur, c'est être capable de prédire l'avenir.

Bien sûr, c'est strictement impossible! Après tout, vous ne savez jamais avec certitude quelles sont les généralisations que vous jugerez utiles par la suite, les tâches connexes que vous voudrez effectuer, les nouvelles fonctionnalités que vos utilisateurs voudront, etc. Mais l'expérience vous donne parfois une idée approximative de ce qui pourrait vous être utile.

Les autres facteurs à prendre en compte sont le temps et les efforts supplémentaires nécessaires et la complexité de votre code. Parfois, vous avez de la chance, et résoudre le problème plus général est en réalité plus simple! (Du moins sur le plan conceptuel, sinon en termes de quantité de code.) Mais le plus souvent, il existe un coût de complexité, de temps et d’efforts.

Donc, si vous pensez qu'une généralisation sera très probablement nécessaire, cela en vaut souvent la peine (sauf si cela ajoute beaucoup de travail ou de complexité); mais si cela semble beaucoup moins probable, alors ce n'est probablement pas le cas (à moins que ce soit très facile et / ou simplifie le code).

(Pour un exemple récent: la semaine dernière, on m'a donné une spécification pour les actions qu'un système devrait prendre exactement 2 jours après l'expiration de quelque chose. Alors bien sûr, j'ai fait de la période de 2 jours un paramètre. Cette semaine, les gens d'affaires étaient ravis, car J'avais de la chance: c'était un changement facile, et je devinais qu'il était fort probable qu'il fût désirable. C'est souvent plus difficile à juger. Mais cela vaut toujours la peine d'essayer de prédire, et l'expérience est souvent un bon guide .)

Tout d’abord, la meilleure réponse à la question «Comment savoir si mes méthodes doivent être réutilisables?» Est «Expérience». Faites-le plusieurs milliers de fois, et vous obtiendrez généralement la bonne réponse. Mais, en guise de teaser, je peux vous donner le dernier ligne de cette réponse: votre client vous dira combien de flexibilité et combien de couches de généralisation vous devriez rechercher.

Beaucoup de ces réponses ont des conseils spécifiques. Je voulais donner quelque chose de plus générique ... parce que l'ironie est trop amusante pour la laisser passer!

Comme certaines des réponses l'ont noté, la généralité coûte cher. Cependant, ce n'est vraiment pas. Pas toujours. Comprendre la dépense est essentiel pour jouer au jeu de la réutilisabilité.

Je me concentre sur l’établissement d’une échelle allant de "irréversible" à "réversible". C'est une échelle lisse. La seule chose véritablement irréversible est le "temps passé sur le projet". Vous ne récupérerez jamais ces ressources. Les situations de «menottes dorées» telles que l’API Windows sont un peu moins réversibles. Les fonctionnalités obsolètes sont conservées dans cette API pendant des décennies, car le modèle économique de Microsoft en fait la demande. Si vous avez des clients dont la relation serait définitivement endommagée en annulant certaines fonctionnalités de l'API, cela devrait alors être considéré comme irréversible. À l'autre bout de l'échelle, vous avez des choses comme le code prototype. Si vous n'aimez pas où cela va, vous pouvez simplement le jeter. Les API à usage interne pourraient être légèrement moins réversibles. Ils peuvent être refactorisés sans déranger un client,le temps (la ressource la plus irréversible de tous!)

Alors mettez-les sur une échelle. Vous pouvez maintenant appliquer une heuristique: plus une chose est réversible, plus vous pouvez l’utiliser pour des activités futures. Si quelque chose est irréversible, utilisez-le uniquement pour des tâches concrètes orientées client. C'est pourquoi vous voyez des principes comme ceux de la programmation extrême qui suggèrent de ne faire que ce que le client demande et rien de plus. Ces principes permettent de s’assurer que vous ne faites pas ce que vous regrettez.

Des choses comme le principe DRY suggèrent un moyen de faire évoluer cet équilibre. Si vous vous répétez, c'est l'occasion de créer ce qui est fondamentalement une API interne. Aucun client ne le voit, vous pouvez donc toujours le changer. Une fois que vous avez cette API interne, vous pouvez maintenant commencer à jouer avec des choses tournées vers l'avenir. Combien de tâches différentes basées sur les fuseaux horaires pensez-vous que votre femme va vous confier? Avez-vous d'autres clients qui souhaiteraient des tâches basées sur un fuseau horaire? Votre flexibilité ici est achetée par les demandes concrètes de vos clients actuels et répond aux futures demandes potentielles de futurs clients.

Cette approche de pensée en couches, qui provient naturellement de DRY, fournit naturellement la généralisation que vous souhaitez sans gaspillage. Mais y a-t-il une limite? Bien sûr il y a. Mais pour le voir, il faut voir la forêt pour les arbres.

Si vous avez plusieurs couches de flexibilité, elles conduisent souvent à un manque de contrôle direct des couches auxquelles vos clients sont confrontés. J'ai eu un logiciel dans lequel j'ai eu la tâche brutale d'expliquer à un client pourquoi il ne pouvait pas obtenir ce qu'il souhaitait en raison de sa flexibilité construite en 10 couches, ce qu'il n'était jamais supposé voir. Nous nous sommes inscrits dans un coin. Nous nous sommes noués avec toute la flexibilité dont nous pensions avoir besoin.

Ainsi, lorsque vous effectuez cette opération de généralisation / DRY, veillez toujours à ce que votre client soit au courant . Que pensez-vous que votre femme va demander ensuite? Vous mettez-vous en mesure de répondre à ces besoins? Si vous avez le talent, le client vous dira efficacement ses besoins futurs. Si vous n'avez pas le talent, la plupart d'entre nous ne nous fions qu'à des conjectures! (surtout avec les conjoints!) Certains clients voudront une grande flexibilité et seront disposés à accepter le coût supplémentaire que représente le développement de toutes ces couches, car ils bénéficient directement de la flexibilité de ces couches. D'autres clients ont plutôt des exigences fixes fixes et préfèrent un développement plus direct. Votre client vous indiquera le degré de flexibilité et le nombre de couches de généralisation à rechercher.

aucun ingénieur logiciel formé sur le plan éthique ne consentirait jamais à écrire une procédure DestroyBaghdad. Une éthique professionnelle de base l'obligerait plutôt à écrire une procédure DestroyCity, à laquelle Bagdad pourrait être paramétré.

C'est ce que les cercles du génie logiciel avancés appellent une "blague". Les blagues ne doivent pas forcément être ce que nous appelons «vraies», bien que pour être drôles, elles doivent généralement faire allusion à quelque chose de vrai.

Dans ce cas particulier, la "blague" n'est pas "vraie". La tâche qui consiste à rédiger une procédure générale pour détruire une ville est, nous pouvons le supposer, des ordres de grandeur allant au-delà de ce qui est nécessaire pour détruire un site spécifique.ville. Autrement, quiconque a détruit une ou plusieurs villes (le Josué biblique, dirons-nous, ou le président Truman) pourrait trivialement généraliser ce qu’il a fait et pouvoir détruire absolument n’importe quelle ville à sa guise. Ce n'est en fait pas le cas. Les méthodes que ces deux personnes ont l'habitude d'utiliser pour détruire un petit nombre de villes spécifiques ne fonctionneraient pas nécessairement sur n'importe quelle ville à aucun moment. Une autre ville dont les murs ont une fréquence de résonance différente ou dont les défenses aériennes à haute altitude sont plutôt meilleures nécessiterait des modifications d'approche mineures ou fondamentales (une trompette ou une roquette à la hauteur différente).

Cela conduit également à la maintenance du code contre les changements dans le temps: il y a plutôt beaucoup de villes qui ne tomberaient sous aucune de ces approches, grâce aux méthodes de construction modernes et au radar omniprésent.

Développer et tester un moyen tout à fait général qui détruira n'importe quelle ville, avant d'accepter de détruire une seule ville, est une approche désespérément inefficace. Aucun ingénieur logiciel formé sur le plan éthique n'essaierait de généraliser un problème nécessitant beaucoup plus de travail que ce que leur employeur / client doit réellement payer, sans obligation manifeste.

Alors qu'est-ce qui est vrai? Parfois, ajouter de la généralité est trivial. Devrions-nous alors toujours ajouter de la généralité quand il est trivial de le faire? Je dirais toujours "non, pas toujours", à cause du problème de la maintenance à long terme. En supposant qu'au moment de la rédaction, toutes les villes sont fondamentalement les mêmes, je vais donc de l'avant avec DestroyCity. Une fois que j’ai écrit cela, ainsi que des tests d’intégration qui (en raison de l’espace infiniment énumérable d’entrées) parcourent toutes les villes connues et s’assurent que la fonction fonctionne sur chaque détruit le clone?

En pratique, cette fonction sert uniquement à détruire Bagdad. Supposons que quelqu'un construise une nouvelle ville résistante à mes techniques (elle est souterraine ou quelque chose du genre). Maintenant, j'ai un échec de test d'intégration pour un cas d'utilisation qui n'existe même pas vraiment , et avant de pouvoir poursuivre ma campagne de terreur contre les civils innocents d'Irak, je dois trouver un moyen de détruire Subterrania. Peu importe que ce soit éthique ou non, c'est idiot et une perte de temps .

Alors, est-ce que vous voulez vraiment une fonction capable de produire une heure avancée pour n’importe quelle année, uniquement pour produire des données pour 2018? Peut-être, mais il va certainement falloir déployer des efforts supplémentaires pour mettre en place des scénarios de test. Il faudra peut-être beaucoup d'efforts pour obtenir une meilleure base de données de fuseaux horaires que celle que vous avez réellement. Ainsi, par exemple, en 1908, la ville de Port Arthur, en Ontario, commençait la période d’été à compter du 1er juillet. Est-ce dans la base de données du fuseau horaire de votre système d'exploitation? Je ne pensais pas, alors votre fonction généralisée est fausse . Il n’ya rien d’éthique dans l’écriture de code qui fait des promesses qu’il ne peut pas tenir.

Très bien, donc, avec les mises en garde appropriées, il est facile d’écrire une fonction qui gère les fuseaux horaires pendant plusieurs années, par exemple de 1970 à nos jours. Mais il est tout aussi facile de prendre la fonction que vous avez écrite et de la généraliser pour paramétrer l'année. Donc, il n’est pas vraiment plus éthique / raisonnable de généraliser maintenant, c’est de faire ce que vous avez fait et ensuite de généraliser si et quand vous en avez besoin.

Toutefois, si vous saviez pourquoi votre femme souhaitait consulter cette liste d'heures d'été, vous auriez alors une opinion éclairée sur le point de savoir si elle est susceptible de poser la même question à nouveau en 2019 et, le cas échéant, si vous pouvez vous sortir de cette boucle en donnant elle est une fonction qu’elle peut appeler, sans avoir besoin de la recompiler. Une fois que vous avez fait cette analyse, la réponse à la question "devrait-elle généraliser aux dernières années" pourrait être "oui". Mais vous vous créez encore un autre problème: les données de fuseau horaire dans le futur ne sont que provisoires. Par conséquent, si elle les gère pour 2019 aujourd'hui, elle peut ou non se rendre compte que cela la nourrit de son mieux. Il vous reste donc encore à rédiger une documentation qui ne serait pas nécessaire pour la fonction moins générale ("les données proviennent de la base de données de fuseaux horaires blah blah, voici le lien pour voir leurs politiques en matière de mise à jour blah blah"). Si vous refusez le cas particulier, elle ne peut pas continuer à travailler pour le compte pour lequel elle avait besoin des données de 2018, à cause d'un non-sens à propos de 2019 dont elle ne se soucie même pas encore.

Ne faites pas de tâches difficiles sans y avoir bien réfléchi, simplement parce qu'une blague vous a dit de le faire. Est-ce utile? Est-ce assez bon marché pour ce degré d'utilité?

C'est une ligne facile à tracer, car la réutilisation telle que définie par l'architecture des astronautes est complexe.

Presque tout le code créé par les développeurs d'applications est extrêmement spécifique à un domaine. Ce n'est pas 1980. Presque tout ce qui vaut la peine est déjà dans un cadre.

Les abstractions et les conventions exigent de la documentation et des efforts d'apprentissage. Veuillez cesser d'en créer de nouveaux juste pour le plaisir de le faire. (Je regarde vous , les gens JavaScript!)

Adonnons le fantasme invraisemblable selon lequel vous avez trouvé quelque chose qui devrait véritablement figurer dans votre cadre de choix. Vous ne pouvez pas simplement taper le code comme vous le faites habituellement. Oh non, vous avez besoin d'une couverture de test non seulement pour l'utilisation prévue, mais aussi pour les écarts par rapport à l'utilisation prévue, pour tous les cas critiques connus, pour tous les modes de défaillance imaginables, cas de test pour diagnostics, données de test, documentation technique, documentation utilisateur, gestion des versions, support scripts, tests de régression, gestion du changement ...

Votre employeur est-il content de payer pour tout cela? Je vais dire non.

L'abstraction est le prix que nous payons pour la flexibilité. Cela rend notre code plus complexe et plus difficile à comprendre. À moins que la flexibilité ne serve un besoin réel et actuel, ne le faites pas, parce que YAGNI.

Regardons un exemple concret auquel je viens de faire face: HTMLRenderer. La mise à l'échelle n'était pas correcte lorsque j'ai essayé de rendre le contexte de périphérique d'une imprimante. Il m'a fallu toute la journée pour découvrir que par défaut, il utilisait GDI (qui n'échelonnait pas) plutôt que GDI + (qui le faisait, mais pas antialias) car je devais parcourir six niveaux d'indirection dans deux assemblys avant de trouver code qui fait n'importe quoi .

Dans ce cas, je pardonnerai à l'auteur. L'abstraction est en fait nécessaire car il s'agit d'un code d'infrastructure qui cible cinq cibles de rendu très différentes: WinForms, WPF, Dotnet Core, Mono et PdfSharp.

Mais cela ne fait que souligner mon point: vous ne faites probablement pas quelque chose d'extrêmement complexe (rendu HTML avec des feuilles de style) ciblant plusieurs plates-formes avec l'objectif affiché de hautes performances sur toutes les plates-formes.

Votre code est presque certainement encore une autre grille de base de données avec des règles commerciales qui ne s'appliquent qu'à votre employeur et des règles fiscales qui ne s'appliquent que dans votre État, dans une application qui n'est pas à vendre.

Tout ce qui indirection résout un problème que vous n'avez pas et rend votre code beaucoup plus difficile à lire, ce qui augmente considérablement les coûts d'entretien et est un très mauvais service à votre employeur. Heureusement, les personnes qui devraient s'en plaindre sont incapables de comprendre ce que vous leur faites.

Un contre-argument est que ce type d’abstraction est favorable au développement piloté par les tests, mais je pense que TDD est également bouleversé, car cela présuppose que l’entreprise comprenne de manière claire, complète et correcte ses besoins. TDD est idéal pour la NASA et pour les logiciels de contrôle des équipements médicaux et des voitures autonomes, mais beaucoup trop cher pour tout le monde.

Incidemment, il n’est pas possible de prévoir toutes les économies d’été du monde. Israël, en particulier, a environ 40 transitions chaque année qui sautent partout parce que nous ne pouvons pas avoir des gens qui prient au mauvais moment et que Dieu ne fait pas l'heure avancée.

Si vous utilisez au moins java 8, vous devez écrire la classe WorldTimeZones pour fournir ce qui semble être en substance une collection de fuseaux horaires.

Ajoutez ensuite une méthode de filtrage (filtre de prédicat) à la classe WorldTimeZones. Cela donne à l'appelant la possibilité de filtrer ce qu'il veut en transmettant une expression lambda en tant que paramètre.

En substance, la méthode de filtrage unique prend en charge le filtrage sur tout ce qui est contenu dans la valeur transmise au prédicat.

Vous pouvez également ajouter une méthode stream () à votre classe WorldTimeZones qui génère un flux de fuseaux horaires lorsqu'elle est appelée. L’appelant peut alors filtrer, mapper et réduire à sa guise sans que vous ayez à écrire de spécialisations.