Ce billet est pour moi, mais je sais que je fixe les notions beaucoup mieux quand je les écris sur ce blog. VOilà quelques notions que je ne connaissais pas au moment où on me les a deandé, et il va sans dire que je me suis sentit complètement idiot. Deuxièmement idiot quand j’ai compris à quoi elles renvoyaient, puisque ces notions sont assez basiques en terme de développement.

Bref, je recopie ici ces notions, afin de contribuer à ne pas me faire avoir une seconde fois.  

Polymorphisme

[Wikipedia] En informatique, le polymorphisme est l’idée d’autoriser le même code à être utilisé avec différents types, ce qui permet des implémentations plus abstraites et générales.

Intérêt du Polymorphisme

En proposant d’utiliser un même nom de méthode pour plusieurs types d’objets différents, le polymorphisme permet une programmation beaucoup plus générique. Le développeur n’a pas à savoir, lorsqu’il programme une méthode, le type précis de l’objet sur lequel la méthode va s’appliquer. Il lui suffit de savoir que cet objet implémentera la méthode.

Ainsi, un logiciel de calcul d’intérêt pour des comptes bancaires se présenterait de la façon suivante en programmation classique (pseudo code):

case MonCompteBancaire
 PEA : MonCompteBancaire.calculeInteretPEA
 PEL : MonCompteBancaire.calculeInteretPEL
 LivretA : MonCompteBancaire.calculeInteretLivretA
end case

Si un nouveau type de compte bancaire PERP apparait (et avec lui un nouveau calcul), il sera nécessaire d’une part d’écrire la nouvelle méthode calculeInteretPERP, mais aussi de modifier tous les appels du calcul ci-dessus. Dans le meilleur des cas, celui-ci sera isolé et mutualisé de sorte qu’une seule modification sera nécessaire. Dans le pire des cas, il peut y avoir des centaines d’appels à modifier.

Avec le polymorphisme, toutes les méthodes porteront le même nom « calculInteret » mais auront des codes différents (un par type de compte). L’appel sera de la forme :

MonCompteBancaire.calculeInteret

Lors de l’arrivée du nouveau compte, aucune modification de ce code ne sera nécessaire. Le choix de la méthode réelle à utiliser sera fait automatiquement à l’exécution par le langage, alors que dans le cas précédent c’est le développeur qui devait programmer ce choix.

Encapsulation

[Wikipédia]

En programmation orientée objet, l’encapsulation est l’idée de protéger l’information contenue dans un objet et de ne proposer que des méthodes de manipulation de cet objet. Ainsi, les propriétés et axiomes associés aux informations contenues dans l’objet seront assurés/validés par les méthodes de l’objet et ne seront plus de la responsabilité de l’utilisateur extérieur. L’utilisateur extérieur ne pourra pas modifier directement l’information et risquer de mettre en péril les axiomes et les propriétés comportementales de l’objet.

L’objet est ainsi vu de l’extérieur comme une boîte noire ayant certaines propriétés et ayant un comportement spécifié. La manière dont ces propriétés ont été implémentées est alors cachée aux utilisateurs de la classe. On peut changer cette implémentation sans changer le comportement extérieur de l’objet. Cela permet donc de séparer la spécification du comportement d’un objet, de l’implémentation pratique de ces spécifications.

En principe, l’encapsulation permet à l’instance d’une classe d’accéder aux attributs d’une super-classe. Par contre deux instances d’une même classe ne peuvent accéder à leurs états.

L’encapsulation dans les langages

Les principes de l’encapsulation sont appliqués de manières très diverses suivant les langages. Mais on peut quand même trouver deux courants principaux.

Premièrement une application relativement stricte des principes dans les langages objet purs (pour autant que ce terme ait un sens) comme dans SmallTalk ou Eiffel. Dans ce cadre les attributs ne sont souvent disponibles qu’en lecture en général dans le programme et en écriture aussi depuis l’intérieur de la classe d’objet. On trouve ensuite différents moyens pour adapter ce cadre à des classes amies ou à des catégories et des hiérarchies d’objets.
Deuxièmement les langages tels que C++, Java, Ruby ou Python et plus généralement tous les langages influencés par la syntaxe du C++ qui a proposé trois niveaux de visibilité :

• public : les attributs dits publics sont accessibles à tous,
• protégé : les attributs dits protégés sont accessibles seulement aux classes dérivées,
• privé : les attributs privés sont accessibles seulement par l’objet lui-même.

Ce type d’encapsulation propose en fait une autre approche de l’encapsulation qui ne fait pas la distinction entre la lecture et l’écriture d’un attribut. Dans ce cadre on utilise en plus des méthodes d’accès et de modifications définies dans une des trois catégories suivant l’effet que l’on souhaite obtenir. Souvent ces deux types de méthodes sont définies en plus de l’attribut qui contient réellement la donnée.

De plus, dans ces langages, l’instance d’une classe a un accès complet à l’état d’une autre instance de la même classe. Des contraintes peuvent limiter l’accès des instances d’une classe aux attributs d’une super-classe. Enfin, des moyens autorisent certaines instances et fonctions à avoir un accès public total à d’autres instances même si elles ne sont pas de la même classe, comme c’est le cas avec les instances friend sous C++.

Process/Threads

[Wikipédia] La plupart des systèmes offrent la distinction entre processus « lourd » (tels que nous les avons décrits), qui sont a priori complètement isolés les uns des autres, et « processus légers » (threads en anglais), qui ont un espace mémoire (et d’autres ressources) en commun.

Edit : Un billet très intéresant à ce niveau également. Les connaissances informatiques de base