AFUP Day 2019
[:fr]La parole est aux speakers : Frédéric Hardy (AFUP Day 2019 Lyon)[:]
[:fr]Jusqu’à l’AFUP Day 2019 Lyon, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !
La conférence
Quel est le rapport entre TCP, UDP et la programmation orientée objet ?La programmation orientée objet doit permettre la conception de programmes fiables, évolutifs, facilement et rapidement, à l’aide de briques de code réutilisables. Pourtant, il est rare de pouvoir réutiliser du code orienté objet dans un contexte différent de celui pour lequel il a été conçu. De plus, parvenir à faire collaborer des objets qui ne sont pas issus du même écosystème n’est pas forcément trivial. Les programmes ont pris de l’embonpoint en termes de quantité de code et de complexité, et ils sont donc dans la plupart des cas très gourmands en ressources intellectuelles et techniques pour leur conception et leur mise en œuvre. De plus, ils deviennent souvent rapidement difficiles à faire évoluer, et leur fiabilité est incertaine et délicate à maintenir sur la durée, si tant est qu’elle soit suffisante dès leur première mise en production. Le constat est donc cruel : la programmation orientée n’a pas tenu ses promesses ! Quoique… l’Homme a une tendance naturelle à accuser l’outil plutôt que la façon dont il l’utilise. Et si nous laissions le bénéfice du doute à la programmation orientée objet durant cette conférence et que nous en profitions pour remettre en cause la façon dont nous l’appréhendons?? En réalisant un parallèle entre les protocoles de communication UDP et TCP à la base d’Internet et la façon dont nous écrivons du code orienté objet actuellement, j’espère vous faire douter de vous-même et à nouveau vous faire croire aux promesses d’Alan Kay ! |
SupInfo 17/05/2019 09:20-10:00 |
Ces dernières années on a souvent parlé de DDD, microservices ou d’architecture hexagonales. Tu vas nous parler de POO, TCP, UDP : des principes qui ont des dizaines d’années d’existence. Penses-tu que ce retour à la base est le meilleur moyen de garantir la simplicité ?
L’objectif derrière le fait de mettre en relation ces concepts est d’apporter un éclairage différent sur la POO par rapport aux pratiques actuelles.
En tant que développeurs, nous avons tous pour objectif de produire facilement et rapidement du code qui répond aux besoins des clients ou des utilisateurs et qui soit simple à maintenir et à faire évoluer.
Et pour y parvenir, nous avons à notre disposition tout un tas de recettes de cuisine ou d’outils qui s’appellent TDD, DDD, architecture hexagonale, design pattern, « if less programming », « object calisthenics », SOLID, et il y en a beaucoup d’autres.
Pourtant, malgré cette pléthore de bonnes pratiques et de recommandations, dans les faits, la plupart du temps, cet objectif n’est que partiellement atteint.
Un jour ou l’autre, nous sommes dans l’impossibilité de faire évoluer le code simplement, et nous sommes alors obligés de produire de la dette technique qu’il faudra rembourser à plus ou moins long terme.
Et comme la dette appelle la dette, elle va donc rendre plus compliquée la maintenance du code et rendre plus complexe son évolution.
Or, la POO a été conçue justement pour répondre à cette problématique, et non pour la provoquer.
C’est en cherchant à comprendre l’origine de ce paradoxe et en revenant à ces origines que je me suis aperçu que nous faisons de la POO, mais que nous ne la comprenons pas réellement.
Nous utilisons la POO pour développer des programmes qui sont une suite d’appel de fonction, alors qu’elle est censée permettre la conception d’un protocole de communication et de l’implémenter.
C’est pour illustrer cela que j’utilise TCP et UDP dans cette conférence, mais je n’en dirais pas plus maintenant.
Si vous voulez savoir exactement ce que j’entends par là et si ce « retour à la base » permet effectivement de « garantir la simplicité », il faudra venir à ma conférence 😉
(suite…)