Mais sous ce titre semblant sortir de l’esprit dérangé d’on ne sait qui (de moi en fait) se cache une vraie analyse de fond : le Père Noël fut le premier à pratiquer le Cloud Computing.

Éclaircissons un peu les choses…

La distribution de cadeaux a franchement évolué au cours des dernières décennies. Même si on s’imagine toujours le Père Noël comme un barbu quelque peu ventripotent (donc à priori jovial, j’ai peine à imaginer un barbu ventripotent grincheux) en survet’ rouge à fourrure blanche assis dans un traineau en bois tiré par X rennes (X variant de 2 à une douzaine en fonction des cultures et de la brochure marketing), il faut bien se dire que ce fantasme nourri par des hordes de publicitaires voulant nous pousser à la consommation est très probablement loin en deçà de la réalité.

Déjà, un traineau en bois, faut arrêter de planer. Vu la cadence que doit tenir le Père Noël, un traineau en bois ne pourrait pas encaisser les G lors des accélération pour aller d’une maison à une autre. Au premier départ le traineau volerait en échardes. En plus le bois, même traité, c’est pas tip top face aux intempéries que peut subir le Père Noël (surtout en cette saison). Vu la masse de cadeaux qu’il doit se trimballer, à moins de faire des aller-retours avec le Pôle Nord (peu probable), il faudrait un traineau monstrueux pour arriver à supporter le poids total. Vous rajoutez par-dessus tout ça quelques mouvements pour la sauvegarde des arbres qui risqueraient de lui coller un procès au cul et vous vous rendez compte que non, le Père Noël ne se trimballe plus dans un traineau en bois depuis longtemps.

Depuis l’invention du moteur à explosion, la révolution industrielle, etc, il est fort probable que le Père Noël fasse sa tournée à bord du dernier cri en matière de jets privés. Il est également probable que ce jet soit une petite merveille d’électronique embarqué afin d’arriver à larguer les bons cadeaux aux bons moments.

Parce que là où le Père Noël pouvait prendre son temps à une époque lointaine, aujourd’hui il est obligé de tout torpiller en un temps record. A cause de l’évolution de la société, la mentalité universelle “je veux tout et maintenant”, la révolution de la téléphonie mobile et des réseaux sociaux. La téléphonie mobile et les réseaux sociaux ? Et bien oui ! Aujourd’hui, si le Père Noël ne se met pas le turbo au cul pour faire sa distribution, il y a fort à parier qu’il va se faire tracer et n’importe qui pourra savoir exactement où il se trouve face à Twitter. Combien de temps a-t-il fallu pour que l’annonce de la mort de Mickael Jackson fasse le tour de la planète ? Si le Père Noël paraisse un peu, serait-ce pour faire une unique pause afin de manger un biscuit ou boire un verre de lait laissé là par un enfant (naïf, la faute aux publicitaires, cf plus haut), il est foutu. C’est un coup à se faire braquer par une bande de gamins de 5 ans. Que voulez-vous, après avoir appris que l’un des mots les plus recherchés par les moins de 7 ans est le mot “porn”, on ne s’attend pas à ce qu’ils fassent preuve d’état d’âme vis à vis du Père Noël.

Donc côté distribution, ça s’est fortement industrialisé.

En plus, avec la législation du travail, je ne serais pas étonné d’apprendre qu’il ne se déplace plus, que tout est automatisé. Avez-vous songé à quoi doit ressembler son contrat de travail ? La somme d’indemnités de déplacements qu’il doit toucher, même pour une unique nuit de travail doit être faramineuse. Plus les heures sup. Plus la prime de risque car voler de nuit, tous feux éteints (pour éviter de se faire détourner par des pirates de l’air), quelque soit la météo et à son âge (vue défaillante, peut-être des problèmes d’incontinence également). Non, d’un point de vue assurances et indemnités, son patron n’aurait pas pu suivre et ça aurait coulé leur business en un Noël.

La solution la plus simple aurait donc été d’investir dans la R&D afin d’automatiser tout le process. Avions drones, manufacture automatisée du début à la fin (ceux qui croient encore aux lutins qui travaillent en chantonnant peuvent aller se rhabiller, vous imaginez des lutins en train de monter une PS3 alors que le Japon fait ça via des chaînes de montage ?).

Ou alors de basculer vers du cloud computing. Le coeur de métier du Père Nöel, à savoir collecter les demandes, préparer les cadeaux et effectuer la livraison, est effectué dans le nuage. Au coeur du réseau. Le réseau de quoi ? Le réseaux des parents bien entendu ! Le Père Noël sous-traite son taf aux parents des gamins ! Il se charge de collecter les demandes (qui sont directement retournées aux parents vu que ce sont eux qui font les achats) et ça s’arrête là. En fait, le Père Noël n’est plus qu’un maillon du système : il vend son image et ne s’occupe plus du tout du business des cadeaux. D’un point de vue stratégie de groupe, ça a un vrai intérêt, ça évite de se disperser dans de multiples domaines au risque de perdre sa spécialisation et de se focaliser sur un seul métier.

Enfin bref, le Père Noël a pas mal changé. Je sais pas si c’est vraiment un changement positif, les nostalgiques diront probablement que c’est affreux.

Mais bon, les nostalgiques auraient l’air malin si on leur offrait un simili d’IPhone taillé dans du bois par un lutin sous-payé.

Que ça ne vous empêche pas de passer un Joyeux Noël et une bon début d’année 2010.

Ce qu’il faut en retenir (ce que j’en ai retenu)

L’un des principaux problèmes des feuilles de styles est leur tendance à gonfler, gonfler, gonfler ce qui les rend plus coûteuse en bande passante mais aussi en maintenabilité (sans compter les risques liés aux styles s’écrasant mutuellement).

La raison est relativement simple : il n’est pas forcément évident de réutiliser des styles déjà existants. On a tendance à concevoir les règles CSS par rapport au contenu d’une page, éventuellement à réutiliser ce qui a été fait sur une page similaire si les similitudes sont flagrantes.

Nicole recommande une approche bien plus pérenne : séparer la structure et le design (ce qui ne veut pas uniquement dire avoir une feuille de style externe mais se baser sur des classes CSS et non sur des balises particulières) et séparer le contenu du contenant.

En fait, il vaut voir une bonne conception CSS comme un assemblage de Legos : commencez par créer votre collection de briques. Une fois que la collection de brique est prête, vous pouvez commencer à créer vos pages, autrement dit vous pouvez commencer à assembler vos briques ensemble pour aboutir au résultat graphique attendu.

Les 10 best practices qu’elle cite :

1. Créez une bibliothèque de composants
2. Utilisez des styles en accord avec la sémantique
3. Concevez des modules avec un fond transparent
4. Soyez flexible
5. Apprenez à aimer les grilles
6. Minimisez l’emploi des sélecteurs
7. Séparez la structure et le design
8. Séparer le contenu et le contenant
9. Etendez les objets en appliquant plusieurs classes sur un élément HTML
10. Utilisez des feuilles de style de reset et de gestion des polices

Et les 9 choses à éviter :

1. Evitez les styles dépendants de l’endroit où vous vous trouvez sur le site
2. Evitez de créer des styles qui dépendent des balises utilisées
3. Limitez l’utilisation d’IDs : ils doivent se limiter aux zones principales, pour le reste utilisez des classes
4. Fuyez les coins arrondis ou les ombres appliqués par-dessus des fonds non-unis (image de fond ou dégradé).
5. Evitez de faire un sprite contenant toutes vos images, à moins que vous ayez qu’un faible nombre de pages
6. Tentez d’éviter les alignements sur la hauteur
7. Le texte c’est du texte, pas une image contenant du texte
8. Evitez la redondance
9. Evitez l’optimisation prématurée

Maintenant si on va un peu plus dans les détails pour certaines parties…

Séparez le contenu du contenant

Ca veut dire qu’un module est composé :

• d’une brique pour la gestion de la bordure (coin arrondis ou carrés, couleur, ombre)
• d’une brique pour le fond (fond uni, image de fond en filigrane, dégradé)
• d’un ensemble de briques pour le contenu

Autrement dit, un module devrait avoir 3 classes afin de définir à quoi doit ressembler sa bordure, quel est le fond à appliquer et comment le contenu doit être organisé.

Séparez la structure et le design

Prévoyez à l’avance la structure basique d’un bloc : faut-il un header dans un bloc ? faut-il un footer ?

De cette manière, créer un bloc se limitera à appliquer les bonnes classes (”block”, “hd”, “ft”, “bd”) au contenu du block.

Une fois que cette structure est définie, vous pouvez alors concevoir les différents design qui s’appliqueront sur cette structure : une brique avec des coins arrondis, une brique pour gérer le fond en dégradé, etc.

Faites des modules transparents

Si vous voulez des coins arrondis, préférez une solution où le coin est créé par l’extérieur et non par l’intérieur, autrement dit une solution où l’image du coin est transparente à l’intérieur et unie à l’extérieur. Cette solution vous permettra d’appliquer n’importe quel fond à l’intérieur de votre bloc, que ce soit une couleur unie ou une image en arrière-plan.

Bémol : le bloc ne pourra être placé que sur un fond correspond à la couleur extérieure de vos coins arrondis (typiquement le fond de votre page).

Soyez flexible

Faites de la gym. Faites en sorte que vos briques puissent s’adapter en largeur et en hauteur. En hauteur pour pouvoir s’adapter à la hauteur du contenu, en largeur pour pouvoir réutiliser votre brique dans n’importe quelle zone de votre grille même si la largeur varie.

C’est la grille qui doit gérer la largeur, les blocs doivent ignorer pour quelle partie de la grille ils ont été conçus.

Tentez une approche UML

Tentez de mettre en place un système d’héritage à vos briques.  Certaines briques seront compatibles ensemble (par exemple certaines briques de gestion de bordure ne pourront pas forcément être appliquées à n’importe quel brique d’arrière plan ou même de mise en forme du contenu).

Ces relations entre vos briques peuvent donner lieu à un schéma plus ou moins UML pour faciliter la compréhension des briques existantes.

Un exemple d’approche UML conçue par Nicole :

Approche UML pour la couche CSS d'un projet

Bref, plein de bonnes suggestions à tenter de mettre en pratique…

Essayons de notre côté d’aller un peu plus loin que cette liste. Lorsque IE6 aura disparu, la nouvelle barrière sera IE7 mais l’abandon d’IE6 débloquera un tas de fonctionnalités CSS actuellement délaissées car incompatibles.

En vrac :

• l’utilisation du sélecteur CSS fils (>) afin de sélectionner les noeuds immédiatement en-dessous d’un noeud et non toute sa descendance.
• j’aurais bien dit le sélecteur de noeuds adjacents (+) mais il est un poil buggé sur IE7
• le sélecteur par attribut ([attr]) pour sélectionner des noeuds en fonction de la présence d’un attribut et de sa valeur, idéal pour différencier les éléments INPUT d’un formulaire (bouton, champs texte, bouton radio, case à cocher, bouton d’envoi, etc).
• la bonne gestion des classes multiples, actuellement un tantinet foireuse sur IE6
• le :hover sur n’importe quoi et pas uniquement sur les liens
• :first-child, pour sélectionner le premier fils d’un noeud
• le display:inline-block pour les éléments initialement avec un display:inline
• display:list-item
• min-width, max-width, min-height, max-height
• utilisation correcte du overflow:visible
• position:fixed
• le sélecteur de précédence (~) permettant de sélectionner un noeud en fonction d’un noeud qui le précéde. Le sélecteur d’adjacence (+) implique que le noeud adjacent précéde immédiatement le noeud ciblé alors que le sélecteur de précédence (~) permet d’avoir des noeuds entre le noeud ciblé et le noeud qui précéde.

Bref, plein de nouvelles choses qui nous permettront de nous arracher un peu moins les cheveux. Mais bon, en attendant, vous allez continuer à vous les arracher par poignées, IE6 est encore coriace…

Néanmoins, une branche de ce domaine qui a été assez peu analysée est l’impact de l’utilisation des sélecteurs CSS et surtout la nécessité, ou pas, d’avoir des règles avec un grand nombre de sélecteurs.

En fait tout a démarré lorsque Dave Hyatt (le Lead Developer de l’équipe WebKit) a fait remarquer dans un commentaire du blog de Shaun Inman que les sélecteurs CSS enfant (comme le caractère espace) étaient à utiliser à la légère car s’appliquent de droite à gauche et non de gauche à droite.

The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers. - Dave Hyatt

Ce qui fait que, comme le résume Jon Sykes, la règle suivante :

body table tr td.myTestClass{
  background-color: red;
}

…est moins efficace que sa version courte :

.myTestClass{
  background-color: red;
}

Pourquoi ? Tout simplement parce qu’avec la première règle, si vous modifiez le DOM cette règle devra probablement être ré-appliquée sur tout le document afin de l’appliquer à de nouveaux noeuds ou au contraire à ne plus l’appliquer sur certains noeuds. Alors qu’avec la seconde règle, la modification du DOM n’aura un impact que si cette modification consiste à ajouter ou à retirer la classe “myTestClass”.

Bref, vouloir faire des règles avec une longue série d’accesseurs enfant pour cibler exactement l’élément qui nous intéresse peut s’avérer couteux sur les performances, il est préférable de donner une classe précise à notre ou nos éléments et de créer une règle qui se base sur cette classe et sur rien d’autre.

Pour montrer ce coût en performances, Jon Sykes a réalisé plusieurs tests. Son dernier test consiste à créer une page contenant trois niveaux de DIV imbriqués, le niveau le plus profond contient un paragraphe contenant lui-même un lien. Le lien a un ID et une classe générée. Au total, il y a 20.000 liens dans la page.
Il a ensuite cherché à comparer le temps mis pour afficher la page avec les conditions suivantes :

• aucun style appliqué
• un fond rouge pour chaque cellule avec une unique règle qui s’applique sur la balise A
• un fond rouge pour chaque cellule avec des règles ayant uniquement le nom de la classe du lien (20.000 règles)
• un fond rouge pour chaque cellule avec des règles utilisant le sélecteur fils (20.000 règles)
• un fond rouge pour chaque cellule avec des règles utilisant le sélecteur descendant (20.000 règles)

Il obtient les résultats suivants (les pourcentages affichés sont par rapport à l’affichage sans aucun style) :

Bref, privilégiez les règles avec des sélecteurs courts. Ca risque d’alourdir votre code HTML avec plus de classes ou d’ID mais les performances d’affichage de votre page s’en sortiront mieux.

Pour lire les articles de Jon Sykes :

1. Testing CSS Performance
2. Testing CSS Performance (pt 2)
3. More CSS Performance Testing (pt 3)

Steve Sounders creuse le sujet un peu plus loin

Les tests de Jon Sykes datent du printemps 2008.

Récemment (début Mars), Steve Sounders (de l’équipe Performances de Yahoo!) a creusé le sujet. Il considérait que bien que justes, les tests de Jon Sykes s’appliquaient à des pages bien trop volumineuses pour représenter la réalité : peu de pages peuvent se vanter d’aligner un DOM de 60.000 noeuds et de 20.000 règles CSS. Les 10 sites les plus fréquentés ont une moyenne de 923 noeuds sur leur homepage pour 1033 règles.

Les tests de Steve Sounders sont dont légèrement différents de ceux de Jon Sykes : il se limite à 2.000 liens et 2.000 règles CSS (et non plus 20.000) ce qui donne une page avec un DOM de 6.000 noeuds.
Il s’est également demandé si les résultats pour la page ne contenant aucun style et celle ne contenant qu’une seule règle sur la balise A n’avaient pas un gain en performance simplement parce que leur code contient 20.000 lignes de code en moins. Il a donc décidé de rajouter, pour ces deux cas, 2.000 règles CSS (qui ne s’appliquent sur rien du tout) afin que la taille des codes HTML soit pratiquement la même pour tous les cas de test.

Bref des tests sur un DOM plus réduit et plus proche de la réalité et des cas de tests de même volume.

Ses tests montrent des résultats assez différents de ceux de Jon Sykes, comme le montre son graphique :

On constate que la plupart des navigateurs conservent des courbes relativement “planes”. Comme le dit Steve, sur les principaux navigateurs (IE6&7 + FF3), la différence entre le test sans style et le test avec les sélecteurs fils ou descendants est en moyenne de 20ms et sur la totalité des navigateurs ça monte à une moyenne de 50ms. Donc un résultat difficile à percevoir à l’oeil nu.

Les résultats de Jon Sykes n’était donc pas vraiment applicable. Mais pourquoi une telle différence de résultats ?

Pour comprendre ce changement, Steve Sounders (qui est décidément très curieux) a décidé de refaire passer son test sur IE6&7 (ce sont les navigateurs pour lesquels il avait la différence la plus flagrante avec les tests de Jon) en les faisant tourner sur des pages ayant de plus en plus de balise A (et par conséquent de noeuds DOM et de règles CSS). Il a donc commencé avec 1.000 liens et a augmenté jusqu’à atteindre les 20.000 du test de Jon.

C’est avec ce test qu’il a constaté un palier autour de 18.000 noeuds, comme le montre son second graph :

En définitive, que devons-nous tirer de ces deux analyses ?
Simplement que la recherche d’optimisation n’est finalement pas dans l’utilisation parcimonieuse des sélecteurs CSS. Dans la plupart des cas le gain sera négligeable et risquerait d’entraîner une baisse de lisibilité du code pour les développeurs.

Il reste quelques soucis par rapport aux exemples de code, mon module de coloriage syntaxique est pas très adapté, je vais le changer…

1. d’abord, vous attendez que le DOM soit complétement chargé afin d’être certain de ne pas louper certains noeuds supposés recevoir l’événement
2. ensuite, vous faites une recherche sur l’intégralité du DOM, soit via votre librairie javascript favorite, soit comme un grand avec vos petites patounes, afin de récupérer la liste des noeuds qui correspondent à votre recherche
3. une fois que vous avez votre collection de noeuds, vous faites une boucle dessus pour tous leur appliquer le même événement, par exemple sur le clic

La majorité des développements en JavaScript fonctionnent actuellement de cette manière et les librairies javascript sont conçues sur ce principe.

Reglib va à l’encontre de ce principe et adopte une approche qu’on pourrait considérer comme plus efficace et plus intelligente.

Le principe est plutôt simple :

1. le gestionnaire d’événement est appliqué sur le body et non pas sur les noeuds du DOM qui sont visés (par exemple nos liens qui ont la bonne classe)
2. lorsque l’utilisateur clic quelque part (et plus globalement lorsqu’il déclenche un événement), l’événement remonte vers le body grâce au mécanisme de propagation des événements,
3. lorsque le body reçoit l’événement, il vérifie s’il n’a pas une règle associé à la cible initiale de l’événement, si c’est le cas, il exécute la fonction associée.

Ce fonctionnement a plusieurs avantages non-négligeables :

• pas besoin d’attendre le chargement complet du DOM vu qu’on place le gestionnaire d’événement directement sur le noeud body, qui est l’un des premiers créé au chargement de la page
• pas de traitement lourd sur l’initialisation de la page étant donné qu’on ne boucle pas sur des collections de noeuds auxquels on doit appliquer un gestionnaire d’événement, on se contente de l’appliquer sur le body,
• inutile de réappliquer le gestionnaire d’événement lorsqu’on crée du contenu de façon dynamique, les événements déclenchés par le contenu créé dynamique remonteront eux aussi vers le body donc seront traités correctement,

Bon, on peut toutefois noter quelques défauts à ce mécanisme :

• Tous les événements passent dans la moulinette associée au body pour savoir si leur cible initiale correspond à l’une des règles placées sur le body et vu la quantité astronomique d’événements (en particulier ceux générés par les déplacements et les survols de la souris), ça en fait un paquet.
• On ne peut pas retirer facilement l’événement appliqué à un noeud particulier. Par exemple si vous avez un gestionnaire d’événement basé sur tous les noeuds qui respectent la règle “a.maClasse”, autrement dit tous les liens ayant pour classe “maClasse”, et que vous souhaitez désactiver l’événement sur un lien particulier ayant cette classe là (faire en sorte que le clic sur le lien ne marche qu’une seule fois par exemple), avec la méthode classique il suffit de retirer le gestionnaire d’événement basé sur le onclick du noeud en question mais avec Reglib, il faut soit faire en sorte que le noeud ne respecte plus la règle placée sur le body (on lui retire sa classe “maClasse” mais elle est peut-être nécessaire pour le design ou pour d’autres événements) soit ajouter une information au noeud pour que le gestionnaire d’événement ne s’exécute pas.

Quoiqu’il en soit ce mécanisme de gestion des événements est très prometteur et on peut supposer que les grandes librairies JavaScript vont rapidement proposer des fonctions pour utiliser ce système.

Une petite demo comparant la gestion d’un widget entre jQuery et Reglib.

Dans le cadre de la conférence “Web Directions South 2008″ ayant eut lieu à Sydney fin Septembre, Cameron Adams a réalisé un simulateur de batterie pour étayer sa présentation et le résultat est assez sympathique.

Le résultat est visible ici : JS-909.

Côté technique, la prouesse vient du fait qu’il n’utilise aucune librairie ni aucun code flash : les sons sont situés à la fin du body dans des objets embed et leur exécution est effectuée via l’interface JavaScript de Quicktime (il est donc nécessaire d’avoir Quicktime d’installé pour que cela fonctionne).

L’intérêt reste limité car à partir d’un certain nombre de sons le moteur JavaScript commence à peiner mais le résultat reste néanmoins surprenant…

Ce phénomène se présente lors d’une mauvaise utilisation des styles sur les événements de type onMouseOver, par exemple lorsque vous réduisez la taille d’un élément au moment ou vous le survolez avec la souris : au moment où la souris passe au-dessus de l’objet, sa taille va réduire si bien que la souris peut potentiellement ne plus être au-dessus de l’élément donc celui-ci va reprendre sa taille initiale. Mais au moment où il reprend sa taille initiale, la souris se retrouve de nouveau au-dessus donc il va de nouveau être réduit. Bref on va assister à un effet de clignotement très désagréable.

Un exemple concret réalisé par CSS-Tricks : Jitter-Man ! Pour constater le phénomène, il suffit de vous rapprocher du bord du cadre rouge de Jitter-Man…

Quelques effets qui peuvent provoquer ce phénomène :

• l’ajout ou le retrait de gras
• les modifications sur les margin ou le padding
• les modifications sur la taille des bordures
• les modifications sur la hauteur ou la largeur
• les modifications sur la hauteur de ligne

Bref, l’essentiel est de faire attention et de placer l’événement onMouseOver sur quelque chose qui ne va pas voir ses dimensions être modifiées à cause de l’effet appliqué.

Source de l’article : CSS-Tricks.

L’exemple le plus parlant pour illustrer cette opposition est la mise en place de coins arrondis sur un bloc.
Pour avoir une compatibilité entre les navigateurs, il faut mettre en place une méthode parmi la multitude des solutions qui s’offrent à nous mais quelque soit la méthode appliquée, cela reste une méthode lourde et illogique à partir du moment où une notion de design (les coins arrondis) a un impact sur le markup de la page (et encore plus si les balises html nécessaires pour les coins arrondis sont générées par du JavaScript) ainsi que sur la maintenance de la page.

D’un autre côté, la méthode dégradée élégante consiste à utiliser le potentiel des CSS 3 en appliquant les coins arrondis via les propriétés border-radius ou box-shadow. Sur les navigateurs ne gérant pas ces propriétés, notre bloc reste carré donc potentiellement moins joli. Cela dit, peut-être qu’avoir un site moins joli que chez les autres incitera les utilisateurs à se tourner vers les dernières versions de leur navigateur…

Oui, oui, je vous l’accorde, les propriétés CSS 3 ont elles aussi leurs limitations pour faire des coins arrondis : ça reste des quarts de cercle de couleur unie alors qu’avec des images placées dans les angles, on a plus de potentiel mais il ne faut pas oublier qu’il existe d’autres propriétés CSS 3 nous permettant de placer plusieurs images de fond sur un bloc donc cet argument ne tient pas.

Les navigateurs évoluent mais les web designers restent bloqués sur les mêmes techniques. Ca pour maîtriser les failles d’IE6, on peut dire qu’elles sont maîtrisées mais ce nivellement par le bas a un impact sur les performances des sites et bride leur design…

Nous allons reprendre ces méthodes une à une afin d’en lister les avantages et les inconvénients… Nous allons réutiliser l’exemple de Stoyan pour montrer la syntaxe de chaque méthode : son exemple consiste à mettre en place un héritage entre trois classes FormeGeometrique, FormeGeometrique2D et Triangle.

Cet article est divisé en de nombreuses pages, chaque page traitant une méthode d’héritage différente.

• Chaînage de prototype
• Héritage des propriétés partagées uniquement
• Utilisation d’un constructeur temporaire
• Héritage par copie de propriétés
• Copie en Surface
• Copie en profondeur
• Héritage par prototypage
• Mélange d’héritage par prototype et de copie de propriétés
• Héritage multiple
• Héritage par Parasitage
• Emprunt de constructeur
• Emprunt de constructeur et copie de son prototype
• Conclusion