En théorie, la pratique est conforme à la théorie. En pratique... Bin en
pratique, les interventions d'urgence sur du code en prod, ça arrive.
Ok, c'est Mal(tm), ok, c'est à éviter par tous les moyens possibles,
mais bon, faut être pragmatique : ça arrive.
Bah non j'ai été sur pas mal de gros projet, des modifs dans du code en
prod non je n'ai jamais vu.
Des patchs fait rapidement sur une machine de dev oui. Mais dans ce cas
à priori pas de soucis avec l'éditeur de text ...
Et puis c'est testé tout de même un minimum. Je ne connais personne
d'assez inconscient pour ne pas faire de test sur un prog avant de le
livrer en prod.
En théorie, la pratique est conforme à la théorie. En pratique... Bin en
pratique, les interventions d'urgence sur du code en prod, ça arrive.
Ok, c'est Mal(tm), ok, c'est à éviter par tous les moyens possibles,
mais bon, faut être pragmatique : ça arrive.
Bah non j'ai été sur pas mal de gros projet, des modifs dans du code en
prod non je n'ai jamais vu.
Des patchs fait rapidement sur une machine de dev oui. Mais dans ce cas
à priori pas de soucis avec l'éditeur de text ...
Et puis c'est testé tout de même un minimum. Je ne connais personne
d'assez inconscient pour ne pas faire de test sur un prog avant de le
livrer en prod.
En théorie, la pratique est conforme à la théorie. En pratique... Bin en
pratique, les interventions d'urgence sur du code en prod, ça arrive.
Ok, c'est Mal(tm), ok, c'est à éviter par tous les moyens possibles,
mais bon, faut être pragmatique : ça arrive.
Bah non j'ai été sur pas mal de gros projet, des modifs dans du code en
prod non je n'ai jamais vu.
Des patchs fait rapidement sur une machine de dev oui. Mais dans ce cas
à priori pas de soucis avec l'éditeur de text ...
Et puis c'est testé tout de même un minimum. Je ne connais personne
d'assez inconscient pour ne pas faire de test sur un prog avant de le
livrer en prod.
Wykaaa wrote:Dans l'enseignement de l'approche objet, j'ai toujours adopté l'approche
de Grady Booch.
Le probleme c'est que cette approche est fortement correlee avec les
langages static avec single-dispatch. Dans les languages dynamiques
et/ou avec multiple-dispatch, les responsabilites sont reparties tres
differement.
C'est vrai mais en première approche, pour des novices, ceci n'est pas
très grave. Il faudra raffiner plus tard dans le cursus.
C'est ce que j'ai cru pendant 15 ans. Aujourd'hui, base sur mon
experience, je pense que les multi-methodes sont plus simple a
enseigner et a apprehender que le single dispatch pour de multiples
raisons (qu'il serait long a expliquer ici mais directement lier au
probleme de design et de ce qu'il faut faire et de ce qu'il ne faut
pas faire).
Il faut cependant endire plus si possible...
Je dis (et je décris) que les 4 concepts majeurs de l'objet sont :
- le concept d'abstraction
- le concept d'encapsulation
- le concept de modularité
Ce "concept" (qui n'en est pas un) est un terme vague (inspire de la
notion de module?) incluant l'encapsulation et la reutilisabilite qui
inclue elle-meme la composabilite.
Bien sûr que si, la modularité est un concept. Ca me fait justement
bondir, à chaque fois que j'entends des informaticiens qui disent le
contraire. Et c'est bien pour ça que la conception globale est
généralement "foirée" parce que ce concept est mal appliqué (car les
gens ne le comprennent pas)..
Dans le contexte objet, ce n'est pas un terme vague. ce qui trompe,
c'est que la modularité a plusieurs niveaux de granularité (je parle,
encore une fois, de la modularité dans le cadre de l'objet). Du plus fin
au plus grossier :
- la classe,
- le package : ensemble de classes
- le composant : ensemble de packages (dans l'approche de développement
par composants)
La encore cette definition est tres specifique. Dans mon cas, je
presente un composant comme un entite elementaire inviolable (brique
de base+encapsulation totale). Ca peut donc etre une fonction (plus
generalement une fermeture lexicale), une classe, un module, etc...- le sous-système : ensemble de composants
C'est bien ce que je pensais, vous parlez d'encapsulation... La
modularite, c'est la capacite a evolue pour satifaire un contexte
d'application (ex: par composabilite) sans etre modifier,
contrairement a l'adaptabilite qui est la meme chose mais avec la
capacite a etre modifier/adapter facilement (prevu dans le design).
Parce que beaucoup de languages proposent la notion de module, on
parle de modularite, mais le "concept" est lui-meme decomposable en
concept orthogonaux qui aident a mieux comprendre comment tout cela
s'agence.
Oui, ok. Mais tout ceci est-il utile, dès le début de la présentation de
Si l'on prend la hiérarchie IEEE, il y a d'autres groupements
intermédiaires.
Là vous mélangez beaucoup de choses. L'encapsulation est un concept à
part (on peut faire des modules où tout est visible à l'extérieur).
Et ca n'a de nom que le mot-clef module du langage.
La
composabilité est au niveau le plus fin des classes (du moins au sens ou
on entend composabilité en objet, à savoir lien de composition).
Ce qui est aussi applicable a des fonctions/closures ou meme a des
programmes (ex: philosophie de UNIX). Certe, un concept a une
semantique dependante du domaine, mais il n'y a pas de raison de le
restreindre autant. Restons simple et libre.
C'est
donc une des relations de hiérarchie. La modularité est une condition
pour la réutilisabilité
Ce n'est donc pas un concept puisqu'il peut etre decompose en...
concepts.
(au sens objet et non pas dans son sens plusancien) qui s'appuie sur les deux principes de : 1- Forte cohésion
interne d'une abstraction, 2- faible couplage entre abstraction
Ce ne sont pas des principes mais des metriques (ordinal) tres utiles
pour eviter/detecter les mauvais designs.
Non. Ce sont bien des principes
Exemple de principes (tires du LaTeX de la presentation):
Open Closed Principle:
Components should be open for extension but closed for modification
Least Knowledge Principle (Law of Demeter)
Assume and expose as little as possible about components
Liskov Substitution Principle
Subclasses should be substitutable for their base classes
Dependency Inversion Principle
Depend upon abstractions, do not depend upon concretions
Interface Segregation Principle
Few client-specific interfaces are better than one general-purpose
interface
Exemple _d'une_ metrique ordinal de la Cohesion:
Coincidental Cohesion
Components are grouped arbitrarily
Categorical Cohesion
Components are grouped because they do the same kind of things
Sequential Cohesion
Components are grouped because they operate in the same execution path
Structural Cohesion
Components are grouped because they operate on the same data
Functional Cohesion
Components are grouped because they contribute to single well-defined
task
Exemple de concepts:
Encapsulation
Ability to reduce dependencies by hiding/protecting information
begin{itemize}
item Expose (stable) interface} and abstract types
item Hide (unstable) implementation and concrete types
end{itemize}
Indirection
Ability to reach a target through a key/reference/pointer (wide sens)
Aggregation
Ability to group objects into collections
Delegation
Ability to defer/redirect/forward function dispatch
Reflection
Ability to reify meta-information
begin{itemize}
item {em Introspection}, ability to read/execute meta-data
(interpreter)
item {em Intercession}, ability to modify meta-data (run-time
optimization)
end{itemize}
Donc la Cohesion elle-meme est un concept (localite de la connaissance/
reponsabilite), mais une _forte_ cohesion comme vous le mentionez est
une metrique. Le fait est que dans ma presentation, je donne une
mesure ordinale pour les deux metriques qui semble plus pratique pour
les developpeurs que des metriques cardinales fortement correlees avec
certains langages (modele objet) et qui n'ont aucune signification
avec d'autre modele objet.
- La notion de hiérarchie : héritage, mais aussi agrégation et
composition qui sont toutes 3 des relations d'ordre strict entre
abstractions (c'est fondamental de comprendre ça pour éviter des erreurs
de conception)
Une fois exposer ces 4 concepts majeurs, j'indique, en insistant
fortement, que ce n'est qu'à la condition que ces 4 concepts soient mis
en oeuvre conjointement qu'on peut parler d'approche objet.
Interessant. Sauf que la notion de Programmation Orientee Objet n'est
pas clairement definie a ma connaissance (avec d'interminable debat
sur
le sujet).
Vous parlez de programmation OO alors que je parle d'approche OO !
Ok. Dans ce cas, tous les languages ou presque (a condition d'avoir la
notion d'inclusion de type et de pointeur) supporte l'approche OO.
C'est large! Ca inclu C, Pascal, etc...
Cette approche est parfaitement définie depuis les premiers articles de
Grady Booch en 83 (25 ans quand même !).
Et contestee/redefinie chaque annee depuis ;-)
Parce que les humains aiment bien "ergoter" et qu'ils admettent
La notion d'heritage inclue plusieurs concepts bien souventmelanges ce qui rend son enseignement difficile.
Quels sont les concepts que mélange la notion d'héritage ?
L'héritage est un sous-concept de la notion de hiérarchie entre modules,
un point c'est tout
ou est la notion de module dans les languages a prototype?
Et les langages comme Pascal ISO avait la notion de module (package).
Ou est la relation de hierarchie? La encore, c'est l'encapsulation qui
est recherchee, et elle n'a pas de relation hierarchique a priori.
Vous utiliser des termes bien plus vagues que les concepts soujacents
et dont depuis 20 ans personne n'arrivent a donner une definition
claire.
a peu pres autant que d'auteur d'ouvrage sur le sujet.
Oui mais moi je me tiens à celle de Grady Booch qui sont celles qui sont
(c'est donc une relation entre modules au même titre
que l'agrégation et la composition. Elle en a les mêmes propriétés :
c'est une relation d'ordre stricte).
L'aggregation n'est pas une relation d'ordre stricte puisqu'elle
permet les dependances cycliques. La composition oui.
Bon, j'ai été un peu rapide avec l'agrégation, je le reconnais...
Enfin, puisque vousconnaissez plus de 50 languages, vous devriez savoir que les concepts
cites ci-dessus sont aussi presents dans des languages _non_ objet
(fonctionnel ou prototype par exemple) et donc ne suffisent pas a
caracteriser un language OO.
La modularité existait avant l'objet,
Je n'ai jamais dis le contraire. C'est bien pour ca que je la definie
comme orthogonal a la notion d'objet et cela apparait clairement
lorsqu'on le decompose sur des concepts ou subtyping et polymorphisme
n'apparaissent pas. Par exemple, les langages fonctionnels permettent
d'ecrire du code beaucoup plus modulaire que les languages objet parce
qu'ils supportent la composition fonctionnelle. En revanche. il est
moins facile d'etendre les fonctions existantes (typiquement par
derivation d'interface) -- pour ce cas, je mets Haskell a part parce
que son systeme de classe permet exactement cela non pas par
derivation comme en OO mais parce qu'il permet d'avoir un modele
ouvert (specialization).
Je ne sais pas si les langages fonctionnels sont plus modulaires que les
bien sûr voir l'article de Parnasen 72 "On the Criteria To Be Used in Decomposing Systems into Modules"
(voir : http://sunnyday.mit.edu/16.355/parnas-criteria.html) mais la
modularité a été redéfinie dans le cadre de l'objet en s'appuyant sur
les principes de forte cohésion interne d'un module (il traite une seule
abstraction et cette abstraction est traitée entièrement dans le module
)
C'est effectivement un niveau de cohesion (le plus fort). Ceci-dit,
depuis d'autres choses ont ete dites dans le cadre OO, dont
R.C. Martin
Design Principles and Design Patterns
ObjectMentor (http://www.objectmentor.com), 2000.
J. Bloch
How to Design a Good API and Why it Matters
LCSD'05 (http://lcsd05.cs.tamu.edu), 2005.
J. Gorman
Object-Oriented Design Principles and Metrics
ParlezUml (http://www.parlezuml.com), 2006.
Je connais toutes ces choses qui sont souvent des redites (autrement) de
et le faible couplage (minimiser les dépendances entre modules et
encapsuler les détails non nécessaires à leur utilisation).
Encore une fois, je ne cherche pas à caractériser un langage de
programmation OO mais l'approche OO (ceci est moins difficile).
Je ne tiens pas à rentrer dans la querelle des langages OO ou pas OO
(qui est sans fin et n'apporte rien)
C'est bien ce que je dis depuis le debut...Ce qui _pourrait_ caracteriser un language OO, c'est subtyping +
polymorphisme (d'inclusion). Ces deux concepts sont les seuls vraiment
present dans tous les languages OO et absent dans les non OO.
Je ne parlais pas de ce qui caractérise un langage objet mais des
concepts à mettre en oeuvre pour qu'on puisse parler de véritable
approche objet (ce n'est pas du tout la même chose).
Le subtyping existe dans ADA 83 qui n'est pas objet.
Il existe aussi en C (explicit) qui n'est pas objet. C'est pour ca que
ma phrase avait "subtyping + ..."
Il y a en fait 4 sortes de polymorphismes :
- Le polymorphisme ad'hoc : la surcharge et la coercion (conversion de
type)
- Le polymorphisme universel qui se subdivise en polymorphisme
paramétrique (comme dans ML, par exemple) et en polymorphisme d'héritage
(qui est effectivement appelé, quelques fois, polymorphisme d'inclusion)
Cf lucacardelli.name/Papers/OnUnderstanding.A4.pdf (le fameux article de
Cardelli et Wegner : "On Understanding Types, Data Abstraction, and
Polymorphism" qui est ce que je connais de mieux sur le sujet)
Je connais. Et d'ailleurs il fait parti des classifications avec
lesquelles je ne suis pas tout a fait d'accord. En parti parce qu'il
melange polymorphisme de type (que j'appelle directe) et polymorphism
de fonction (indirecte=type des arguments) ce qui fait que cette
decomposition n'est pas orthogonale.
(overload) est indirecte mais aussi la redefinition (override), le
parametrique (au sens C++ ou Haskell) est en revanche directe
(polymorphisme de type). Ma decomposition (qui a aussi 4
polymorphismes) est d'avantage orthogonale et plus abstraite. Mais
elle est aussi plus simple a comprendre (d'apres les personnes qui la
rencontre) parce que non formatee pour certains langages.
Par exemple, quel est la nature du (des) polymorphisme(s) dans
template <typename T1, typename T2>
void func(T1& arg1, T2& arg2)
{
...
}
d'apres Cardelli, c'est du parametrique alors que c'est aussi (!) de
la surchage et dans certain languages ca pourrait etre aussi de la
redefinition (via l'heritage, si C++ supportait les multi-methodes
templates par ex, cf TR N2216). Bref, c'est tout a la fois selon sa
decomposition parce qu'elle n'est pas orthogonale.
Ou encore, quelle est la difference entre
struct B {
void func();
};
struct D : B {};
et
struct B {
virtual void func();
};
struct D : B {};
d'apres Cardelli?? D'ou mon attachement a separer subtyping de
polymorphisme (que je ne nomme plus d'inclusion, mais plutot lie a ses
specialisations)
Voici la mienne (so simple ;-) ):
Parametric Type
Type with definitions parametrized by types
Polymorphic Type
Type bound to several specializations
Parametric Function
Function with definitions parametrized by arguments type
Polymorphic Function
Function bound to several specializations (by arguments type)
Evidement, sorti du contexte, ca parait _trop_ simple et abstrait.
definitions sont precedees d'autres concepts associes aux types et aux
fonctions (separement). Elles sont intentionnellement decouplees de
leur utilisation (syntax) et de leur implementation. Les 's' dans les
definitions ont tous une importance (en rouge+souligne sur mon
transparent). L'avantage, c'est que les multi-methodes rentrent dans
cette decomposition (dernier cas de Type + dernier cas de Function).
Pour bien faire, il faudrait encore decomposer Parametric parce que la
parametrisation en Java et en C++ n'ont rien a voir, mais chez moi
comme chez Cardelli, c'est le meme polymorphisme (et ca me gene). Mais
comme COS ne supporte pas la parametrisation, c'est pas primordial
dans cette presentation.Après, il faut faire de nombreuses études de cas pour montrer comment,
EFFECTIVEMENT, ces 4 concepts doivent être mis en oeuvre ENSEMBLE dans
une réelle approche objet et comment ils contribuent les uns aux autres
à cette approche.
J'ai fait ca pas plus tard que la semaine derniere a des physiciens
qui
ne connaissait rien d'autre que Fortran 77 (qui sevit encore ici, he
oui...) et un peu C. Ca m'a pris 6-7 heures, dont la moitie sur
l'impact
des concepts des languages de programmations sur le design de
software.
En revanche mon approche n'est pas dans les livres (et donc discutable
a
souhait, en particulier ma classification des concepts). Neanmoins,
tout
le monde a compris en 1h a 2h (pour la partie OO).
Oui mais quelle est votre approche ?
Enoncer des concepts simples et orthogonaux mais tres abstraits.
Ensuite il est aise de re-classer les taxonomies existantes en disant
ce polymorphisme de Cardelli correspond a la combinaison de celui-ci
+celui-la.
Vous n'en dites rien alors que j'ai détaillé la mienne.
Ce qui me gêne c'est que vous vous situez toujours par rapport aux
langages de programmation OO alors que ce n'est pas mon cas.
Parce que les techniques/approches OO, c'est trop vague. Par exemple,
j'utilise en C des approches OO que tres peut de language OO me
fournissent (meta-classe, multi-methodes, delegation generique,
contrats). Pour plus de lecture, voir
http://cern.ch/laurent.deniau/html/cos-oopsla07-draft.pdf
(bien que obsolete puisque COS a ete ameliore sur bien des points
depuis et l'est encore)
Pédagogiquement parlant, je ne passe pas plus de temps sur la notion de
hiérarchie (et pas seulement l'héritage, c'est ça la clé) que sur les
autres concepts.
C'est dommage, parce que dans les languages a typage statique, la
notion
de hierarchie est intrinsequement liee a celle de couplage que l'on
cherche a eviter. Le jeux consiste donc a montrer comment reorganiser
les hierarchies pour diminuer le couplage sans rendre Liskov furieux.
Je vous reprends : "sans rendre Liskov furieuSE". j'ai assisté à un
Non, je ne parle pas de Barbara elle-meme qui n'a rien a voir avec
cette discussion en tant qu'auteur du principe, mais du principe lui-
meme "Liskov Substitution Principle" qui est inapplicable en pratique
(on commence seulement a s'en rendre compte ;-) ).
Vous voulez parler du problème du sous-typage des types récursifs ?
workshop de Barbara Liskov (auteur du langage CLU) en 85 à Berlin.
C'était extra.
Vous faites allusion au fameux principe de substitution ?
oui d'ou le masculin.
C++ utilise les templates presque partout pour resoudre ce probleme,
mais les autres languages n'ont guere le choix que d'utiliser des
interfaces (au sens Java du terme).
Mais les interfaces "à la Java" c'est très bien non ?
Oui mais c'est dynamique, les templates sont statiques (donc plus
compliques). Ce qui veut dire pour les interfaces check au runtime et
faible couplage sont au rendez-vous (comme dans les languages
dynamiques). Ce n'est pas pour rien que le JDK a ete completement
reorganise sur ce principe.J'ai vu une application de 450 mille lignes de Java qui utilisait très
proprement les interfaces. Cette application était nickel.
Mois aussi ;-) Et j'ai vu la meme chose en C qui n'etait autre que
l'implementation de la JVM elle-meme par Sun ;-)
Mais des constructeurs comme Sun ou Apple ont parfois du très joli code.
Mais la aussi, j'explique dans mon cours que les interfaces (au sens
Java) sont des artefacts necessaires pour rendre plus dynamique les
langages statiquement types. Dans les langages dynamiques (duck
typing), l'heritage a une autre signification (pas de LSP) beaucoup
plus pragmatique comme la reutilisation de code ou la classification
des types. Du coup les hierarchies de classes sont quasi inexistantes.
Fin 2007-debut 2008, nous avons eu un etudiant qui a developper en
Java tout un systeme de gestion de plug-in externe (module C, matlab
etc...) pour nos applications. C'etait tres joli, bien fait avec plein
d'interface et base en parti sur les capacites d'introspection de
Java. Comme il est question d'utiliser COS d'ici peu (cf ref ci-
dessus) qui est dynamiquement type et supporte les multi-methodes,
tout risque de partir a la poubelle parce que c'est devenu inutile.Enfin, je ne suis pas d'accord que les "vraies" bases s'expliquent en 5
minutes car moi j'y passe 3 (oui trois) jours sur les 4 concepts.
Je suis d'accord, 3-4 jours c'est ce qu'il faut pour un etudiant moyen
n'ayant aucun background sur le sujet. Ne serait-ce que pour lui
laisser
le temps de se faire a l'idee (comme pour les pointeurs). Le probleme,
c'est qu'il faut encore 1-2 ans pour savoir le mettre a profit dans
des
gros projets (design).
Hélas oui, mais il n'y a pas de mystère...
Python, OO, concepts... Rarement vu un OT pareil sur f.c.l.c
Wykaaa wrote:
Dans l'enseignement de l'approche objet, j'ai toujours adopté l'approche
de Grady Booch.
Le probleme c'est que cette approche est fortement correlee avec les
langages static avec single-dispatch. Dans les languages dynamiques
et/ou avec multiple-dispatch, les responsabilites sont reparties tres
differement.
C'est vrai mais en première approche, pour des novices, ceci n'est pas
très grave. Il faudra raffiner plus tard dans le cursus.
C'est ce que j'ai cru pendant 15 ans. Aujourd'hui, base sur mon
experience, je pense que les multi-methodes sont plus simple a
enseigner et a apprehender que le single dispatch pour de multiples
raisons (qu'il serait long a expliquer ici mais directement lier au
probleme de design et de ce qu'il faut faire et de ce qu'il ne faut
pas faire).
Il faut cependant endire plus si possible...
Je dis (et je décris) que les 4 concepts majeurs de l'objet sont :
- le concept d'abstraction
- le concept d'encapsulation
- le concept de modularité
Ce "concept" (qui n'en est pas un) est un terme vague (inspire de la
notion de module?) incluant l'encapsulation et la reutilisabilite qui
inclue elle-meme la composabilite.
Bien sûr que si, la modularité est un concept. Ca me fait justement
bondir, à chaque fois que j'entends des informaticiens qui disent le
contraire. Et c'est bien pour ça que la conception globale est
généralement "foirée" parce que ce concept est mal appliqué (car les
gens ne le comprennent pas)..
Dans le contexte objet, ce n'est pas un terme vague. ce qui trompe,
c'est que la modularité a plusieurs niveaux de granularité (je parle,
encore une fois, de la modularité dans le cadre de l'objet). Du plus fin
au plus grossier :
- la classe,
- le package : ensemble de classes
- le composant : ensemble de packages (dans l'approche de développement
par composants)
La encore cette definition est tres specifique. Dans mon cas, je
presente un composant comme un entite elementaire inviolable (brique
de base+encapsulation totale). Ca peut donc etre une fonction (plus
generalement une fermeture lexicale), une classe, un module, etc...
- le sous-système : ensemble de composants
C'est bien ce que je pensais, vous parlez d'encapsulation... La
modularite, c'est la capacite a evolue pour satifaire un contexte
d'application (ex: par composabilite) sans etre modifier,
contrairement a l'adaptabilite qui est la meme chose mais avec la
capacite a etre modifier/adapter facilement (prevu dans le design).
Parce que beaucoup de languages proposent la notion de module, on
parle de modularite, mais le "concept" est lui-meme decomposable en
concept orthogonaux qui aident a mieux comprendre comment tout cela
s'agence.
Oui, ok. Mais tout ceci est-il utile, dès le début de la présentation de
Si l'on prend la hiérarchie IEEE, il y a d'autres groupements
intermédiaires.
Là vous mélangez beaucoup de choses. L'encapsulation est un concept à
part (on peut faire des modules où tout est visible à l'extérieur).
Et ca n'a de nom que le mot-clef module du langage.
La
composabilité est au niveau le plus fin des classes (du moins au sens ou
on entend composabilité en objet, à savoir lien de composition).
Ce qui est aussi applicable a des fonctions/closures ou meme a des
programmes (ex: philosophie de UNIX). Certe, un concept a une
semantique dependante du domaine, mais il n'y a pas de raison de le
restreindre autant. Restons simple et libre.
C'est
donc une des relations de hiérarchie. La modularité est une condition
pour la réutilisabilité
Ce n'est donc pas un concept puisqu'il peut etre decompose en...
concepts.
(au sens objet et non pas dans son sens plus
ancien) qui s'appuie sur les deux principes de : 1- Forte cohésion
interne d'une abstraction, 2- faible couplage entre abstraction
Ce ne sont pas des principes mais des metriques (ordinal) tres utiles
pour eviter/detecter les mauvais designs.
Non. Ce sont bien des principes
Exemple de principes (tires du LaTeX de la presentation):
Open Closed Principle:
Components should be open for extension but closed for modification
Least Knowledge Principle (Law of Demeter)
Assume and expose as little as possible about components
Liskov Substitution Principle
Subclasses should be substitutable for their base classes
Dependency Inversion Principle
Depend upon abstractions, do not depend upon concretions
Interface Segregation Principle
Few client-specific interfaces are better than one general-purpose
interface
Exemple _d'une_ metrique ordinal de la Cohesion:
Coincidental Cohesion
Components are grouped arbitrarily
Categorical Cohesion
Components are grouped because they do the same kind of things
Sequential Cohesion
Components are grouped because they operate in the same execution path
Structural Cohesion
Components are grouped because they operate on the same data
Functional Cohesion
Components are grouped because they contribute to single well-defined
task
Exemple de concepts:
Encapsulation
Ability to reduce dependencies by hiding/protecting information
begin{itemize}
item Expose (stable) interface} and abstract types
item Hide (unstable) implementation and concrete types
end{itemize}
Indirection
Ability to reach a target through a key/reference/pointer (wide sens)
Aggregation
Ability to group objects into collections
Delegation
Ability to defer/redirect/forward function dispatch
Reflection
Ability to reify meta-information
begin{itemize}
item {em Introspection}, ability to read/execute meta-data
(interpreter)
item {em Intercession}, ability to modify meta-data (run-time
optimization)
end{itemize}
Donc la Cohesion elle-meme est un concept (localite de la connaissance/
reponsabilite), mais une _forte_ cohesion comme vous le mentionez est
une metrique. Le fait est que dans ma presentation, je donne une
mesure ordinale pour les deux metriques qui semble plus pratique pour
les developpeurs que des metriques cardinales fortement correlees avec
certains langages (modele objet) et qui n'ont aucune signification
avec d'autre modele objet.
- La notion de hiérarchie : héritage, mais aussi agrégation et
composition qui sont toutes 3 des relations d'ordre strict entre
abstractions (c'est fondamental de comprendre ça pour éviter des erreurs
de conception)
Une fois exposer ces 4 concepts majeurs, j'indique, en insistant
fortement, que ce n'est qu'à la condition que ces 4 concepts soient mis
en oeuvre conjointement qu'on peut parler d'approche objet.
Interessant. Sauf que la notion de Programmation Orientee Objet n'est
pas clairement definie a ma connaissance (avec d'interminable debat
sur
le sujet).
Vous parlez de programmation OO alors que je parle d'approche OO !
Ok. Dans ce cas, tous les languages ou presque (a condition d'avoir la
notion d'inclusion de type et de pointeur) supporte l'approche OO.
C'est large! Ca inclu C, Pascal, etc...
Cette approche est parfaitement définie depuis les premiers articles de
Grady Booch en 83 (25 ans quand même !).
Et contestee/redefinie chaque annee depuis ;-)
Parce que les humains aiment bien "ergoter" et qu'ils admettent
La notion d'heritage inclue plusieurs concepts bien souvent
melanges ce qui rend son enseignement difficile.
Quels sont les concepts que mélange la notion d'héritage ?
L'héritage est un sous-concept de la notion de hiérarchie entre modules,
un point c'est tout
ou est la notion de module dans les languages a prototype?
Et les langages comme Pascal ISO avait la notion de module (package).
Ou est la relation de hierarchie? La encore, c'est l'encapsulation qui
est recherchee, et elle n'a pas de relation hierarchique a priori.
Vous utiliser des termes bien plus vagues que les concepts soujacents
et dont depuis 20 ans personne n'arrivent a donner une definition
claire.
a peu pres autant que d'auteur d'ouvrage sur le sujet.
Oui mais moi je me tiens à celle de Grady Booch qui sont celles qui sont
(c'est donc une relation entre modules au même titre
que l'agrégation et la composition. Elle en a les mêmes propriétés :
c'est une relation d'ordre stricte).
L'aggregation n'est pas une relation d'ordre stricte puisqu'elle
permet les dependances cycliques. La composition oui.
Bon, j'ai été un peu rapide avec l'agrégation, je le reconnais...
Enfin, puisque vous
connaissez plus de 50 languages, vous devriez savoir que les concepts
cites ci-dessus sont aussi presents dans des languages _non_ objet
(fonctionnel ou prototype par exemple) et donc ne suffisent pas a
caracteriser un language OO.
La modularité existait avant l'objet,
Je n'ai jamais dis le contraire. C'est bien pour ca que je la definie
comme orthogonal a la notion d'objet et cela apparait clairement
lorsqu'on le decompose sur des concepts ou subtyping et polymorphisme
n'apparaissent pas. Par exemple, les langages fonctionnels permettent
d'ecrire du code beaucoup plus modulaire que les languages objet parce
qu'ils supportent la composition fonctionnelle. En revanche. il est
moins facile d'etendre les fonctions existantes (typiquement par
derivation d'interface) -- pour ce cas, je mets Haskell a part parce
que son systeme de classe permet exactement cela non pas par
derivation comme en OO mais parce qu'il permet d'avoir un modele
ouvert (specialization).
Je ne sais pas si les langages fonctionnels sont plus modulaires que les
bien sûr voir l'article de Parnas
en 72 "On the Criteria To Be Used in Decomposing Systems into Modules"
(voir : http://sunnyday.mit.edu/16.355/parnas-criteria.html) mais la
modularité a été redéfinie dans le cadre de l'objet en s'appuyant sur
les principes de forte cohésion interne d'un module (il traite une seule
abstraction et cette abstraction est traitée entièrement dans le module
)
C'est effectivement un niveau de cohesion (le plus fort). Ceci-dit,
depuis d'autres choses ont ete dites dans le cadre OO, dont
R.C. Martin
Design Principles and Design Patterns
ObjectMentor (http://www.objectmentor.com), 2000.
J. Bloch
How to Design a Good API and Why it Matters
LCSD'05 (http://lcsd05.cs.tamu.edu), 2005.
J. Gorman
Object-Oriented Design Principles and Metrics
ParlezUml (http://www.parlezuml.com), 2006.
Je connais toutes ces choses qui sont souvent des redites (autrement) de
et le faible couplage (minimiser les dépendances entre modules et
encapsuler les détails non nécessaires à leur utilisation).
Encore une fois, je ne cherche pas à caractériser un langage de
programmation OO mais l'approche OO (ceci est moins difficile).
Je ne tiens pas à rentrer dans la querelle des langages OO ou pas OO
(qui est sans fin et n'apporte rien)
C'est bien ce que je dis depuis le debut...
Ce qui _pourrait_ caracteriser un language OO, c'est subtyping +
polymorphisme (d'inclusion). Ces deux concepts sont les seuls vraiment
present dans tous les languages OO et absent dans les non OO.
Je ne parlais pas de ce qui caractérise un langage objet mais des
concepts à mettre en oeuvre pour qu'on puisse parler de véritable
approche objet (ce n'est pas du tout la même chose).
Le subtyping existe dans ADA 83 qui n'est pas objet.
Il existe aussi en C (explicit) qui n'est pas objet. C'est pour ca que
ma phrase avait "subtyping + ..."
Il y a en fait 4 sortes de polymorphismes :
- Le polymorphisme ad'hoc : la surcharge et la coercion (conversion de
type)
- Le polymorphisme universel qui se subdivise en polymorphisme
paramétrique (comme dans ML, par exemple) et en polymorphisme d'héritage
(qui est effectivement appelé, quelques fois, polymorphisme d'inclusion)
Cf lucacardelli.name/Papers/OnUnderstanding.A4.pdf (le fameux article de
Cardelli et Wegner : "On Understanding Types, Data Abstraction, and
Polymorphism" qui est ce que je connais de mieux sur le sujet)
Je connais. Et d'ailleurs il fait parti des classifications avec
lesquelles je ne suis pas tout a fait d'accord. En parti parce qu'il
melange polymorphisme de type (que j'appelle directe) et polymorphism
de fonction (indirecte=type des arguments) ce qui fait que cette
decomposition n'est pas orthogonale.
(overload) est indirecte mais aussi la redefinition (override), le
parametrique (au sens C++ ou Haskell) est en revanche directe
(polymorphisme de type). Ma decomposition (qui a aussi 4
polymorphismes) est d'avantage orthogonale et plus abstraite. Mais
elle est aussi plus simple a comprendre (d'apres les personnes qui la
rencontre) parce que non formatee pour certains langages.
Par exemple, quel est la nature du (des) polymorphisme(s) dans
template <typename T1, typename T2>
void func(T1& arg1, T2& arg2)
{
...
}
d'apres Cardelli, c'est du parametrique alors que c'est aussi (!) de
la surchage et dans certain languages ca pourrait etre aussi de la
redefinition (via l'heritage, si C++ supportait les multi-methodes
templates par ex, cf TR N2216). Bref, c'est tout a la fois selon sa
decomposition parce qu'elle n'est pas orthogonale.
Ou encore, quelle est la difference entre
struct B {
void func();
};
struct D : B {};
et
struct B {
virtual void func();
};
struct D : B {};
d'apres Cardelli?? D'ou mon attachement a separer subtyping de
polymorphisme (que je ne nomme plus d'inclusion, mais plutot lie a ses
specialisations)
Voici la mienne (so simple ;-) ):
Parametric Type
Type with definitions parametrized by types
Polymorphic Type
Type bound to several specializations
Parametric Function
Function with definitions parametrized by arguments type
Polymorphic Function
Function bound to several specializations (by arguments type)
Evidement, sorti du contexte, ca parait _trop_ simple et abstrait.
definitions sont precedees d'autres concepts associes aux types et aux
fonctions (separement). Elles sont intentionnellement decouplees de
leur utilisation (syntax) et de leur implementation. Les 's' dans les
definitions ont tous une importance (en rouge+souligne sur mon
transparent). L'avantage, c'est que les multi-methodes rentrent dans
cette decomposition (dernier cas de Type + dernier cas de Function).
Pour bien faire, il faudrait encore decomposer Parametric parce que la
parametrisation en Java et en C++ n'ont rien a voir, mais chez moi
comme chez Cardelli, c'est le meme polymorphisme (et ca me gene). Mais
comme COS ne supporte pas la parametrisation, c'est pas primordial
dans cette presentation.
Après, il faut faire de nombreuses études de cas pour montrer comment,
EFFECTIVEMENT, ces 4 concepts doivent être mis en oeuvre ENSEMBLE dans
une réelle approche objet et comment ils contribuent les uns aux autres
à cette approche.
J'ai fait ca pas plus tard que la semaine derniere a des physiciens
qui
ne connaissait rien d'autre que Fortran 77 (qui sevit encore ici, he
oui...) et un peu C. Ca m'a pris 6-7 heures, dont la moitie sur
l'impact
des concepts des languages de programmations sur le design de
software.
En revanche mon approche n'est pas dans les livres (et donc discutable
a
souhait, en particulier ma classification des concepts). Neanmoins,
tout
le monde a compris en 1h a 2h (pour la partie OO).
Oui mais quelle est votre approche ?
Enoncer des concepts simples et orthogonaux mais tres abstraits.
Ensuite il est aise de re-classer les taxonomies existantes en disant
ce polymorphisme de Cardelli correspond a la combinaison de celui-ci
+celui-la.
Vous n'en dites rien alors que j'ai détaillé la mienne.
Ce qui me gêne c'est que vous vous situez toujours par rapport aux
langages de programmation OO alors que ce n'est pas mon cas.
Parce que les techniques/approches OO, c'est trop vague. Par exemple,
j'utilise en C des approches OO que tres peut de language OO me
fournissent (meta-classe, multi-methodes, delegation generique,
contrats). Pour plus de lecture, voir
http://cern.ch/laurent.deniau/html/cos-oopsla07-draft.pdf
(bien que obsolete puisque COS a ete ameliore sur bien des points
depuis et l'est encore)
Pédagogiquement parlant, je ne passe pas plus de temps sur la notion de
hiérarchie (et pas seulement l'héritage, c'est ça la clé) que sur les
autres concepts.
C'est dommage, parce que dans les languages a typage statique, la
notion
de hierarchie est intrinsequement liee a celle de couplage que l'on
cherche a eviter. Le jeux consiste donc a montrer comment reorganiser
les hierarchies pour diminuer le couplage sans rendre Liskov furieux.
Je vous reprends : "sans rendre Liskov furieuSE". j'ai assisté à un
Non, je ne parle pas de Barbara elle-meme qui n'a rien a voir avec
cette discussion en tant qu'auteur du principe, mais du principe lui-
meme "Liskov Substitution Principle" qui est inapplicable en pratique
(on commence seulement a s'en rendre compte ;-) ).
Vous voulez parler du problème du sous-typage des types récursifs ?
workshop de Barbara Liskov (auteur du langage CLU) en 85 à Berlin.
C'était extra.
Vous faites allusion au fameux principe de substitution ?
oui d'ou le masculin.
C++ utilise les templates presque partout pour resoudre ce probleme,
mais les autres languages n'ont guere le choix que d'utiliser des
interfaces (au sens Java du terme).
Mais les interfaces "à la Java" c'est très bien non ?
Oui mais c'est dynamique, les templates sont statiques (donc plus
compliques). Ce qui veut dire pour les interfaces check au runtime et
faible couplage sont au rendez-vous (comme dans les languages
dynamiques). Ce n'est pas pour rien que le JDK a ete completement
reorganise sur ce principe.
J'ai vu une application de 450 mille lignes de Java qui utilisait très
proprement les interfaces. Cette application était nickel.
Mois aussi ;-) Et j'ai vu la meme chose en C qui n'etait autre que
l'implementation de la JVM elle-meme par Sun ;-)
Mais des constructeurs comme Sun ou Apple ont parfois du très joli code.
Mais la aussi, j'explique dans mon cours que les interfaces (au sens
Java) sont des artefacts necessaires pour rendre plus dynamique les
langages statiquement types. Dans les langages dynamiques (duck
typing), l'heritage a une autre signification (pas de LSP) beaucoup
plus pragmatique comme la reutilisation de code ou la classification
des types. Du coup les hierarchies de classes sont quasi inexistantes.
Fin 2007-debut 2008, nous avons eu un etudiant qui a developper en
Java tout un systeme de gestion de plug-in externe (module C, matlab
etc...) pour nos applications. C'etait tres joli, bien fait avec plein
d'interface et base en parti sur les capacites d'introspection de
Java. Comme il est question d'utiliser COS d'ici peu (cf ref ci-
dessus) qui est dynamiquement type et supporte les multi-methodes,
tout risque de partir a la poubelle parce que c'est devenu inutile.
Enfin, je ne suis pas d'accord que les "vraies" bases s'expliquent en 5
minutes car moi j'y passe 3 (oui trois) jours sur les 4 concepts.
Je suis d'accord, 3-4 jours c'est ce qu'il faut pour un etudiant moyen
n'ayant aucun background sur le sujet. Ne serait-ce que pour lui
laisser
le temps de se faire a l'idee (comme pour les pointeurs). Le probleme,
c'est qu'il faut encore 1-2 ans pour savoir le mettre a profit dans
des
gros projets (design).
Hélas oui, mais il n'y a pas de mystère...
Python, OO, concepts... Rarement vu un OT pareil sur f.c.l.c
Wykaaa wrote:Dans l'enseignement de l'approche objet, j'ai toujours adopté l'approche
de Grady Booch.
Le probleme c'est que cette approche est fortement correlee avec les
langages static avec single-dispatch. Dans les languages dynamiques
et/ou avec multiple-dispatch, les responsabilites sont reparties tres
differement.
C'est vrai mais en première approche, pour des novices, ceci n'est pas
très grave. Il faudra raffiner plus tard dans le cursus.
C'est ce que j'ai cru pendant 15 ans. Aujourd'hui, base sur mon
experience, je pense que les multi-methodes sont plus simple a
enseigner et a apprehender que le single dispatch pour de multiples
raisons (qu'il serait long a expliquer ici mais directement lier au
probleme de design et de ce qu'il faut faire et de ce qu'il ne faut
pas faire).
Il faut cependant endire plus si possible...
Je dis (et je décris) que les 4 concepts majeurs de l'objet sont :
- le concept d'abstraction
- le concept d'encapsulation
- le concept de modularité
Ce "concept" (qui n'en est pas un) est un terme vague (inspire de la
notion de module?) incluant l'encapsulation et la reutilisabilite qui
inclue elle-meme la composabilite.
Bien sûr que si, la modularité est un concept. Ca me fait justement
bondir, à chaque fois que j'entends des informaticiens qui disent le
contraire. Et c'est bien pour ça que la conception globale est
généralement "foirée" parce que ce concept est mal appliqué (car les
gens ne le comprennent pas)..
Dans le contexte objet, ce n'est pas un terme vague. ce qui trompe,
c'est que la modularité a plusieurs niveaux de granularité (je parle,
encore une fois, de la modularité dans le cadre de l'objet). Du plus fin
au plus grossier :
- la classe,
- le package : ensemble de classes
- le composant : ensemble de packages (dans l'approche de développement
par composants)
La encore cette definition est tres specifique. Dans mon cas, je
presente un composant comme un entite elementaire inviolable (brique
de base+encapsulation totale). Ca peut donc etre une fonction (plus
generalement une fermeture lexicale), une classe, un module, etc...- le sous-système : ensemble de composants
C'est bien ce que je pensais, vous parlez d'encapsulation... La
modularite, c'est la capacite a evolue pour satifaire un contexte
d'application (ex: par composabilite) sans etre modifier,
contrairement a l'adaptabilite qui est la meme chose mais avec la
capacite a etre modifier/adapter facilement (prevu dans le design).
Parce que beaucoup de languages proposent la notion de module, on
parle de modularite, mais le "concept" est lui-meme decomposable en
concept orthogonaux qui aident a mieux comprendre comment tout cela
s'agence.
Oui, ok. Mais tout ceci est-il utile, dès le début de la présentation de
Si l'on prend la hiérarchie IEEE, il y a d'autres groupements
intermédiaires.
Là vous mélangez beaucoup de choses. L'encapsulation est un concept à
part (on peut faire des modules où tout est visible à l'extérieur).
Et ca n'a de nom que le mot-clef module du langage.
La
composabilité est au niveau le plus fin des classes (du moins au sens ou
on entend composabilité en objet, à savoir lien de composition).
Ce qui est aussi applicable a des fonctions/closures ou meme a des
programmes (ex: philosophie de UNIX). Certe, un concept a une
semantique dependante du domaine, mais il n'y a pas de raison de le
restreindre autant. Restons simple et libre.
C'est
donc une des relations de hiérarchie. La modularité est une condition
pour la réutilisabilité
Ce n'est donc pas un concept puisqu'il peut etre decompose en...
concepts.
(au sens objet et non pas dans son sens plusancien) qui s'appuie sur les deux principes de : 1- Forte cohésion
interne d'une abstraction, 2- faible couplage entre abstraction
Ce ne sont pas des principes mais des metriques (ordinal) tres utiles
pour eviter/detecter les mauvais designs.
Non. Ce sont bien des principes
Exemple de principes (tires du LaTeX de la presentation):
Open Closed Principle:
Components should be open for extension but closed for modification
Least Knowledge Principle (Law of Demeter)
Assume and expose as little as possible about components
Liskov Substitution Principle
Subclasses should be substitutable for their base classes
Dependency Inversion Principle
Depend upon abstractions, do not depend upon concretions
Interface Segregation Principle
Few client-specific interfaces are better than one general-purpose
interface
Exemple _d'une_ metrique ordinal de la Cohesion:
Coincidental Cohesion
Components are grouped arbitrarily
Categorical Cohesion
Components are grouped because they do the same kind of things
Sequential Cohesion
Components are grouped because they operate in the same execution path
Structural Cohesion
Components are grouped because they operate on the same data
Functional Cohesion
Components are grouped because they contribute to single well-defined
task
Exemple de concepts:
Encapsulation
Ability to reduce dependencies by hiding/protecting information
begin{itemize}
item Expose (stable) interface} and abstract types
item Hide (unstable) implementation and concrete types
end{itemize}
Indirection
Ability to reach a target through a key/reference/pointer (wide sens)
Aggregation
Ability to group objects into collections
Delegation
Ability to defer/redirect/forward function dispatch
Reflection
Ability to reify meta-information
begin{itemize}
item {em Introspection}, ability to read/execute meta-data
(interpreter)
item {em Intercession}, ability to modify meta-data (run-time
optimization)
end{itemize}
Donc la Cohesion elle-meme est un concept (localite de la connaissance/
reponsabilite), mais une _forte_ cohesion comme vous le mentionez est
une metrique. Le fait est que dans ma presentation, je donne une
mesure ordinale pour les deux metriques qui semble plus pratique pour
les developpeurs que des metriques cardinales fortement correlees avec
certains langages (modele objet) et qui n'ont aucune signification
avec d'autre modele objet.
- La notion de hiérarchie : héritage, mais aussi agrégation et
composition qui sont toutes 3 des relations d'ordre strict entre
abstractions (c'est fondamental de comprendre ça pour éviter des erreurs
de conception)
Une fois exposer ces 4 concepts majeurs, j'indique, en insistant
fortement, que ce n'est qu'à la condition que ces 4 concepts soient mis
en oeuvre conjointement qu'on peut parler d'approche objet.
Interessant. Sauf que la notion de Programmation Orientee Objet n'est
pas clairement definie a ma connaissance (avec d'interminable debat
sur
le sujet).
Vous parlez de programmation OO alors que je parle d'approche OO !
Ok. Dans ce cas, tous les languages ou presque (a condition d'avoir la
notion d'inclusion de type et de pointeur) supporte l'approche OO.
C'est large! Ca inclu C, Pascal, etc...
Cette approche est parfaitement définie depuis les premiers articles de
Grady Booch en 83 (25 ans quand même !).
Et contestee/redefinie chaque annee depuis ;-)
Parce que les humains aiment bien "ergoter" et qu'ils admettent
La notion d'heritage inclue plusieurs concepts bien souventmelanges ce qui rend son enseignement difficile.
Quels sont les concepts que mélange la notion d'héritage ?
L'héritage est un sous-concept de la notion de hiérarchie entre modules,
un point c'est tout
ou est la notion de module dans les languages a prototype?
Et les langages comme Pascal ISO avait la notion de module (package).
Ou est la relation de hierarchie? La encore, c'est l'encapsulation qui
est recherchee, et elle n'a pas de relation hierarchique a priori.
Vous utiliser des termes bien plus vagues que les concepts soujacents
et dont depuis 20 ans personne n'arrivent a donner une definition
claire.
a peu pres autant que d'auteur d'ouvrage sur le sujet.
Oui mais moi je me tiens à celle de Grady Booch qui sont celles qui sont
(c'est donc une relation entre modules au même titre
que l'agrégation et la composition. Elle en a les mêmes propriétés :
c'est une relation d'ordre stricte).
L'aggregation n'est pas une relation d'ordre stricte puisqu'elle
permet les dependances cycliques. La composition oui.
Bon, j'ai été un peu rapide avec l'agrégation, je le reconnais...
Enfin, puisque vousconnaissez plus de 50 languages, vous devriez savoir que les concepts
cites ci-dessus sont aussi presents dans des languages _non_ objet
(fonctionnel ou prototype par exemple) et donc ne suffisent pas a
caracteriser un language OO.
La modularité existait avant l'objet,
Je n'ai jamais dis le contraire. C'est bien pour ca que je la definie
comme orthogonal a la notion d'objet et cela apparait clairement
lorsqu'on le decompose sur des concepts ou subtyping et polymorphisme
n'apparaissent pas. Par exemple, les langages fonctionnels permettent
d'ecrire du code beaucoup plus modulaire que les languages objet parce
qu'ils supportent la composition fonctionnelle. En revanche. il est
moins facile d'etendre les fonctions existantes (typiquement par
derivation d'interface) -- pour ce cas, je mets Haskell a part parce
que son systeme de classe permet exactement cela non pas par
derivation comme en OO mais parce qu'il permet d'avoir un modele
ouvert (specialization).
Je ne sais pas si les langages fonctionnels sont plus modulaires que les
bien sûr voir l'article de Parnasen 72 "On the Criteria To Be Used in Decomposing Systems into Modules"
(voir : http://sunnyday.mit.edu/16.355/parnas-criteria.html) mais la
modularité a été redéfinie dans le cadre de l'objet en s'appuyant sur
les principes de forte cohésion interne d'un module (il traite une seule
abstraction et cette abstraction est traitée entièrement dans le module
)
C'est effectivement un niveau de cohesion (le plus fort). Ceci-dit,
depuis d'autres choses ont ete dites dans le cadre OO, dont
R.C. Martin
Design Principles and Design Patterns
ObjectMentor (http://www.objectmentor.com), 2000.
J. Bloch
How to Design a Good API and Why it Matters
LCSD'05 (http://lcsd05.cs.tamu.edu), 2005.
J. Gorman
Object-Oriented Design Principles and Metrics
ParlezUml (http://www.parlezuml.com), 2006.
Je connais toutes ces choses qui sont souvent des redites (autrement) de
et le faible couplage (minimiser les dépendances entre modules et
encapsuler les détails non nécessaires à leur utilisation).
Encore une fois, je ne cherche pas à caractériser un langage de
programmation OO mais l'approche OO (ceci est moins difficile).
Je ne tiens pas à rentrer dans la querelle des langages OO ou pas OO
(qui est sans fin et n'apporte rien)
C'est bien ce que je dis depuis le debut...Ce qui _pourrait_ caracteriser un language OO, c'est subtyping +
polymorphisme (d'inclusion). Ces deux concepts sont les seuls vraiment
present dans tous les languages OO et absent dans les non OO.
Je ne parlais pas de ce qui caractérise un langage objet mais des
concepts à mettre en oeuvre pour qu'on puisse parler de véritable
approche objet (ce n'est pas du tout la même chose).
Le subtyping existe dans ADA 83 qui n'est pas objet.
Il existe aussi en C (explicit) qui n'est pas objet. C'est pour ca que
ma phrase avait "subtyping + ..."
Il y a en fait 4 sortes de polymorphismes :
- Le polymorphisme ad'hoc : la surcharge et la coercion (conversion de
type)
- Le polymorphisme universel qui se subdivise en polymorphisme
paramétrique (comme dans ML, par exemple) et en polymorphisme d'héritage
(qui est effectivement appelé, quelques fois, polymorphisme d'inclusion)
Cf lucacardelli.name/Papers/OnUnderstanding.A4.pdf (le fameux article de
Cardelli et Wegner : "On Understanding Types, Data Abstraction, and
Polymorphism" qui est ce que je connais de mieux sur le sujet)
Je connais. Et d'ailleurs il fait parti des classifications avec
lesquelles je ne suis pas tout a fait d'accord. En parti parce qu'il
melange polymorphisme de type (que j'appelle directe) et polymorphism
de fonction (indirecte=type des arguments) ce qui fait que cette
decomposition n'est pas orthogonale.
(overload) est indirecte mais aussi la redefinition (override), le
parametrique (au sens C++ ou Haskell) est en revanche directe
(polymorphisme de type). Ma decomposition (qui a aussi 4
polymorphismes) est d'avantage orthogonale et plus abstraite. Mais
elle est aussi plus simple a comprendre (d'apres les personnes qui la
rencontre) parce que non formatee pour certains langages.
Par exemple, quel est la nature du (des) polymorphisme(s) dans
template <typename T1, typename T2>
void func(T1& arg1, T2& arg2)
{
...
}
d'apres Cardelli, c'est du parametrique alors que c'est aussi (!) de
la surchage et dans certain languages ca pourrait etre aussi de la
redefinition (via l'heritage, si C++ supportait les multi-methodes
templates par ex, cf TR N2216). Bref, c'est tout a la fois selon sa
decomposition parce qu'elle n'est pas orthogonale.
Ou encore, quelle est la difference entre
struct B {
void func();
};
struct D : B {};
et
struct B {
virtual void func();
};
struct D : B {};
d'apres Cardelli?? D'ou mon attachement a separer subtyping de
polymorphisme (que je ne nomme plus d'inclusion, mais plutot lie a ses
specialisations)
Voici la mienne (so simple ;-) ):
Parametric Type
Type with definitions parametrized by types
Polymorphic Type
Type bound to several specializations
Parametric Function
Function with definitions parametrized by arguments type
Polymorphic Function
Function bound to several specializations (by arguments type)
Evidement, sorti du contexte, ca parait _trop_ simple et abstrait.
definitions sont precedees d'autres concepts associes aux types et aux
fonctions (separement). Elles sont intentionnellement decouplees de
leur utilisation (syntax) et de leur implementation. Les 's' dans les
definitions ont tous une importance (en rouge+souligne sur mon
transparent). L'avantage, c'est que les multi-methodes rentrent dans
cette decomposition (dernier cas de Type + dernier cas de Function).
Pour bien faire, il faudrait encore decomposer Parametric parce que la
parametrisation en Java et en C++ n'ont rien a voir, mais chez moi
comme chez Cardelli, c'est le meme polymorphisme (et ca me gene). Mais
comme COS ne supporte pas la parametrisation, c'est pas primordial
dans cette presentation.Après, il faut faire de nombreuses études de cas pour montrer comment,
EFFECTIVEMENT, ces 4 concepts doivent être mis en oeuvre ENSEMBLE dans
une réelle approche objet et comment ils contribuent les uns aux autres
à cette approche.
J'ai fait ca pas plus tard que la semaine derniere a des physiciens
qui
ne connaissait rien d'autre que Fortran 77 (qui sevit encore ici, he
oui...) et un peu C. Ca m'a pris 6-7 heures, dont la moitie sur
l'impact
des concepts des languages de programmations sur le design de
software.
En revanche mon approche n'est pas dans les livres (et donc discutable
a
souhait, en particulier ma classification des concepts). Neanmoins,
tout
le monde a compris en 1h a 2h (pour la partie OO).
Oui mais quelle est votre approche ?
Enoncer des concepts simples et orthogonaux mais tres abstraits.
Ensuite il est aise de re-classer les taxonomies existantes en disant
ce polymorphisme de Cardelli correspond a la combinaison de celui-ci
+celui-la.
Vous n'en dites rien alors que j'ai détaillé la mienne.
Ce qui me gêne c'est que vous vous situez toujours par rapport aux
langages de programmation OO alors que ce n'est pas mon cas.
Parce que les techniques/approches OO, c'est trop vague. Par exemple,
j'utilise en C des approches OO que tres peut de language OO me
fournissent (meta-classe, multi-methodes, delegation generique,
contrats). Pour plus de lecture, voir
http://cern.ch/laurent.deniau/html/cos-oopsla07-draft.pdf
(bien que obsolete puisque COS a ete ameliore sur bien des points
depuis et l'est encore)
Pédagogiquement parlant, je ne passe pas plus de temps sur la notion de
hiérarchie (et pas seulement l'héritage, c'est ça la clé) que sur les
autres concepts.
C'est dommage, parce que dans les languages a typage statique, la
notion
de hierarchie est intrinsequement liee a celle de couplage que l'on
cherche a eviter. Le jeux consiste donc a montrer comment reorganiser
les hierarchies pour diminuer le couplage sans rendre Liskov furieux.
Je vous reprends : "sans rendre Liskov furieuSE". j'ai assisté à un
Non, je ne parle pas de Barbara elle-meme qui n'a rien a voir avec
cette discussion en tant qu'auteur du principe, mais du principe lui-
meme "Liskov Substitution Principle" qui est inapplicable en pratique
(on commence seulement a s'en rendre compte ;-) ).
Vous voulez parler du problème du sous-typage des types récursifs ?
workshop de Barbara Liskov (auteur du langage CLU) en 85 à Berlin.
C'était extra.
Vous faites allusion au fameux principe de substitution ?
oui d'ou le masculin.
C++ utilise les templates presque partout pour resoudre ce probleme,
mais les autres languages n'ont guere le choix que d'utiliser des
interfaces (au sens Java du terme).
Mais les interfaces "à la Java" c'est très bien non ?
Oui mais c'est dynamique, les templates sont statiques (donc plus
compliques). Ce qui veut dire pour les interfaces check au runtime et
faible couplage sont au rendez-vous (comme dans les languages
dynamiques). Ce n'est pas pour rien que le JDK a ete completement
reorganise sur ce principe.J'ai vu une application de 450 mille lignes de Java qui utilisait très
proprement les interfaces. Cette application était nickel.
Mois aussi ;-) Et j'ai vu la meme chose en C qui n'etait autre que
l'implementation de la JVM elle-meme par Sun ;-)
Mais des constructeurs comme Sun ou Apple ont parfois du très joli code.
Mais la aussi, j'explique dans mon cours que les interfaces (au sens
Java) sont des artefacts necessaires pour rendre plus dynamique les
langages statiquement types. Dans les langages dynamiques (duck
typing), l'heritage a une autre signification (pas de LSP) beaucoup
plus pragmatique comme la reutilisation de code ou la classification
des types. Du coup les hierarchies de classes sont quasi inexistantes.
Fin 2007-debut 2008, nous avons eu un etudiant qui a developper en
Java tout un systeme de gestion de plug-in externe (module C, matlab
etc...) pour nos applications. C'etait tres joli, bien fait avec plein
d'interface et base en parti sur les capacites d'introspection de
Java. Comme il est question d'utiliser COS d'ici peu (cf ref ci-
dessus) qui est dynamiquement type et supporte les multi-methodes,
tout risque de partir a la poubelle parce que c'est devenu inutile.Enfin, je ne suis pas d'accord que les "vraies" bases s'expliquent en 5
minutes car moi j'y passe 3 (oui trois) jours sur les 4 concepts.
Je suis d'accord, 3-4 jours c'est ce qu'il faut pour un etudiant moyen
n'ayant aucun background sur le sujet. Ne serait-ce que pour lui
laisser
le temps de se faire a l'idee (comme pour les pointeurs). Le probleme,
c'est qu'il faut encore 1-2 ans pour savoir le mettre a profit dans
des
gros projets (design).
Hélas oui, mais il n'y a pas de mystère...
Python, OO, concepts... Rarement vu un OT pareil sur f.c.l.c
Parce que les humains aiment bien "ergoter" et qu'ils admettent
difficilement qu'un autre ait raison à leur place...
Mais ceci est du temps perdu.
PS : j'ai parfois, dans la discussion et principalement dans ce message,
été un peu "dur". Veuillez bien m'en excuser car comme nous nous le sommes
avoué Bruno Desthuilliers et moi-même dans nos échanges, nous sommes
parfois excessifs.
Mais après tout, n'est-ce pas l'expression de la passion pour le sujet ?
Parce que les humains aiment bien "ergoter" et qu'ils admettent
difficilement qu'un autre ait raison à leur place...
Mais ceci est du temps perdu.
PS : j'ai parfois, dans la discussion et principalement dans ce message,
été un peu "dur". Veuillez bien m'en excuser car comme nous nous le sommes
avoué Bruno Desthuilliers et moi-même dans nos échanges, nous sommes
parfois excessifs.
Mais après tout, n'est-ce pas l'expression de la passion pour le sujet ?
Parce que les humains aiment bien "ergoter" et qu'ils admettent
difficilement qu'un autre ait raison à leur place...
Mais ceci est du temps perdu.
PS : j'ai parfois, dans la discussion et principalement dans ce message,
été un peu "dur". Veuillez bien m'en excuser car comme nous nous le sommes
avoué Bruno Desthuilliers et moi-même dans nos échanges, nous sommes
parfois excessifs.
Mais après tout, n'est-ce pas l'expression de la passion pour le sujet ?
En fait, dans un langage à prototype, on a tout de même des "objets"
mais les attributs et les méthodes sont indifférenciés (slots).
En fait, dans un langage à prototype, on a tout de même des "objets"
mais les attributs et les méthodes sont indifférenciés (slots).
En fait, dans un langage à prototype, on a tout de même des "objets"
mais les attributs et les méthodes sont indifférenciés (slots).
C'est ce que j'ai cru pendant 15 ans. Aujourd'hui, base sur mon
experience, je pense que les multi-methodes sont plus simple a
enseigner et a apprehender que le single dispatch pour de multiples
raisons (qu'il serait long a expliquer ici mais directement lier au
probleme de design et de ce qu'il faut faire et de ce qu'il ne faut
pas faire).
Il faut cependant endire plus si possible...
Parce que beaucoup de languages proposent la notion de module, on
parle de modularite, mais le "concept" est lui-meme decomposable en
concept orthogonaux qui aident a mieux comprendre comment tout cela
s'agence.
Oui, ok. Mais tout ceci est-il utile, dès le début de la présentatio n de
l'approche objet ?
Là vous mélangez beaucoup de choses. L'encapsulation est un concept à
part (on peut faire des modules où tout est visible à l'extérieur) .
Et ca n'a de nom que le mot-clef module du langage.
Non car, en C par exemple, il n'y a pas de mot clé et c'est le fichier
qui fait office de module (.h et .c correspondants). Ceci pose
d'ailleurs de nombreux problèmes puisque la notion de fichier est une
notion "système" et pas "langage".
La
composabilité est au niveau le plus fin des classes (du moins au sens ou
on entend composabilité en objet, à savoir lien de composition).
Ce qui est aussi applicable a des fonctions/closures ou meme a des
programmes (ex: philosophie de UNIX). Certe, un concept a une
semantique dependante du domaine, mais il n'y a pas de raison de le
restreindre autant. Restons simple et libre.
je suis désolé mais la composabilité des fonctions et la composabili té
des modules, ce n'est pas la même chose.
La question à se poser est l'objectif des
connaissances requises pour faire de la conception et de la
programmation "propre" au sens des facteurs qualité logiciels exigés
aujourd'hui dans l'industrie et, en particulier pour l'informatique des
systèmes complexes à logiciel prépondérant où l'on manque cruel lement
de développeurs suffisamment compétents.
Alors ce que vous exposez est très bien, vous essayez d'être le plus
rigoureux possible mais je ne pense pas que tout ceci concoure à faire
des développeurs plus compétents concernant les nombreux domaines
couverts par l'ingénierie système.
Il faut des bases simples, quelques concepts clés et surtout pas des
tonnes de principes sous lesquels les débutants vont être noyés. Cec i
ou est la notion de module dans les languages a prototype?
Parlez-vous de langages à prototype comme Self ou Lisaac.
En fait, dans un langage à prototype, on a tout de même des "objets"
mais les attributs et les méthodes sont indifférenciés (slots).
Pour vous, ABCL/1 rentre-t-il dans les langages à prototype (à une
époque on parlait de langages d'acteurs).
L'aggregation n'est pas une relation d'ordre stricte puisqu'elle
permet les dependances cycliques. La composition oui.
Bon, j'ai été un peu rapide avec l'agrégation, je le reconnais...
Je ne sais pas si les langages fonctionnels sont plus modulaires que les
langages objets car ce n'est pas le même "genre" de modularité.
R.C. Martin
Design Principles and Design Patterns
ObjectMentor (http://www.objectmentor.com), 2000.
J. Bloch
How to Design a Good API and Why it Matters
LCSD'05 (http://lcsd05.cs.tamu.edu), 2005.
J. Gorman
Object-Oriented Design Principles and Metrics
ParlezUml (http://www.parlezuml.com), 2006.
Je connais toutes ces choses qui sont souvent des redites (autrement) de
choses dites depuis des lustres.
Entre nous, on ne peut pas dire que le dernier site que vous citez se
distingue par son originalité... (dans le petit document sur les
métriques, on voit celles de Halstead, très contestées et la métri que
LCOM, remaniée maintes fois elle aussi et toujours très contestable.
Le subtyping existe dans ADA 83 qui n'est pas objet.
Il existe aussi en C (explicit) qui n'est pas objet. C'est pour ca que
ma phrase avait "subtyping + ..."
Oui mais vous aviez dit que ces DEUX concepts étaient absents des
langages non OO.
Par exemple, quel est la nature du (des) polymorphisme(s) dans
template <typename T1, typename T2>
void func(T1& arg1, T2& arg2)
{
...
}
d'apres Cardelli, c'est du parametrique alors que c'est aussi (!) de
la surchage et dans certain languages ca pourrait etre aussi de la
redefinition (via l'heritage, si C++ supportait les multi-methodes
templates par ex, cf TR N2216). Bref, c'est tout a la fois selon sa
decomposition parce qu'elle n'est pas orthogonale.
On peut effectivement se poser la question, mais il me semble que, dans
ce cas, la construction est clairement paramétrique.
Voici la mienne (so simple ;-) ):
Parametric Type
Type with definitions parametrized by types
Polymorphic Type
Type bound to several specializations
Parametric Function
Function with definitions parametrized by arguments type
Polymorphic Function
Function bound to several specializations (by arguments type)
Evidement, sorti du contexte, ca parait _trop_ simple et abstrait.
Non, ça me convient.
Enoncer des concepts simples et orthogonaux mais tres abstraits.
Ensuite il est aise de re-classer les taxonomies existantes en disant
ce polymorphisme de Cardelli correspond a la combinaison de celui-ci
+celui-la.
Ce qui me gêne, pour des débutants, c'est effectivement le haut niveau
d'abstraction. Nous sommes d'accord qu'il n'y a pas (ou ne devrait pas y
avoir) de souci pour des gens aguerris.
Non, je ne parle pas de Barbara elle-meme qui n'a rien a voir avec
cette discussion en tant qu'auteur du principe, mais du principe lui-
meme "Liskov Substitution Principle" qui est inapplicable en pratique
(on commence seulement a s'en rendre compte ;-) ).
Vous voulez parler du problème du sous-typage des types récursifs ?
La théorie des types de Cook résoud le problème (typage du second
ordre). Un langage comme Eiffel permet, dans une certaine mesure le
typage du second ordre non ?
Mais des constructeurs comme Sun ou Apple ont parfois du très joli code.
J'ai vu du code C++ d'Apple, chaque "module" pouvait être donné en
exemple aux étudiants.
Python, OO, concepts... Rarement vu un OT pareil sur f.c.l.c
Et bien redynamisons ce groupe ;-)
PS : j'ai parfois, dans la discussion et principalement dans ce message,
été un peu "dur". Veuillez bien m'en excuser car comme nous nous le
sommes avoué Bruno Desthuilliers et moi-même dans nos échanges, nous
sommes parfois excessifs.
Mais après tout, n'est-ce pas l'expression de la passion pour le sujet ?
C'est ce que j'ai cru pendant 15 ans. Aujourd'hui, base sur mon
experience, je pense que les multi-methodes sont plus simple a
enseigner et a apprehender que le single dispatch pour de multiples
raisons (qu'il serait long a expliquer ici mais directement lier au
probleme de design et de ce qu'il faut faire et de ce qu'il ne faut
pas faire).
Il faut cependant endire plus si possible...
Parce que beaucoup de languages proposent la notion de module, on
parle de modularite, mais le "concept" est lui-meme decomposable en
concept orthogonaux qui aident a mieux comprendre comment tout cela
s'agence.
Oui, ok. Mais tout ceci est-il utile, dès le début de la présentatio n de
l'approche objet ?
Là vous mélangez beaucoup de choses. L'encapsulation est un concept à
part (on peut faire des modules où tout est visible à l'extérieur) .
Et ca n'a de nom que le mot-clef module du langage.
Non car, en C par exemple, il n'y a pas de mot clé et c'est le fichier
qui fait office de module (.h et .c correspondants). Ceci pose
d'ailleurs de nombreux problèmes puisque la notion de fichier est une
notion "système" et pas "langage".
La
composabilité est au niveau le plus fin des classes (du moins au sens ou
on entend composabilité en objet, à savoir lien de composition).
Ce qui est aussi applicable a des fonctions/closures ou meme a des
programmes (ex: philosophie de UNIX). Certe, un concept a une
semantique dependante du domaine, mais il n'y a pas de raison de le
restreindre autant. Restons simple et libre.
je suis désolé mais la composabilité des fonctions et la composabili té
des modules, ce n'est pas la même chose.
La question à se poser est l'objectif des
connaissances requises pour faire de la conception et de la
programmation "propre" au sens des facteurs qualité logiciels exigés
aujourd'hui dans l'industrie et, en particulier pour l'informatique des
systèmes complexes à logiciel prépondérant où l'on manque cruel lement
de développeurs suffisamment compétents.
Alors ce que vous exposez est très bien, vous essayez d'être le plus
rigoureux possible mais je ne pense pas que tout ceci concoure à faire
des développeurs plus compétents concernant les nombreux domaines
couverts par l'ingénierie système.
Il faut des bases simples, quelques concepts clés et surtout pas des
tonnes de principes sous lesquels les débutants vont être noyés. Cec i
ou est la notion de module dans les languages a prototype?
Parlez-vous de langages à prototype comme Self ou Lisaac.
En fait, dans un langage à prototype, on a tout de même des "objets"
mais les attributs et les méthodes sont indifférenciés (slots).
Pour vous, ABCL/1 rentre-t-il dans les langages à prototype (à une
époque on parlait de langages d'acteurs).
L'aggregation n'est pas une relation d'ordre stricte puisqu'elle
permet les dependances cycliques. La composition oui.
Bon, j'ai été un peu rapide avec l'agrégation, je le reconnais...
Je ne sais pas si les langages fonctionnels sont plus modulaires que les
langages objets car ce n'est pas le même "genre" de modularité.
R.C. Martin
Design Principles and Design Patterns
ObjectMentor (http://www.objectmentor.com), 2000.
J. Bloch
How to Design a Good API and Why it Matters
LCSD'05 (http://lcsd05.cs.tamu.edu), 2005.
J. Gorman
Object-Oriented Design Principles and Metrics
ParlezUml (http://www.parlezuml.com), 2006.
Je connais toutes ces choses qui sont souvent des redites (autrement) de
choses dites depuis des lustres.
Entre nous, on ne peut pas dire que le dernier site que vous citez se
distingue par son originalité... (dans le petit document sur les
métriques, on voit celles de Halstead, très contestées et la métri que
LCOM, remaniée maintes fois elle aussi et toujours très contestable.
Le subtyping existe dans ADA 83 qui n'est pas objet.
Il existe aussi en C (explicit) qui n'est pas objet. C'est pour ca que
ma phrase avait "subtyping + ..."
Oui mais vous aviez dit que ces DEUX concepts étaient absents des
langages non OO.
Par exemple, quel est la nature du (des) polymorphisme(s) dans
template <typename T1, typename T2>
void func(T1& arg1, T2& arg2)
{
...
}
d'apres Cardelli, c'est du parametrique alors que c'est aussi (!) de
la surchage et dans certain languages ca pourrait etre aussi de la
redefinition (via l'heritage, si C++ supportait les multi-methodes
templates par ex, cf TR N2216). Bref, c'est tout a la fois selon sa
decomposition parce qu'elle n'est pas orthogonale.
On peut effectivement se poser la question, mais il me semble que, dans
ce cas, la construction est clairement paramétrique.
Voici la mienne (so simple ;-) ):
Parametric Type
Type with definitions parametrized by types
Polymorphic Type
Type bound to several specializations
Parametric Function
Function with definitions parametrized by arguments type
Polymorphic Function
Function bound to several specializations (by arguments type)
Evidement, sorti du contexte, ca parait _trop_ simple et abstrait.
Non, ça me convient.
Enoncer des concepts simples et orthogonaux mais tres abstraits.
Ensuite il est aise de re-classer les taxonomies existantes en disant
ce polymorphisme de Cardelli correspond a la combinaison de celui-ci
+celui-la.
Ce qui me gêne, pour des débutants, c'est effectivement le haut niveau
d'abstraction. Nous sommes d'accord qu'il n'y a pas (ou ne devrait pas y
avoir) de souci pour des gens aguerris.
Non, je ne parle pas de Barbara elle-meme qui n'a rien a voir avec
cette discussion en tant qu'auteur du principe, mais du principe lui-
meme "Liskov Substitution Principle" qui est inapplicable en pratique
(on commence seulement a s'en rendre compte ;-) ).
Vous voulez parler du problème du sous-typage des types récursifs ?
La théorie des types de Cook résoud le problème (typage du second
ordre). Un langage comme Eiffel permet, dans une certaine mesure le
typage du second ordre non ?
Mais des constructeurs comme Sun ou Apple ont parfois du très joli code.
J'ai vu du code C++ d'Apple, chaque "module" pouvait être donné en
exemple aux étudiants.
Python, OO, concepts... Rarement vu un OT pareil sur f.c.l.c
Et bien redynamisons ce groupe ;-)
PS : j'ai parfois, dans la discussion et principalement dans ce message,
été un peu "dur". Veuillez bien m'en excuser car comme nous nous le
sommes avoué Bruno Desthuilliers et moi-même dans nos échanges, nous
sommes parfois excessifs.
Mais après tout, n'est-ce pas l'expression de la passion pour le sujet ?
C'est ce que j'ai cru pendant 15 ans. Aujourd'hui, base sur mon
experience, je pense que les multi-methodes sont plus simple a
enseigner et a apprehender que le single dispatch pour de multiples
raisons (qu'il serait long a expliquer ici mais directement lier au
probleme de design et de ce qu'il faut faire et de ce qu'il ne faut
pas faire).
Il faut cependant endire plus si possible...
Parce que beaucoup de languages proposent la notion de module, on
parle de modularite, mais le "concept" est lui-meme decomposable en
concept orthogonaux qui aident a mieux comprendre comment tout cela
s'agence.
Oui, ok. Mais tout ceci est-il utile, dès le début de la présentatio n de
l'approche objet ?
Là vous mélangez beaucoup de choses. L'encapsulation est un concept à
part (on peut faire des modules où tout est visible à l'extérieur) .
Et ca n'a de nom que le mot-clef module du langage.
Non car, en C par exemple, il n'y a pas de mot clé et c'est le fichier
qui fait office de module (.h et .c correspondants). Ceci pose
d'ailleurs de nombreux problèmes puisque la notion de fichier est une
notion "système" et pas "langage".
La
composabilité est au niveau le plus fin des classes (du moins au sens ou
on entend composabilité en objet, à savoir lien de composition).
Ce qui est aussi applicable a des fonctions/closures ou meme a des
programmes (ex: philosophie de UNIX). Certe, un concept a une
semantique dependante du domaine, mais il n'y a pas de raison de le
restreindre autant. Restons simple et libre.
je suis désolé mais la composabilité des fonctions et la composabili té
des modules, ce n'est pas la même chose.
La question à se poser est l'objectif des
connaissances requises pour faire de la conception et de la
programmation "propre" au sens des facteurs qualité logiciels exigés
aujourd'hui dans l'industrie et, en particulier pour l'informatique des
systèmes complexes à logiciel prépondérant où l'on manque cruel lement
de développeurs suffisamment compétents.
Alors ce que vous exposez est très bien, vous essayez d'être le plus
rigoureux possible mais je ne pense pas que tout ceci concoure à faire
des développeurs plus compétents concernant les nombreux domaines
couverts par l'ingénierie système.
Il faut des bases simples, quelques concepts clés et surtout pas des
tonnes de principes sous lesquels les débutants vont être noyés. Cec i
ou est la notion de module dans les languages a prototype?
Parlez-vous de langages à prototype comme Self ou Lisaac.
En fait, dans un langage à prototype, on a tout de même des "objets"
mais les attributs et les méthodes sont indifférenciés (slots).
Pour vous, ABCL/1 rentre-t-il dans les langages à prototype (à une
époque on parlait de langages d'acteurs).
L'aggregation n'est pas une relation d'ordre stricte puisqu'elle
permet les dependances cycliques. La composition oui.
Bon, j'ai été un peu rapide avec l'agrégation, je le reconnais...
Je ne sais pas si les langages fonctionnels sont plus modulaires que les
langages objets car ce n'est pas le même "genre" de modularité.
R.C. Martin
Design Principles and Design Patterns
ObjectMentor (http://www.objectmentor.com), 2000.
J. Bloch
How to Design a Good API and Why it Matters
LCSD'05 (http://lcsd05.cs.tamu.edu), 2005.
J. Gorman
Object-Oriented Design Principles and Metrics
ParlezUml (http://www.parlezuml.com), 2006.
Je connais toutes ces choses qui sont souvent des redites (autrement) de
choses dites depuis des lustres.
Entre nous, on ne peut pas dire que le dernier site que vous citez se
distingue par son originalité... (dans le petit document sur les
métriques, on voit celles de Halstead, très contestées et la métri que
LCOM, remaniée maintes fois elle aussi et toujours très contestable.
Le subtyping existe dans ADA 83 qui n'est pas objet.
Il existe aussi en C (explicit) qui n'est pas objet. C'est pour ca que
ma phrase avait "subtyping + ..."
Oui mais vous aviez dit que ces DEUX concepts étaient absents des
langages non OO.
Par exemple, quel est la nature du (des) polymorphisme(s) dans
template <typename T1, typename T2>
void func(T1& arg1, T2& arg2)
{
...
}
d'apres Cardelli, c'est du parametrique alors que c'est aussi (!) de
la surchage et dans certain languages ca pourrait etre aussi de la
redefinition (via l'heritage, si C++ supportait les multi-methodes
templates par ex, cf TR N2216). Bref, c'est tout a la fois selon sa
decomposition parce qu'elle n'est pas orthogonale.
On peut effectivement se poser la question, mais il me semble que, dans
ce cas, la construction est clairement paramétrique.
Voici la mienne (so simple ;-) ):
Parametric Type
Type with definitions parametrized by types
Polymorphic Type
Type bound to several specializations
Parametric Function
Function with definitions parametrized by arguments type
Polymorphic Function
Function bound to several specializations (by arguments type)
Evidement, sorti du contexte, ca parait _trop_ simple et abstrait.
Non, ça me convient.
Enoncer des concepts simples et orthogonaux mais tres abstraits.
Ensuite il est aise de re-classer les taxonomies existantes en disant
ce polymorphisme de Cardelli correspond a la combinaison de celui-ci
+celui-la.
Ce qui me gêne, pour des débutants, c'est effectivement le haut niveau
d'abstraction. Nous sommes d'accord qu'il n'y a pas (ou ne devrait pas y
avoir) de souci pour des gens aguerris.
Non, je ne parle pas de Barbara elle-meme qui n'a rien a voir avec
cette discussion en tant qu'auteur du principe, mais du principe lui-
meme "Liskov Substitution Principle" qui est inapplicable en pratique
(on commence seulement a s'en rendre compte ;-) ).
Vous voulez parler du problème du sous-typage des types récursifs ?
La théorie des types de Cook résoud le problème (typage du second
ordre). Un langage comme Eiffel permet, dans une certaine mesure le
typage du second ordre non ?
Mais des constructeurs comme Sun ou Apple ont parfois du très joli code.
J'ai vu du code C++ d'Apple, chaque "module" pouvait être donné en
exemple aux étudiants.
Python, OO, concepts... Rarement vu un OT pareil sur f.c.l.c
Et bien redynamisons ce groupe ;-)
PS : j'ai parfois, dans la discussion et principalement dans ce message,
été un peu "dur". Veuillez bien m'en excuser car comme nous nous le
sommes avoué Bruno Desthuilliers et moi-même dans nos échanges, nous
sommes parfois excessifs.
Mais après tout, n'est-ce pas l'expression de la passion pour le sujet ?
Wykaaa wrote:C'est ce que j'ai cru pendant 15 ans. Aujourd'hui, base sur mon
experience, je pense que les multi-methodes sont plus simple a
enseigner et a apprehender que le single dispatch pour de multiples
raisons (qu'il serait long a expliquer ici mais directement lier au
probleme de design et de ce qu'il faut faire et de ce qu'il ne faut
pas faire).
Il faut cependant endire plus si possible...
Desole, mais je vais couper pas mal la reponse parce que je n'ai pas
de temps. En revanche, je envoyer en priver les slides de la
presentation (en anglais).
La question à se poser est l'objectif des
connaissances requises pour faire de la conception et de la
programmation "propre" au sens des facteurs qualité logiciels exigés
aujourd'hui dans l'industrie et, en particulier pour l'informatique des
systèmes complexes à logiciel prépondérant où l'on manque cruellement
de développeurs suffisamment compétents.
Le probleme, c'est que le developpement logiciel devient si complique
que bientot plus personne ne sera competent a part qques genies qui ne
seront interesses que par la recherche academique.
Le but de COS est de simplifier drastiquement a la fois le design et
la programmation elle-meme, parce qu'ici, il n'y a que des physiciens,
des ingenieurs ou des etudiants dans les memes domaines pour ecrire du
soft. Et les equipes sont microscopiques (1-2 pers.) tandis que les
softs (s'ils etaient complets) depasseraient allegrement le million de
lignes de code dans un langage classique (C++, Java, etc).
L'intention est louable.
Alors ce que vous exposez est très bien, vous essayez d'être le plus
rigoureux possible mais je ne pense pas que tout ceci concoure à faire
Non, le plus simple et pragmatique possible en raison de ce que je
viens de mentionner. C'est aussi pour cela que je concois parfaitement
que mon approche est discustable et contestable, et je ne demande qu'a
la perfertionner et a la rendre rigoureuse (sans perdre en
simplicite).
des développeurs plus compétents concernant les nombreux domaines
couverts par l'ingénierie système.
Il faut des bases simples, quelques concepts clés et surtout pas des
tonnes de principes sous lesquels les débutants vont être noyés. Ceci
Les debutants aiment les recettes toutes faites.
ou est la notion de module dans les languages a prototype?
Parlez-vous de langages à prototype comme Self ou Lisaac.
oui, ou meme JavaScript.
Par exemple, quel est la nature du (des) polymorphisme(s) dans
template <typename T1, typename T2>
void func(T1& arg1, T2& arg2)
{
...
}
d'apres Cardelli, c'est du parametrique alors que c'est aussi (!) de
la surchage et dans certain languages ca pourrait etre aussi de la
redefinition (via l'heritage, si C++ supportait les multi-methodes
templates par ex, cf TR N2216). Bref, c'est tout a la fois selon sa
decomposition parce qu'elle n'est pas orthogonale.
On peut effectivement se poser la question, mais il me semble que, dans
ce cas, la construction est clairement paramétrique.
dans ce cas vous avez une collision de type des la deuxieme
specialisation. Il faut aussi au minimum la surchage.
Enoncer des concepts simples et orthogonaux mais tres abstraits.
Ensuite il est aise de re-classer les taxonomies existantes en disant
ce polymorphisme de Cardelli correspond a la combinaison de celui-ci
+celui-la.
Ce qui me gêne, pour des débutants, c'est effectivement le haut niveau
d'abstraction. Nous sommes d'accord qu'il n'y a pas (ou ne devrait pas y
avoir) de souci pour des gens aguerris.
Mais les memes etudiants sont capable d'avaler des concepts (en
topologie par ex.) autrement plus abstrait. Ce qui compte, c'est la
facon de le presenter. Il ne faut pas mystifier le concept (ce que je
vois trop souvent) mais l'expliquer.
La théorie des types de Cook résoud le problème (typage du second
ordre). Un langage comme Eiffel permet, dans une certaine mesure le
typage du second ordre non ?
Oui (si vous parler de "Current"), et c'est aussi son point faible.
Les languages fonctionnels comme Haskell (prime) vont aussi plus loin
(type Kinds, high-order types, etc), mais c'est complique avec son
lots de problemes.
Oui je voulais parler de "Current".
Mais des constructeurs comme Sun ou Apple ont parfois du très joli code.
J'ai vu du code C++ d'Apple, chaque "module" pouvait être donné en
exemple aux étudiants.
Du C++, ce doit etre recent alors (Objective-C++)? Je n'irais pas
jusqu'a dire "chaque", vu que la class-cluster String est un vrai
bord..l mais je ne peux pas nier que Objective-C m'a fortement inspire
pour COS, notament a travers la qualite de Cocoa (et Carbon).
Non, pas récent, c'était du code pour le futur système après Mac OS 9,
Cote C++, je trouve Poco tres propre aussi.
C'est une volonté affichée des développeurs de se basé sur le strict C++
Wykaaa wrote:
C'est ce que j'ai cru pendant 15 ans. Aujourd'hui, base sur mon
experience, je pense que les multi-methodes sont plus simple a
enseigner et a apprehender que le single dispatch pour de multiples
raisons (qu'il serait long a expliquer ici mais directement lier au
probleme de design et de ce qu'il faut faire et de ce qu'il ne faut
pas faire).
Il faut cependant endire plus si possible...
Desole, mais je vais couper pas mal la reponse parce que je n'ai pas
de temps. En revanche, je envoyer en priver les slides de la
presentation (en anglais).
La question à se poser est l'objectif des
connaissances requises pour faire de la conception et de la
programmation "propre" au sens des facteurs qualité logiciels exigés
aujourd'hui dans l'industrie et, en particulier pour l'informatique des
systèmes complexes à logiciel prépondérant où l'on manque cruellement
de développeurs suffisamment compétents.
Le probleme, c'est que le developpement logiciel devient si complique
que bientot plus personne ne sera competent a part qques genies qui ne
seront interesses que par la recherche academique.
Le but de COS est de simplifier drastiquement a la fois le design et
la programmation elle-meme, parce qu'ici, il n'y a que des physiciens,
des ingenieurs ou des etudiants dans les memes domaines pour ecrire du
soft. Et les equipes sont microscopiques (1-2 pers.) tandis que les
softs (s'ils etaient complets) depasseraient allegrement le million de
lignes de code dans un langage classique (C++, Java, etc).
L'intention est louable.
Alors ce que vous exposez est très bien, vous essayez d'être le plus
rigoureux possible mais je ne pense pas que tout ceci concoure à faire
Non, le plus simple et pragmatique possible en raison de ce que je
viens de mentionner. C'est aussi pour cela que je concois parfaitement
que mon approche est discustable et contestable, et je ne demande qu'a
la perfertionner et a la rendre rigoureuse (sans perdre en
simplicite).
des développeurs plus compétents concernant les nombreux domaines
couverts par l'ingénierie système.
Il faut des bases simples, quelques concepts clés et surtout pas des
tonnes de principes sous lesquels les débutants vont être noyés. Ceci
Les debutants aiment les recettes toutes faites.
ou est la notion de module dans les languages a prototype?
Parlez-vous de langages à prototype comme Self ou Lisaac.
oui, ou meme JavaScript.
Par exemple, quel est la nature du (des) polymorphisme(s) dans
template <typename T1, typename T2>
void func(T1& arg1, T2& arg2)
{
...
}
d'apres Cardelli, c'est du parametrique alors que c'est aussi (!) de
la surchage et dans certain languages ca pourrait etre aussi de la
redefinition (via l'heritage, si C++ supportait les multi-methodes
templates par ex, cf TR N2216). Bref, c'est tout a la fois selon sa
decomposition parce qu'elle n'est pas orthogonale.
On peut effectivement se poser la question, mais il me semble que, dans
ce cas, la construction est clairement paramétrique.
dans ce cas vous avez une collision de type des la deuxieme
specialisation. Il faut aussi au minimum la surchage.
Enoncer des concepts simples et orthogonaux mais tres abstraits.
Ensuite il est aise de re-classer les taxonomies existantes en disant
ce polymorphisme de Cardelli correspond a la combinaison de celui-ci
+celui-la.
Ce qui me gêne, pour des débutants, c'est effectivement le haut niveau
d'abstraction. Nous sommes d'accord qu'il n'y a pas (ou ne devrait pas y
avoir) de souci pour des gens aguerris.
Mais les memes etudiants sont capable d'avaler des concepts (en
topologie par ex.) autrement plus abstrait. Ce qui compte, c'est la
facon de le presenter. Il ne faut pas mystifier le concept (ce que je
vois trop souvent) mais l'expliquer.
La théorie des types de Cook résoud le problème (typage du second
ordre). Un langage comme Eiffel permet, dans une certaine mesure le
typage du second ordre non ?
Oui (si vous parler de "Current"), et c'est aussi son point faible.
Les languages fonctionnels comme Haskell (prime) vont aussi plus loin
(type Kinds, high-order types, etc), mais c'est complique avec son
lots de problemes.
Oui je voulais parler de "Current".
Mais des constructeurs comme Sun ou Apple ont parfois du très joli code.
J'ai vu du code C++ d'Apple, chaque "module" pouvait être donné en
exemple aux étudiants.
Du C++, ce doit etre recent alors (Objective-C++)? Je n'irais pas
jusqu'a dire "chaque", vu que la class-cluster String est un vrai
bord..l mais je ne peux pas nier que Objective-C m'a fortement inspire
pour COS, notament a travers la qualite de Cocoa (et Carbon).
Non, pas récent, c'était du code pour le futur système après Mac OS 9,
Cote C++, je trouve Poco tres propre aussi.
C'est une volonté affichée des développeurs de se basé sur le strict C++
Wykaaa wrote:C'est ce que j'ai cru pendant 15 ans. Aujourd'hui, base sur mon
experience, je pense que les multi-methodes sont plus simple a
enseigner et a apprehender que le single dispatch pour de multiples
raisons (qu'il serait long a expliquer ici mais directement lier au
probleme de design et de ce qu'il faut faire et de ce qu'il ne faut
pas faire).
Il faut cependant endire plus si possible...
Desole, mais je vais couper pas mal la reponse parce que je n'ai pas
de temps. En revanche, je envoyer en priver les slides de la
presentation (en anglais).
La question à se poser est l'objectif des
connaissances requises pour faire de la conception et de la
programmation "propre" au sens des facteurs qualité logiciels exigés
aujourd'hui dans l'industrie et, en particulier pour l'informatique des
systèmes complexes à logiciel prépondérant où l'on manque cruellement
de développeurs suffisamment compétents.
Le probleme, c'est que le developpement logiciel devient si complique
que bientot plus personne ne sera competent a part qques genies qui ne
seront interesses que par la recherche academique.
Le but de COS est de simplifier drastiquement a la fois le design et
la programmation elle-meme, parce qu'ici, il n'y a que des physiciens,
des ingenieurs ou des etudiants dans les memes domaines pour ecrire du
soft. Et les equipes sont microscopiques (1-2 pers.) tandis que les
softs (s'ils etaient complets) depasseraient allegrement le million de
lignes de code dans un langage classique (C++, Java, etc).
L'intention est louable.
Alors ce que vous exposez est très bien, vous essayez d'être le plus
rigoureux possible mais je ne pense pas que tout ceci concoure à faire
Non, le plus simple et pragmatique possible en raison de ce que je
viens de mentionner. C'est aussi pour cela que je concois parfaitement
que mon approche est discustable et contestable, et je ne demande qu'a
la perfertionner et a la rendre rigoureuse (sans perdre en
simplicite).
des développeurs plus compétents concernant les nombreux domaines
couverts par l'ingénierie système.
Il faut des bases simples, quelques concepts clés et surtout pas des
tonnes de principes sous lesquels les débutants vont être noyés. Ceci
Les debutants aiment les recettes toutes faites.
ou est la notion de module dans les languages a prototype?
Parlez-vous de langages à prototype comme Self ou Lisaac.
oui, ou meme JavaScript.
Par exemple, quel est la nature du (des) polymorphisme(s) dans
template <typename T1, typename T2>
void func(T1& arg1, T2& arg2)
{
...
}
d'apres Cardelli, c'est du parametrique alors que c'est aussi (!) de
la surchage et dans certain languages ca pourrait etre aussi de la
redefinition (via l'heritage, si C++ supportait les multi-methodes
templates par ex, cf TR N2216). Bref, c'est tout a la fois selon sa
decomposition parce qu'elle n'est pas orthogonale.
On peut effectivement se poser la question, mais il me semble que, dans
ce cas, la construction est clairement paramétrique.
dans ce cas vous avez une collision de type des la deuxieme
specialisation. Il faut aussi au minimum la surchage.
Enoncer des concepts simples et orthogonaux mais tres abstraits.
Ensuite il est aise de re-classer les taxonomies existantes en disant
ce polymorphisme de Cardelli correspond a la combinaison de celui-ci
+celui-la.
Ce qui me gêne, pour des débutants, c'est effectivement le haut niveau
d'abstraction. Nous sommes d'accord qu'il n'y a pas (ou ne devrait pas y
avoir) de souci pour des gens aguerris.
Mais les memes etudiants sont capable d'avaler des concepts (en
topologie par ex.) autrement plus abstrait. Ce qui compte, c'est la
facon de le presenter. Il ne faut pas mystifier le concept (ce que je
vois trop souvent) mais l'expliquer.
La théorie des types de Cook résoud le problème (typage du second
ordre). Un langage comme Eiffel permet, dans une certaine mesure le
typage du second ordre non ?
Oui (si vous parler de "Current"), et c'est aussi son point faible.
Les languages fonctionnels comme Haskell (prime) vont aussi plus loin
(type Kinds, high-order types, etc), mais c'est complique avec son
lots de problemes.
Oui je voulais parler de "Current".
Mais des constructeurs comme Sun ou Apple ont parfois du très joli code.
J'ai vu du code C++ d'Apple, chaque "module" pouvait être donné en
exemple aux étudiants.
Du C++, ce doit etre recent alors (Objective-C++)? Je n'irais pas
jusqu'a dire "chaque", vu que la class-cluster String est un vrai
bord..l mais je ne peux pas nier que Objective-C m'a fortement inspire
pour COS, notament a travers la qualite de Cocoa (et Carbon).
Non, pas récent, c'était du code pour le futur système après Mac OS 9,
Cote C++, je trouve Poco tres propre aussi.
C'est une volonté affichée des développeurs de se basé sur le strict C++
----- Original Message -----
From: "Wykaaa"
Newsgroups: fr.comp.lang.c
Sent: Friday, April 04, 2008 12:33 AM
Subject: Re: PythonParce que les humains aiment bien "ergoter" et qu'ils admettent
difficilement qu'un autre ait raison à leur place...
Mais ceci est du temps perdu.
Et le fait que, dans ce forum ( peut-être dans d'autres, aussi), un nouvel
arrivant, avec à l'évidence un sérieux savoir à partager, va se faire
tailler en pièces, à la place de susciter de intérêt ou de la curiosité.
PS : j'ai parfois, dans la discussion et principalement dans ce message,
été un peu "dur". Veuillez bien m'en excuser car comme nous nous le sommes
avoué Bruno Desthuilliers et moi-même dans nos échanges, nous sommes
parfois excessifs.
Mais après tout, n'est-ce pas l'expression de la passion pour le sujet ?
Ce qui est à porter à ton crédit c'est que tu es resté centré sur les
notions de fonds "techniques", ce qui n'est pas le cas d'autres
interventions.
Du moins j'ai essayé. Ta remarque me laisse penser que j'y ai réussi.
----- Original Message -----
From: "Wykaaa" <wykaaa@yahoo.fr>
Newsgroups: fr.comp.lang.c
Sent: Friday, April 04, 2008 12:33 AM
Subject: Re: Python
Parce que les humains aiment bien "ergoter" et qu'ils admettent
difficilement qu'un autre ait raison à leur place...
Mais ceci est du temps perdu.
Et le fait que, dans ce forum ( peut-être dans d'autres, aussi), un nouvel
arrivant, avec à l'évidence un sérieux savoir à partager, va se faire
tailler en pièces, à la place de susciter de intérêt ou de la curiosité.
PS : j'ai parfois, dans la discussion et principalement dans ce message,
été un peu "dur". Veuillez bien m'en excuser car comme nous nous le sommes
avoué Bruno Desthuilliers et moi-même dans nos échanges, nous sommes
parfois excessifs.
Mais après tout, n'est-ce pas l'expression de la passion pour le sujet ?
Ce qui est à porter à ton crédit c'est que tu es resté centré sur les
notions de fonds "techniques", ce qui n'est pas le cas d'autres
interventions.
Du moins j'ai essayé. Ta remarque me laisse penser que j'y ai réussi.
----- Original Message -----
From: "Wykaaa"
Newsgroups: fr.comp.lang.c
Sent: Friday, April 04, 2008 12:33 AM
Subject: Re: PythonParce que les humains aiment bien "ergoter" et qu'ils admettent
difficilement qu'un autre ait raison à leur place...
Mais ceci est du temps perdu.
Et le fait que, dans ce forum ( peut-être dans d'autres, aussi), un nouvel
arrivant, avec à l'évidence un sérieux savoir à partager, va se faire
tailler en pièces, à la place de susciter de intérêt ou de la curiosité.
PS : j'ai parfois, dans la discussion et principalement dans ce message,
été un peu "dur". Veuillez bien m'en excuser car comme nous nous le sommes
avoué Bruno Desthuilliers et moi-même dans nos échanges, nous sommes
parfois excessifs.
Mais après tout, n'est-ce pas l'expression de la passion pour le sujet ?
Ce qui est à porter à ton crédit c'est que tu es resté centré sur les
notions de fonds "techniques", ce qui n'est pas le cas d'autres
interventions.
Du moins j'ai essayé. Ta remarque me laisse penser que j'y ai réussi.
(snip)En fait, dans un langage à prototype, on a tout de même des "objets"
mais les attributs et les méthodes sont indifférenciés (slots).
Cela fait-il de Python un langage à prototype ?-)
NB : la question est un poil provo, mais vu les points communs entre les
modèles objets de javascript (désolé, c'est le seul langage à prototype
avec lequel j'ai un peu d'expérience) et de Python, elle n'est pas
forcément dénuée de fondement...
(xpost et fu2 fcl.py)
(snip)
En fait, dans un langage à prototype, on a tout de même des "objets"
mais les attributs et les méthodes sont indifférenciés (slots).
Cela fait-il de Python un langage à prototype ?-)
NB : la question est un poil provo, mais vu les points communs entre les
modèles objets de javascript (désolé, c'est le seul langage à prototype
avec lequel j'ai un peu d'expérience) et de Python, elle n'est pas
forcément dénuée de fondement...
(xpost et fu2 fcl.py)
(snip)En fait, dans un langage à prototype, on a tout de même des "objets"
mais les attributs et les méthodes sont indifférenciés (slots).
Cela fait-il de Python un langage à prototype ?-)
NB : la question est un poil provo, mais vu les points communs entre les
modèles objets de javascript (désolé, c'est le seul langage à prototype
avec lequel j'ai un peu d'expérience) et de Python, elle n'est pas
forcément dénuée de fondement...
(xpost et fu2 fcl.py)
Perso, un script très court exploité sur deux machines, [...]
D'un autre côté dans un process sérieux et normal ca n'arrive pas.
Les programmes sont livrés pour tests. Si les tests passent ils sont
installés en production. C'est tout.
S'il y a modif on reprend le process.
Perso, un script très court exploité sur deux machines, [...]
D'un autre côté dans un process sérieux et normal ca n'arrive pas.
Les programmes sont livrés pour tests. Si les tests passent ils sont
installés en production. C'est tout.
S'il y a modif on reprend le process.
Perso, un script très court exploité sur deux machines, [...]
D'un autre côté dans un process sérieux et normal ca n'arrive pas.
Les programmes sont livrés pour tests. Si les tests passent ils sont
installés en production. C'est tout.
S'il y a modif on reprend le process.
En news:, JKB va escriure:Il existe d'autres langages autrement mieux conçus. En Fortran, par
exemple [...]
DO I=1.10
envoie une fusée sur la lune...
Pour moi, la syntaxe C est aussi moisie que la
syntaxe Python sur ce point parce que d'une part un bloc peut être
implicite (if () gnagnagna;) et d'autre part parce qu'une
instruction peut être nulle (if ();).
Dame, il est clair donc que C et Python ont été conçus par des
implémenteurs, tandis que Ada (et probablement la construction IF+THEN/ENDIF
du Fortran que tu cites) ont été conçus par des comités.
En news:slrnfv6m2s.553.knatschke@fermat.systella.fr, JKB va escriure:
Il existe d'autres langages autrement mieux conçus. En Fortran, par
exemple [...]
DO I=1.10
envoie une fusée sur la lune...
Pour moi, la syntaxe C est aussi moisie que la
syntaxe Python sur ce point parce que d'une part un bloc peut être
implicite (if () gnagnagna;) et d'autre part parce qu'une
instruction peut être nulle (if ();).
Dame, il est clair donc que C et Python ont été conçus par des
implémenteurs, tandis que Ada (et probablement la construction IF+THEN/ENDIF
du Fortran que tu cites) ont été conçus par des comités.
En news:, JKB va escriure:Il existe d'autres langages autrement mieux conçus. En Fortran, par
exemple [...]
DO I=1.10
envoie une fusée sur la lune...
Pour moi, la syntaxe C est aussi moisie que la
syntaxe Python sur ce point parce que d'une part un bloc peut être
implicite (if () gnagnagna;) et d'autre part parce qu'une
instruction peut être nulle (if ();).
Dame, il est clair donc que C et Python ont été conçus par des
implémenteurs, tandis que Ada (et probablement la construction IF+THEN/ENDIF
du Fortran que tu cites) ont été conçus par des comités.