" Le modèle d'interface constant est une mauvaise utilisation des interfaces "
Quiconque a concocté cette hypothèse, quelque gourou qu'il soit, l'a concoctée sur la base de la nécessité de continuer à mettre en œuvre efficacement les mauvaises habitudes et pratiques. L'hypothèse est basée sur la promotion de la validité des mauvaises habitudes de conception de logiciels.
J'ai écrit une réfutation de réponse contre cette hypothèse ici: Quelle est la meilleure façon d'implémenter des constantes en Java? expliquant le caractère sans fondement de cette hypothèse.
Pendant 10 ans, cette question était restée ouverte, jusqu'à ce qu'elle soit close dans les 2 heures après que j'aie affiché mes raisons justifiant cette hypothèse, exposant ainsi la NON-Volonté de débattre de ceux qui s'accrochent à cette hypothèse erronée.
Ce sont les points que j'ai exprimés contre l'hypothèse
La base de cette hypothèse est le besoin de méthodes et de règles RESTRICTIVES pour faire face aux effets des mauvaises habitudes et méthodologies logicielles.
Les partisans du sentiment " Le modèle d'interface constant est une mauvaise utilisation des interfaces" sont incapables de fournir d'autres raisons que celles causées par la nécessité de faire face aux effets de ces mauvaises habitudes et pratiques.
Résolvez le problème fondamental.
Et puis pourquoi ne pas utiliser pleinement et exploiter toutes les fonctionnalités du langage de la structure du langage Java à votre convenance. Aucune veste requise. Pourquoi inventer des règles pour barricader votre mode de vie inefficace pour discriminer et incriminer des modes de vie plus efficaces?
La question fondamentale
est l'organisation de l'information. Les informations servant de médiateur au processus, et le comportement de ces informations doivent d'abord être compris, ainsi que les soi-disant règles métier - avant de concevoir ou de compléter des solutions au processus. Cette méthode d'organisation de l'information s'appelait il y a quelques décennies la normalisation des données.
Alors seule l'ingénierie d'une solution sera possible car aligner la granularité et la modularité des composants d'une solution avec la granularité et la modularité des composants de l'information est la stratégie optimale.
Il existe deux ou trois obstacles importants à l'organisation de l'information.
Le manque de perception de la nécessité d'une «normalisation» des modèles de données.
Les déclarations d'EF Codd sur la normalisation des données sont erronées, défectueuses et ambiguës.
La dernière mode qui se fait passer pour une ingénierie agile est la notion erronée selon laquelle il ne faut pas planifier et conditionner l'organisation des modules à l'avance, car vous pouvez la refactoriser au fur et à mesure. La refactorisation et le changement continu sans être entravés par de futures découvertes sont utilisés comme excuse. Les découvertes essentielles du comportement des informations de processus sont alors, en utilisant des astuces comptables pour retarder les profits et l'actifisation, c'est pourquoi les connaissances essentielles et leur traitement ne sont pas jugées nécessaires maintenant.
L'utilisation des constantes d'interface est une bonne pratique.
N'inventez pas de règles et n'émettez aucune fatwa contre cela simplement parce que vous aimez vos habitudes de programmation ponctuelles.
N'interdisez pas la possession d'armes à feu au motif qu'il y a des gens qui ne savent pas comment manier les armes ou qui sont enclins à abuser des armes à feu.
Si les règles que vous concoctez sont destinées à des novices en programmation incapables de coder professionnellement et que vous vous comptez parmi eux, dites-le - ne déclarez pas votre fatwa comme applicable à des modèles de données correctement normalisés.
Un raisonnement idiot - Les interfaces n'étaient pas destinées par les patrouilleurs du langage Java à être utilisées de cette façon?
Je me fiche de ce que les intentions originales des pères fondateurs avaient pour la Constitution américaine. Je me fiche des intentions non écrites et non codifiées. Je ne me soucie que de ce qui est littéralement codifié dans la Constitution écrite et de la manière dont je peux les exploiter pour le fonctionnement efficace de la société.
Je ne me soucie que de ce que me permettent les spécifications du langage / plate-forme Java et j'ai l'intention de les exploiter au maximum pour me donner un moyen d'exprimer mes solutions logicielles de manière efficace et efficiente. Aucune veste requise.
L'utilisation des constantes Enum est en fait une pratique horrible.
Il faut écrire du code supplémentaire pour mapper le paramètre à la valeur. Le fait que les fondateurs de Java n'aient pas fourni de mappage paramètre-valeur sans que vous ayez écrit ce code de mappage démontre que les constantes Enum sont tout aussi une utilisation non intentionnelle du langage Java.
D'autant que vous n'êtes pas encouragé à normaliser et à composant vos paramètres, il y aurait une fausse impression que les paramètres mélangés dans un sac Enum appartiennent à la même dimension.
Les constantes sont un contrat API
N'oublie pas ça. Si vous avez conçu et normalisé votre modèle de données et qu'il inclut des constantes, ces constantes sont des contrats. Si vous n'avez pas normalisé votre modèle de données, vous devez vous conformer aux fatwas données sur la façon de pratiquer le codage restrictif pour faire face à cette mauvaise habitude.
Par conséquent, les interfaces sont un moyen idéal de mettre en œuvre le contrat de Constants.
Une étrange présomption - Et si l'interface était implémentée par inadvertance.
Ouaip. N'importe qui pourrait implémenter par inadvertance une interface par inadvertance. Rien ne fera obstacle à de tels programmeurs par inadvertance.
Concevez et normalisez votre modèle de données contre les fuites
Ne placez pas de décrets restrictifs pour protéger les mauvaises pratiques présumées qui provoquent la fuite de paramètres non contractuels / errants dans l'API. Résolvez le problème fondamental, plutôt que de rejeter la faute sur les constantes d'interface.
Ne pas utiliser d'EDI est une mauvaise pratique
Un programmeur fonctionnant normalement et EFFICACE n'est pas là pour prouver combien de temps elle peut rester sous l'eau, jusqu'où elle pourrait marcher dans une chaleur fulgurante ou des orages humides. Elle doit utiliser un outil efficace comme une voiture ou un bus ou au moins un vélo pour prendre ses 10 miles au travail tous les jours.
Ne placez pas de restrictions sur les autres programmeurs simplement parce que vous avez une obsession d'ascèse ésotérique avec la programmation sans IDE.
Quelques frameworks sont conçus pour aider les programmeurs à continuer à pratiquer efficacement les mauvaises habitudes.
OSGI est un tel cadre. Tout comme le décret contre les constantes d'interface.
Par conséquent, la réponse définitive ...
Les constantes d'interface sont un moyen efficace et efficient de placer dans un contrat des composants bien conçus et normalisés d'un modèle de données.
Les constantes d'interface dans une interface privée correctement nommée imbriquée dans un fichier de classe sont également une bonne pratique pour regrouper toutes vos constantes privées plutôt que de les disperser dans le fichier.