17.12.2012 Views

Programmation PYTHON - Zenk - Security - Repository

Programmation PYTHON - Zenk - Security - Repository

Programmation PYTHON - Zenk - Security - Repository

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

488<br />

Techniques avancées<br />

QUATRIÈME PARTIE<br />

L’objectif originel de Simula était de fournir aux chercheurs une bibliothèque de<br />

classes de simulation discrète, qui pouvait être modifiée dans des classes dérivées<br />

pour mettre au point un fonctionnement particulier.<br />

D’autres techniques complémentaires ont été introduites par la suite, dans les années<br />

soixante-dix, par des langages comme SmallTalk, qui vont influencer fortement<br />

Python, à savoir :<br />

l’héritage multiple ;<br />

les classes virtuelles pures ;<br />

les métaclasses ;<br />

le garbage collecting.<br />

Typage, classification et encapsulation<br />

La programmation orientée objet détermine que les systèmes sont définis par des<br />

entités appelées objets, et que chacun de ces objets possède des caractéristiques définies<br />

dans un type d’objet.<br />

Typage de Liskov<br />

Selon la théorie des types de Liskov, un type détermine un ensemble de caractéristiques<br />

que partageront les objets appartenant à ce type.<br />

Ces caractéristiques prennent la forme de méthodes et de valeurs pour l’objet et sont<br />

définies par une classe. Cette classe contient le code à proprement parler et tout objet<br />

de ce type est appelé instance de classe.<br />

Liskov stipule en outre qu’il est possible de créer une sous-classification par le biais<br />

de l’héritage, présenté ci-après.<br />

Enfin, cette classification introduit un mécanisme de substitution lorsque deux classes<br />

partagent des caractéristiques communes : substituer une classe par une autre sans que<br />

le code utilisateur ne soit impacté est appelé principe de substitution de Liskov.<br />

Principe de substitution de Liskov<br />

Prenons l’exemple d’une classe A, qui utilise dans sa méthode calcul(), la méthode<br />

sous_calcul() d’une classe B. Cette dépendance fonctionnelle rend A tributaire<br />

de B. B peut implémenter d’autres méthodes sans que cela ne gêne A car la seule<br />

chose qui intéresse A est la méthode sous_calcul().<br />

En d’autres termes, remplacer B par une classe C qui fournisse aussi une méthode<br />

sous_calcul() ne dérangera pas A, qui y trouve son compte.<br />

Cette dépendance peut donc être remontée dans une abstraction commune à B et C.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!