Orientés objets

Le principe des systèmes d'exploitation orientés objets est d'avoir un noyau minimum auquel viennent s'ajouter des modules gérant les fonctionnalités supplémentaires et pouvant être chargés à volonté. Du point de vue du noyau il n'y a pas vraiment de différence entre les parties du système qui lui sont extérieures et les applications qui font appel à elles et viennent donc s'y "empiler". Les modules (objets), qui contiennent chacun une certaine quantité de code et de données quelle que soit leur nature, doivent pouvoir communiquer pour utiliser les possibilités que les autres mettent à leur disposition.

L'idée est entre autre de faire des économies de place en ne recommençant pas des développements pour implémenter des fonctions similaires - au lieu de toujours compter sur l'augmentation de capacité des disques durs. Par exemple, avec l'approche classique, si vous possédez 2 traitements de texte - mettons un logiciel de courrier électronique et un intégré incluant aussi tableur, graphique, etc. - ils auront chacun leur vérificateur orthographique ayant leurs qualités et leurs défauts spécifiques. En se basant sur le principe des systèmes orientés objets, les 2 logiciels pourraient n'avoir qu'un seul correcteur orthographique commun situé dans un module à part. S'il disposait d'une interface standard celui ci pourrait être commercialisé indépendamment du traitement de texte lui-même et leurs mises à jour ne seraient plus liées. Il serait aussi possible que plusieurs sociétés fournissent des vérificateurs ayant une interface similaire et chacun serait libre de choisir le meilleur produit.

Cependant le problème de la fiabilité se présente au moment du passage d'une version d'un module à une autre. Il devient particulièrement sensible parce que ce sont tous les logiciels utilisant une fonction donnée qui sont susceptibles d'être touchés par un éventuel bug, d'où l'intérêt grandissant de mettre en place des tests exhaustifs et systématiques ainsi qu'une possibilité pour chaque utilisateur de signaler directement des problèmes rencontrés. Dans le cas de développement par une entreprise de logiciels qui lui sont propres et de leur évolution, il semble indispensable de pouvoir définir dans le système des "domaines" (utilisation courante / développement / etc.) ne pouvant pas être mélangés pour la recherche d'une fonctionnalité.