La dissociation est une des réponses parmi d’autres à la question de l’encapsulation (ou pas) entre le programme et la chose programmée. Contre l’ambiguïté ontologique du code vis-à-vis des données, la dissociation choisit plutôt la séparation. Dans cette stratégie de la dissociation, la relation entre code et données s’établit à partir d’une distinction par défaut des deux. Le programme délègue la gestion de la matérialité des données à un autre programme, ce qui n’empêche pas de rétablir des liens et voire même de traiter les données comme son propre code; mais la configuration par défaut est néanmoins conçu à partir d’une encapsulation qui sépare les deux. Les conséquences de cette dissociation peuvent être observées dans de nombreux objets techniques.
Dans le langage de programmation C, un programme peut appeler un autre programme et « passer » à ce deuxième programme un certain nombre de « valeurs ». Dans la programmation on appelle ces valeurs des « arguments ». Les arguments sont l’équivalent d’une information transmise à quelqu’un d’autre. Si nous disons à quelqu’un « rendez-vous demain à 12:00 devant la gare » nous avons en réalité tous les deux une connaissance de contenu du message. Si une troisième personne entend notre conversation, elle sait également l’heure et l’endroit de notre rendez-vous, et contient « en elle » cette information sans qu’il y ait perde d’information chez nous. Dans la lexique informatique, on dirait que nous avons tous les trois une « copie » de cette information. En programmation, on appelle ce transfert la « transmission d’arguments par valeur » (cf. Programmer en C++, p.30). En transmettant par valeur, un programme donne une copie des données à un autre programme. Chaque programme a ainsi sa propre copie et tourne entièrement autour de ces données. La copie des données donne une appartenance des données au programme traitant, ce qui rapproche cette logique à la bonne gestion promise par la programmation orientée-objet qui prône l’association absolue entre un programme et ses données.
Dans le langage de programmation C, un programme peut également appeler un autre programme et « référencer » une donnée sans en faire une copie. Dans ce cas donnée et programme sont traités séparément. En C cela se traduit par « la transmission d’arguments par référence » (cf. Programmer en C++, p.31). Ce serait l’équivalent d’un ami qui prête sa carte bleu à quelqu’un autre : si la deuxième personne dépense de l’argent avec cette carte, les conséquences retentissent sur le compte en banque de la première. Dans la lexique informatique, on dirait que les deux personnes font « référence » à la même chose puisque le deuxième programme ne fait pas une copie de la première et partage en réalité l’accès à la même variable. Les deux programmes manipulent le même emplacement de valeur (cf. variable). Ce partage est d’ailleurs le premier danger pointé par les critiques issues des partisans de la programmation orientée-objet : donner à deux programmes les clés des mêmes données augmente de façon exponentiel les risques de données corrompues ou des fonctions mal-adaptées au données dont elles ne pourraient plus garantir la pertinence de leurs contenus. Mais dans certains cas très précis — que l’orientée-objet ne bannît pas non plus car trop pratique — en dissociant le programme et les données on peut atteindre une gestion efficace des données nombreuses, rapides, ou « volatiles », notamment dans le cas de la vidéo ou le son. Nous argumenterons même que certaines logiques de traitement dits « temps-réel » n’auraient probablement jamais vu le jour si le langage C n’avait pas dans son architecture cette « mauvaise » gestion des données multiples, surtout en ce qui concerne les array.
Tentons justement une démonstration.
Dans le langage de programmation C, tout transfert d’un array d’un programme à un deuxième se fait non pas par copie mais par référence. Petit rappel : un array n’est rien d’autre qu’une liste de données multiples et peut être utilisé pour représenter de nombreux phénomènes. Une « chaîne » de caractères formant un texte (comme celui que vous lisez, par exemple), une liste de pixels représentant une image, ou une suite de chiffres décrivant les oscillations nécessaires pour restituer un enregistrement sonore sont tous des exemples d’arrays. Comme le langage C a été conçu à une époque où la mémoire informatique étaient beaucoup plus restreinte, et que les arrays risquaient de rapidement déborder les capacités de ces machines, les concepteurs du C ont jugé plus judicieux de ne pas transférer d’un bout de programme à l’autre la totalité du contenu d’une liste de valeurs. La mémoire peut assez facilement gérer deux copies d’une heure et d’une adresse d’un rendez-vous; par contre, la mémoire déborderait rapidement (et la machine ralentirait rapidement) si elle devait constamment faire une copie de la totalité des valeurs en pixels de la Joconde chaque fois qu’un autre programme souhaitaient analyser une partie de son contenu (par exemple, pour étudier les pixels autour de la signature). Comme un array n’est pas une valeur mais un ensemble de valeurs, pour des questions d’économie de moyens (et de spatialisation restreinte), C préfère la référencement des valeurs plutôt que leur copie.
En 1991, la société Apple a démontré pour la première fois sa bibliothèque Quicktime, qui gère des flux audiovisuels sur ordinateur. Pour gérer ce flux sans accrocs, Quicktime profitent du procédé de référencement des données en passant de bout de programme en bout de programme uniquement l’adresse des images et non pas la totalité des contenus eux-mêmes. Quicktime est de fond en comble une histoire de références autrement appelé des pointeurs. Une des premières erreurs qu’un débutant fait en créant une animation Quicktime c’est d’enregistrer non pas les données d’une animation dans un nouveau fichier, mais l’adresse de celle-ci; pensant avoir une copie, il efface ensuite l’animation originale puis découvre avec consternation que le deuxième fichier ne fait rien d’autre que de pointer vers une animation maintenant disparue. Quicktime a été programmé en langage C et consiste encore aujourd’hui en une collection de programmes pour la plupart programmés dans un langage non-orientée-objet. Quicktime n’est pas une bibliothèque orientée-objet pour la simple raison qu’un langage orientée-objet auraient privilégié la copie des valeurs plutôt leur référencement. Pendant de nombreuses années la bibliothèque native de Mac OS X (cf. Cocoa) devait passer par des Rustines pour accéder à Quicktime car les deux étaient codés avec sur deux plates-formes différentes avec des langages de programmation compatibles mais « philosophiquement » différents (C pour Quicktime, Objective-C pour Mac OS X/NeXT).
Pour gérer les stocks et flux massives des contenus audiovisuelles Quicktime fait passer alors d’un programme à l’autre uniquement l’adresse des contenus et non pas les contenus eux-mêmes (« eh! votre film est là-bas »). Cette stratégie dissocie totalement le programme des données ce qui donne une énorme avantage aujourd’hui à Apple à l’époque où les flux audiovisuelles doivent passer non pas d’un programme à l’autre mais d’une machine à l’autre à travers les réseaux wifi. Grâce à cette dissociation un même fichier vidéo peut être partagé sur de nombreux machines en même temps (cf. Apple TV). La dissociation des arrays en langage C devient même maintenant l’architecture de base pour une dissociation des données vis-à-vis leur machine traitant. Cette suite de l’histoire de Quicktime n’est plus dépendant uniquement de cette particularité du langage de programmation C, mais nous y voyons néanmoins son inspiration de départ. Quicktime existe bel et bien pour des langages de programmation avec données associées comme le Java, il n’empêche que Quicktime a été conçu à une époque ou le C était le langage de programmation dominant et il a bien profité de ses soi-disant faiblesses pour les transformer en des véritables avantages.
cf. Data Diariezzzzzz, Jitter, Image/ine, Mirror Mirror, Wooden Mirror, Urbaniser - T1, The Thousand Faces of Buddha