Les langages de programmation sont trop compliqués

754 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
754
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Les langages de programmation sont trop compliqués

  1. 1. Coder
  2. 2. Coder j’adore ça !
  3. 3. Coder ...mais c’est trop compliqué !
  4. 4. Apprenons le Java ! class MainClass { public static void main(String[] args) { System.out.println(“Hello, World!”); } }
  5. 5. Apprenons le Java ! class MainClass { public static void main(String[] args) { System.out.println(“Hello, World!”); } }
  6. 6. Apprenons le Java ! ? ? ? ? ? ? class MainClass { public static void main(String[] args) { System.out.println(“Hello, World!”); } } ? ? ? ? ? ?
  7. 7. Apprenons le Java ! ? ? ? ? ? ? ??! class MainClass { public static void main(String[] args) { System.out.println(“Hello, World!”); } } ? ? ? ? ? ?
  8. 8. puts “Hello World!” print(“Hello World!”) printStrLn “Hello World!” print “Hello World!”
  9. 9. Alors comme ça c’est compliqué ? Making Software: What Really Works and Why We Believe It Why is it So Hard to Learn to Program?
  10. 10. Compliqué ? Concevoir un algorithme est simple. Communiquer un algorithme à un humain est simple. Communiquer un algorithme à une machine est moins simple.
  11. 11. Pourquoi ? Les langages de programmation ! (?)
  12. 12. Plus précisément Les langages de programmation orientés objet java, c#, python, ruby...
  13. 13. Axiomes Orienté-objet = polymorphisme + encapsulation Qualité = testable / modulaire + maintenable / lisible
  14. 14. Les méthodes privées ranger == planquer sous le lit
  15. 15. Une méthode publique trop imposante Test Interface Méthode publique Implémentation cp cp
  16. 16. Des méthodes privées à la rescousse Test Interface mpub Implémentation mpriv mpriv cp cp
  17. 17. Des problèmes Test Interface mpub Implémentation mpriv mpriv cp cp
  18. 18. Deux styles de méthodes privées // field equals x updateField(); // field equals y Parfum de variable globale // field equals x field = computeValue(); // field equals y Méthode détachée de son objet
  19. 19. Des objets à la rescousse Test Interface mpub Implémentation Nouvelle dépendance Nouvelle dépendance mpub mpub cp cp
  20. 20. Les méthodes privées ● Inutiles ● Dangereuses
  21. 21. L’héritage de classe Coupling: it’s over 9000!
  22. 22. Difficile à tester Mère Test Mère Fille Test Fille
  23. 23. Difficile à tester Mère Test Mère super Fille Test Fille
  24. 24. Difficile à tester Mère Test Mère Fille Test Fille
  25. 25. Difficile à tester Mère Test Mère Fille Test Fille
  26. 26. Difficile à tester Mère Test Mère Fille Test Fille
  27. 27. Difficile à tester Mère Test Mère Fille Test Fille
  28. 28. Difficile à maintenir public
  29. 29. Difficile à maintenir public protected
  30. 30. Difficile à maintenir public protected Faible encapsulation Couplage fort Double dépendance
  31. 31. Dépendences cycliques Classe abstraite
  32. 32. Dépendences cycliques Classe abstraite ?
  33. 33. Dépendences cycliques Classe abstraite Classe fille concrète
  34. 34. Dépendences cycliques Classe abstraite ??! Classe fille concrète
  35. 35. C’est l’enfer ! ● Difficile à tester ● Difficile à maintenir ● Dépendances ‘cycliques’
  36. 36. C’est l’enfer ! ● ● ● ● Difficile à tester Difficile à maintenir Dépendances ‘cycliques’ Et ça sert à...quoi exactement ?
  37. 37. C’est l’enfer ! ● ● ● ● Difficile à tester Difficile à maintenir Dépendances ‘cycliques’ Et ça sert à...quoi exactement ? ■ L’héritage d’interfaces fournit déjà le polymorphisme ■ La composition fournit déjà de quoi réutiliser les implémentations
  38. 38. Solution : composition interface MembreDeLaFamille {...} class Mère implements MembreDeLaFamille {...} class Fille implements MembreDeLaFamille { private final MembreDeLaFamille mère; public Fille(MembreDeLaFamille mère) { this.mère = mère; } ... }
  39. 39. Solution : composition abstract class AbstractCollection<T> class CollectionDecorator<T> implements Collection<T> { implements Collection<T> { boolean contains(Object o) { final Iterable<T> iterable; ...// appelle iterator() } boolean contains(Object o) { ...// appelle iterator() abstract Iterator<T> iterator(); } } Iterator<T> iterator() { return iterable.iterator(); } }
  40. 40. Static dispatch It’s not a bug, it’s a feature!
  41. 41. L’enfer 2.0
  42. 42. L’enfer 2.0 ● Difficile à tester
  43. 43. L’enfer 2.0 ● Difficile à tester ● Difficile à maintenir
  44. 44. L’enfer 2.0 ● Difficile à tester ● Difficile à maintenir ● Détruit tout polymorphisme
  45. 45. L’enfer 2.0 ● ● ● ● Difficile à tester Difficile à maintenir Détruit tout polymorphisme Rend les classes potentiellement variables… alors qu’elles sont globales !
  46. 46. Pragmatisme
  47. 47. Débutants
  48. 48. Merci ! Questions ? Hugo.Wood@sopragroup.com / @mercury_wood / elevatedabstractions.wordpress.com

×