19.12.04
Enseignement de l'Objet
Intéressante discussion avec Jacques il y a quelques jours sur l'évolution du développement objet, et en particulier de l'enseignement de l'objet.
Constat de départ: le développement objet commence à se séparer en deux branches. Le développement de composants, et le développement de conteneurs/frameworks. Quelle est alors la place dans ce cadre de l'enseignement classique des concepts objet (classe/instance, héritage, envoi de message, aggrégation/composition, etc) ?
Bref, le monde commence à se séparer entre ceux qui vont mettre en place de quoi faire de la réutilisation, et ceux qui vont effectivement bénéficier de la réutilisation.
Les développeurs de composants
Le fait est que le boulot de développement orienté sur le composant nécessite plus et moins: plus, dans le sens où il faut une compréhension globale (pas forcément très en profondeur d'ailleurs) du framework dans lequel on s'insère. Cet apprentissage est d'ailleurs souvent assez implicite.
Comme le développeur se place dans une optique d'héritage et de spécialisation, une grande partie de la complexité du framework sous-jacent peut être masquée - plus (i.e. Swing) ou moins (i.e. J2EE). De plus en plus d'outils existent et favorisent ce style de développement. L'architecture dans ce cadre est relativement limitée, il est rare de trouver de vrais cas de réutilisations au niveau des classes, la réutilisation se fait plutôt par grands blocs fonctionnels, c'est à dire de composants eux-même, et non de portions de composants. Bref, on fait de l'objet dans le cadre du composant comme on pouvait (presque) faire du procédural, assez contraint et guidé par le modèle de composant auquel on se contraint.
Et au niveau du modèle objet, même si les bases sont nécessaires, les techniques de conception un peu évoluées ne sont pas forcément nécessaires. Par contre, il peut s'avérer très déstabilisant au départ de se retrouver face au "Principe d'Hollywood" (don't call us - we'll call you): c'est le framework autour qui contrôle le flux d'exécution, on est loin du "void main / hello world" canonique: il s'agit de réagir à des informations que va transmettre le framework, se faire appeler, persister, activer... Et l'idée forte d'Andrea Stein qu'il peut être bien plus pertinent de repenser l'apprentissage des concepts de base autour de la notion de boucle de traitement est sans doute directement applicable.
Les développeurs de frameworks
Autre grand domaine d'activité: la conception et le développement des frameworks eux-même. C'est la conception objet au sens classique, mais avec des préoccupations en plus. C'est peut-être plus le domaine des Patterns, de l'architecture. Contrairement à l'opinion générale, il est sans doute possible d'imaginer de l'enseignement dans ce domaine. Par exemple en mettant l'accent sur des préoccupation comme la montée en charge (y'a-t'il une meilleure traduction pour 'scalability' ?), la maîtrise de la charge mémoire, les préoccupations de déploiement et de distribution, la surveillance de l'applicatif résultant, le debugging.
Les outils sont assez pauvres dans ce domaine. Il y a un manque criant d'outils pour représenter, visualiser, agir sur des architectures de taille conséquente. Bref, il faudrait des techniques style LXR, mais à un cran d'abstraction supérieur. Tim Bray faisait remarquer par exemple que les outils de debugging pour les archis multithread sont dramatiquement manquant. Le développement test-based est une arme intéressante dans ce domaine-ci, mais on retombe très rapidement dans des problèmes d'expression (cf. l'exemple des threads, par exemple) ou d'exploitation (des expérimentations comme Tarantula sont à suivre).
Bref, il faudrait pour le haut-niveau des outils comme Shark pour le bas-niveau. Problème: cela nécessite déjà la capture d'une masse de donnée conséquente (il faut travailler niveau instance et ligne de code) et l'exploiter d'une façon pertinente (sans doute avec des traitements statistiques). Peut-être qu'on va finir par voir la prédiction de Daniel Hillis se réaliser
Notes annexes
Inconnues pouvant faire basculer cette distinction: la place des langages très dynamiques et leur intégration avec le monde objet classique (Groovy, IronPython, bref, les langages dynamiques implémentés dans le CLR ou une JVM), l'apparition ou non d'outils de développement véritable neutres / orientés point de vue, etc.
Une opposition intéressante vue sur le C2 Wiki
Constat de départ: le développement objet commence à se séparer en deux branches. Le développement de composants, et le développement de conteneurs/frameworks. Quelle est alors la place dans ce cadre de l'enseignement classique des concepts objet (classe/instance, héritage, envoi de message, aggrégation/composition, etc) ?
Bref, le monde commence à se séparer entre ceux qui vont mettre en place de quoi faire de la réutilisation, et ceux qui vont effectivement bénéficier de la réutilisation.
Les développeurs de composants
Le fait est que le boulot de développement orienté sur le composant nécessite plus et moins: plus, dans le sens où il faut une compréhension globale (pas forcément très en profondeur d'ailleurs) du framework dans lequel on s'insère. Cet apprentissage est d'ailleurs souvent assez implicite.
Comme le développeur se place dans une optique d'héritage et de spécialisation, une grande partie de la complexité du framework sous-jacent peut être masquée - plus (i.e. Swing) ou moins (i.e. J2EE). De plus en plus d'outils existent et favorisent ce style de développement. L'architecture dans ce cadre est relativement limitée, il est rare de trouver de vrais cas de réutilisations au niveau des classes, la réutilisation se fait plutôt par grands blocs fonctionnels, c'est à dire de composants eux-même, et non de portions de composants. Bref, on fait de l'objet dans le cadre du composant comme on pouvait (presque) faire du procédural, assez contraint et guidé par le modèle de composant auquel on se contraint.
Et au niveau du modèle objet, même si les bases sont nécessaires, les techniques de conception un peu évoluées ne sont pas forcément nécessaires. Par contre, il peut s'avérer très déstabilisant au départ de se retrouver face au "Principe d'Hollywood" (don't call us - we'll call you): c'est le framework autour qui contrôle le flux d'exécution, on est loin du "void main / hello world" canonique: il s'agit de réagir à des informations que va transmettre le framework, se faire appeler, persister, activer... Et l'idée forte d'Andrea Stein qu'il peut être bien plus pertinent de repenser l'apprentissage des concepts de base autour de la notion de boucle de traitement est sans doute directement applicable.
Les développeurs de frameworks
Autre grand domaine d'activité: la conception et le développement des frameworks eux-même. C'est la conception objet au sens classique, mais avec des préoccupations en plus. C'est peut-être plus le domaine des Patterns, de l'architecture. Contrairement à l'opinion générale, il est sans doute possible d'imaginer de l'enseignement dans ce domaine. Par exemple en mettant l'accent sur des préoccupation comme la montée en charge (y'a-t'il une meilleure traduction pour 'scalability' ?), la maîtrise de la charge mémoire, les préoccupations de déploiement et de distribution, la surveillance de l'applicatif résultant, le debugging.
Les outils sont assez pauvres dans ce domaine. Il y a un manque criant d'outils pour représenter, visualiser, agir sur des architectures de taille conséquente. Bref, il faudrait des techniques style LXR, mais à un cran d'abstraction supérieur. Tim Bray faisait remarquer par exemple que les outils de debugging pour les archis multithread sont dramatiquement manquant. Le développement test-based est une arme intéressante dans ce domaine-ci, mais on retombe très rapidement dans des problèmes d'expression (cf. l'exemple des threads, par exemple) ou d'exploitation (des expérimentations comme Tarantula sont à suivre).
Bref, il faudrait pour le haut-niveau des outils comme Shark pour le bas-niveau. Problème: cela nécessite déjà la capture d'une masse de donnée conséquente (il faut travailler niveau instance et ligne de code) et l'exploiter d'une façon pertinente (sans doute avec des traitements statistiques). Peut-être qu'on va finir par voir la prédiction de Daniel Hillis se réaliser
The second reason for believing in physical/computational model convergence is more profound and therefore more likely to be wrong. Both sciences study large systems of weakly interacting components. Such systems, with local rules of interaction, often seem to have simple macrolaws. This may be due to some "law of large systems" [...]
Notes annexes
Inconnues pouvant faire basculer cette distinction: la place des langages très dynamiques et leur intégration avec le monde objet classique (Groovy, IronPython, bref, les langages dynamiques implémentés dans le CLR ou une JVM), l'apparition ou non d'outils de développement véritable neutres / orientés point de vue, etc.
Une opposition intéressante vue sur le C2 Wiki
ObjectOrientedProgramming = Polymorphism + (Some) Late Binding + (Some) Encapsulation + Inheritance
ComponentOrientedProgramming = Polymorphism + (Really) Late Binding + (Real, Enforced) Encapsulation + Interface Inheritance + Binary Reuse
