J'ai entendu la phrase être lancée et pour moi les arguments semblent complètement fous (désolé si je fais de la paille ici, ce n'est pas mon intention), généralement cela va quelque chose dans le sens de:
Vous ne voulez pas créer une abstraction avant de savoir quel est le cas général, sinon (1) vous pourriez mettre dans vos abstractions des choses qui n'appartiennent pas, ou (2) omettre des choses importantes.
(1) Pour moi, cela semble que le programmeur n'est pas assez pragmatique, ils ont fait des suppositions que les choses existeraient dans le programme final qui ne fonctionne pas, donc ils travaillent avec un niveau d'abstraction bas, le problème n'est pas l'abstraction prématurée, c'est la concrétion prématurée.
(2) L'omission de choses importantes est une chose, il est tout à fait possible que quelque chose soit omis de la spécification qui s'avère plus tard important, la solution à cela n'est pas de trouver vos propres ressources de concrétion et de gaspillage lorsque vous vous découvrez deviné mal, c'est pour obtenir plus d'informations du client.
Nous devons toujours travailler des abstractions jusqu'aux concrétions car c'est la façon la plus pragmatique de faire les choses, et non l'inverse.
Si nous ne le faisons pas, nous risquons de mal comprendre les clients et de créer des choses qui doivent être changées, mais si nous construisons uniquement les abstractions que les clients ont définies dans leur propre langue, nous ne risquons jamais ce risque (au moins loin d'être aussi probable que de prendre un coup dans le noir avec une certaine concrétion), oui, il est possible que les clients changent d'avis sur les détails, mais les abstractions qu'ils utilisaient à l'origine pour communiquer ce qu'ils veulent ont tendance à être toujours valables.
Voici un exemple, supposons qu'un client souhaite que vous créiez un robot d'ensachage d'articles:
public abstract class BaggingRobot() {
private Collection<Item> items;
public abstract void bag(Item item);
}
Nous construisons quelque chose à partir des abstractions utilisées par le client sans entrer dans les détails avec des choses que nous ne savons pas. C'est extrêmement flexible, j'ai vu cela être appelé "abstraction prématurée" alors qu'en réalité il serait plus prématuré de supposer comment l'ensachage a été mis en œuvre, disons après avoir discuté avec le client qu'il veut que plus d'un article soit mis en sac à la fois . Afin de mettre à jour ma classe, tout ce dont j'ai besoin est de changer la signature, mais pour quelqu'un qui a commencé de bas en haut, cela pourrait impliquer une refonte complète du système.
Il n'y a pas d'abstraction prématurée, seulement de concrétion prématurée. Quel est le problème avec cette déclaration? Où sont les défauts de mon raisonnement? Merci.