Discussion :

[davcha]

"private" est également une mesure de protection... mais c'est pour un concept OO qui est l'encapsulation.

Je ne pense pas que "sealed" protège un concept OO, ou alors je ne vois pas lequel.

Pourtant, c'est exactement les mêmes concepts OO que protègent sealed et private.

Hum... je ne connais pas assez le C# pour le dire. En quoi ca change les signatures d'ajouter sealed sur une classe ?

Pas besoin de connaître le C#, c'est la même chose qu'en Java, ici.
Si tu définis une classe Java comme étant dérivable, puis dans une version ultérieure, tu la marque comme étant final, ce caractère final est visible à l'extérieur de ton .class
Et donc, ça change la "signature", ou le contrat définit par ta classe, si tu préfères.

Oui, je suis d'accord. Les cas où j'ai réellement besoin de faire de l'héritage (au sens du liskov) sont très rares.

Donne en un exemple.

[pseudocode]

Remarque, une utilisation du seal théorique est l'interface : bloquer la fonctionnalité par l'imposition d'un contrat.

Là encore, on peut aussi poser un verrou car il n'est pas nécessairement souhaitable que l'on puisse modifier le contrat exposé.

Pour moi, l'héritage ne signifie pas "modifier" un contrat, mais l'enrichir (cf. liskov)

En poo le seal correspond au principe de fermeture, et l'abstract au principe d'ouverture. C'est une mise en pratique du design par responsabilité.

Effectivement, on doit pouvoir utiliser "seal" pour faire de l'OCP, bien que a mon avis le mécanisme private/public/héritage à largement fait ses preuves dans ce domaine. Faut que j'y reflechisse, ce n'est pas si evident que ca de trouver un exemple. D'ailleurs je remarque que personne ne m'en a encore donné.

Pour le String réponse sérieuse : pourquoi ne devrait-elle pas l'être ?
Parce que toi tu vas juger qu'il est nécessaire de pouvoir dériver tout objet "au cas où c'est nécessaire", et nous te répondrons qu'il n'est pas nécessaire d'envisager la possiblité qu'on objet puisse être dérivé de façon systèmatique.

Les deux réponses ont du sens. L'une est plus adaptée à répondre à des problèmatiques rencontrées en développement itératif, l'autre est plus adaptée à une logique de développement par la qualité de conception.

Hum... j'avoue que je ne connais pas de principes de conception/développement basé sur l'interdiction de la spécialisation. Perso, j'utilise souvent SOLID comme base de travail.

[pseudocode]

Pas besoin de connaître le C#, c'est la même chose qu'en Java, ici.
Si tu définis une classe Java comme étant dérivable, puis dans une version ultérieure, tu la marque comme étant final, ce caractère final est visible à l'extérieur de ton .class
Et donc, ça change la "signature", ou le contrat définit par ta classe, si tu préfères.

Je ne vois pas en quoi ajouter "sealed" sur une classe String ou File change son contrat = le service rendu par l'objet.

Donne en un exemple.

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class Entity {
	long uid=0;
	String name="";
	int value=0;
	// plein d'autres attributs
 
	public Entity(long uid,String name,int value) {
		this.uid=uid;
		this.name=name;
		this.value=value;
	}
 
	public long getUid() { return uid; }
	public String getName() { return name; }
	public int getValue() {	return value; }
	public void setValue(int i) { this.value = i; }
	// plein d'autre getter/setter
}

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public class ObservableEntity extends Entity {
 
	public ObservableEntity(long uid,String name,int value) {
		super(uid,name,value);
	}
 
	@Override public void setValue(int i) {
		if (i!=value) System.out.printf("value of '%s' (uid=%d) has changed from %d to %d\n",name,uid,value,i);
		super.setValue(i);
	}
}

[B.AF]

Ah oui, c'est certain que c'est un exemple de poids....

J'étais certain qu'on allait recevoir un observateur et en C#, c'est vraiment pas le meilleur exemple.

Vu qu'on pourrait le faire sans rien d'autre qu'une classe, des events et de la délégation ou une spécialisation INotifyPropertyChanged en .Net

Là tu nous montres juste un usage discutable de l'héritage qui concerne un langage.

Mais bon, depuis il y a l'IoC (event registry par exemple), et des langages un peu plus évolués.

D'ailleurs, c'est un héritage qui finalement n'a rien d'objet car il a une portée quasi inutile.

Bref, voilà ce que ça donne en C#; et franchement ça a une autre allure ???

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
 
public class Entity : INotifyPropertyChanged
    {
        private String _name = "";
        private long _uid;
        private int _value;
        // plein d'autres attributs
 
        public Entity(long uid, String name, int value)
        {
            Uid = uid;
            Name = name;
            Value = value;
        }
 
        public Entity()
        {
        }
 
        public virtual long Uid
        {
            get { return _uid; }
            set
            {
                if (value != _uid)
                {
                    _uid = value;
                    NotifyPropertyChanged("Uid");
                }
            }
        }
 
        public virtual String Name
        {
            get { return _name; }
            set
            {
                if (value != _name)
                {
                    _name = value;
                    NotifyPropertyChanged("Name");
                }
            }
        }
 
        public virtual int Value
        {
            get { return _value; }
            set
            {
                if (value != _value)
                {
                    _value = value;
                    NotifyPropertyChanged("Value");
                }
            }
        }
 
        #region INotifyPropertyChanged Members
 
        public virtual event PropertyChangedEventHandler PropertyChanged;
 
        #endregion
 
        protected void NotifyPropertyChanged(String info)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(info));
            }
        }
    }

Qui s'utilise bêtement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
    class Program
    {
        static void Main(string[] args)
        {
            Entity e = new Entity();
            e.PropertyChanged += e_PropertyChanged;
        }
 
        static void e_PropertyChanged(object sender, propertyChangedEventArgs e)
        {
            Console.WriteLine("{0} value has changed",e.PropertyName);
 
        }
    }

[davcha]

Bah, même en Java... Un observateur, tu peux le faire sans héritage de classe...

[pseudocode]

@B.AF : tu mets des NotifyProperty sur toutes tes classes, au cas où ?

Bah, même en Java... Un observateur, tu peux le faire sans héritage de classe...

Je rappelle que la question de départ ce n'était pas "comment faire pour ne pas se servir de l'héritage", mais c'était "pourquoi on m'interdit de me servir de l'héritage".

Ca me rappelle la phrase Coluche : "expliquez moi de quoi vous avez besoin, je vous expliquerai comment vous en passer"

[blbird]

Ca me rappelle la phrase Coluche : "expliquez moi de quoi vous avez besoin, je vous expliquerai comment vous en passer"

Je crois que c'est exactement ca.

Le seul cas où j'envisagerai peut-être (et encore perso je ne le ferais pas avec mes équipes de dev) d'avoir du Sealed, c'est dans le cas d'un développement d'un framework non-terminé. Et je ne l'ai jamais encore rencontré en Java.

J'ose espérer que pour une version donnée, le framework DotNet peut-être considéré comme terminé.

Encore une fois, le fait d'interdire à un développeur l'héritage d'une classe, pour le protéger, c'est inverser les responsabilités. C'est au développeur de savoir s'il se sent capable de le faire, et c'est à lui d'en prendre la responsabilité. A ce rythme, bientôt on aura plus le droit d'écrire nos propres framework ni de faire de l'héritage dans nos propres classes, trop dangereux...
Je sais que c'est typiquement le moule sociétale dans lequel on vie qui nous pousse à l'imiter dans l'idée qu'il vaut mieux interdire plutôt que de laisser les gens avoir des responsabilités, mais si on pouvait l'éviter en informatique, j'en serait reconnaissant à Microsoft.

[arflam]

La plus part d'entre vous semblent être des développeurs confirmés.

Personnellement, comme administrateur système depuis 10 ans dont 4 sous unix (et développeur du dimanche depuis ma HP48), je découvre .NET par le biais de powershell qui je dois dire est un régal. Sans vouloir troller, je le trouve largement (surtout avec la V2) plus puissant qu'un bash/ksh, notamment du fait de son orientation objet (et je n'ai ni à supporter Vi ni la gestion unix de la casse).

Évidement, pour du code évolué, j'ai été amené à m'intéresser au framework, sans parler de l'accès à la partie graphique parfois très complémentaire à l'affichage console. Du coups, j'attaque C# avec la génération WCF, WPF et Silverligth (avec sa partie serveur/déploiement).

[B.AF]

@B.AF : tu mets des NotifyProperty sur toutes tes classes, au cas où ?

Ah non : Dieux a inventé l'aop et la génération de code.
Je te donne juste un exemple de ce que les délégués peuvent apporter dans la poo en C#; INotify on pourrait s'en passer, la mécanique resterait la même et l'objet fonctionnerait de la même façon.

Donc quand tu peux penser différemment, certaines notions sont abordées différemment comme le sealed.

Quant à l'histoire des frameworks terminés en Java, ça me fait rire, il y a du final jusque dans les sources de netbeans. On peut être raisonnable et définir le seal comme un outil de conception à utiliser correctemet, et pas comme une lutte des classes du développement. Ca me paraitrait plus sain.

[OsoNet]

Salut tout le monde, premier poste tout çà, tout çà...

Désolé pour le pavé, mais fallait que çà sorte.

Concernant vos divergences sur le principe d'ouverture / fermeture; ce genre de discussion architecturale mériterait un poste à elle toute seule.

Je résumerais ma position par une seule phrase: Mieux vos une classe ouverte qu'une classe mal fermée.
Simple et concis.

Pour en revenir sur le sujet du DotNet et de son évolution, je pense que cette plateforme a très bien évoluée, mais elle n'est pas pour autant exempt de défaut, loin de là.

1°) la généricité est excellente, mais pose des problèmes de rétro compatibilité. On ressent bien que cette fonctionnalité était un manque des versions antérieures (1 et 1.1); dans l'idéal, j'aurais plus vu une interprétation de IEnumerable comme un IEnumerable(Of Object) plutot que ce qu'il se fait actuellement.
Même si l'ajout de la variance dans la version 4 réduit un peu les effets néfastes de l'implémentation tardive des génériques, on sent bien un manque de refactorisation / mise à niveau entre les versions précédentes et la version 2.0.

2°) Certaines classes du framework sont bloquées par une mauvaise utilisation du principe d'ouverture / fermeture. Ce sont, à mon avis, rarement des fermetures techniques justifiées (donc correctes), mais plutôt des fermetures marketing ou de facilité. Hors dans un framework, c'est préjudiciable aux utilisateurs de ce framework.

Exemple de ces fermetures: la gestion des types, les propriétés de dépendances (XAML, WPF et WF), property grid etc etc. Les exemples sont nombreux et ne se limitent pas à la gestion des classes "sealed". Bien souvent la fermeture est aussi gérée par le biais du modifier "Friend" en vb ou "Internal" en CS.

3°) Le modèle objet du dotnet qui est fermé et bloqué.
De plus, ce modèle objet est mélangé avec le modèle réflexif, ce qui le complexifie beaucoup trop.

4°) On est toujours au stade de promesse sur l'ouverture des compilateurs (et ce depuis le version 2.0 du dotnet)
Que ce soit une ouverture du code et/ou une ouverture par extensibilité.

5°) Les nouvelles fondations, qui, toujours de mon avis personnel, ne sont pas vraiment convaincantes, notamment WF et WPF. Beaucoup trop compliqué, trop orientée ...

6°) Certaines limites que l'on découvre en développement, qui n'ont aucune raison technique viable.
Et surtout, que l'on soit bloqué dans le contournement de ces limites (voir point 2).
Exemple de limite: Les enum (dans les génériques notamment), Les valeurs par défauts (pourquoi un champ statique en lecture seule ne peut pas agir comme une constante? limite du compilateur sur la vérification de ce champ?)

7°) L'absence d'interface implicite ou de contrat implicite.
Dans un modèle à héritage simple ou la seule alternative est l'utilisation des interfaces, et que ces interfaces sont en plus extrêmement limité, on rentre directement dans le s limites du modèle objet / modèle de typage du compilateur. En même temps, je n'ai pas d'exemple en tête d'un langage où ces interfaces implicites sont implémentés. En DotNet, çà pourrait donné par exemple
Public MyString:Implements String. L'utilité de réimplémenter la classe string n'est pas le sujet de la discussion ici, surtout qu'il ne s'agit pas d'un héritage mais d'une implémentation. Par contre, il s'agit d'une implémentation qui ne peut enfreindre les contraintes du type implémenté, ce qui entraine que MyString peut-être utilisé n'importe ou en lieu et place de String.


8°) Dans la version 4.0, l'implémentation des contrats (enfin) qui est très bien en saisie des conditions, mais plus que perfectible au niveau de la compilation. Totalement incompréhensible d'un point de vue technique surtout qu'un exemple existe déjà via le langage Eiffel.

De plus, pourquoi ces contrats n'ont-ils pas été regroupé avec la gestion des interfaces? après tout, en DotNet, les interfaces ne sont que des contrats de signatures; ils auraient pu être augmenté par des contrats type Eiffel sans que çà gêne personne.

9°) Les langages sur la plateforme dotnet ne sont pas des langages objet "pure" (et oui, toujours pas, hélas)

10°) Les langages sont sur une plateforme commune, mais ne sont pas égaux, ce qui limite fortement le côté multilangage de la plateforme. Il a été promis dans la prochaine version du dotnet que les fonctionnalités de VB et de CS soient équivalentes. Excellent, mais a quand la réunification des communautés de développeurs? Quand le choix entre VB et CS ne sera t'il qu'un choix de visualisation du code, et pas autre chose? Quand Ms arretera-t'il la politique de "diviser pour mieux regner"?
De mon avis personnel, sur cette plateforme, c'est contre productif. Vivement le jour ou un développeur CS développera en CS et le développeur VB ou autre verra et modifiera son code dans le langage qu'il aura choisit (donc vb ou autre).

Exemple: A code en CS, B regarde le code de A en VB, le modifie en VB et A voit les modifications en CS.

11°) D'une manière générale, qu'aucune facilité ne soit proposé pour toutes les sortes de modifications/extensions autre que l'héritage. Tout architecte qui se respecte sait que l'héritage n'est pas la solution miracle. Hors en dotnet, tout est fait dans le sens de l'héritage en ignorant ces défauts. Les interfaces sont limités, les extensions sont géniales, mais limitées, rien n'est proposé sur le côté relationnel (quid des opérateurs Kleene? quid des relations en tant qu'objet de premier niveau? quid de la composition?...)
Et encore plus gênant, dès qu'on envisage ces sujets, on retombe sur les limitations du modèle objet et / ou la fermeture des compilateurs.

12°) La gestion des nombres, c'est toujours du grand n'importe quoi (avis personnel inside): Byte, Int16, Int32, Int64, UInt16, UInt32, UInt64, Single, Double, Decimal, Complex....
Non mais franchement, et la simplicité ... !
INumber, Natural, Decimal pis spécialisation si on le souhaite (explicable notamment pour des raisons de performance / optimisation), ca me parait quand même plus simple, pas d'accord?


Alors, le DotNet, une merde? Oh que non, le Dotnet est génial; génial mais perfectible, et pas qu'un peu.

Linq, génial
Entity Framework, génial (pas parfait, mais génial quand même)
WCF, hallucinant (la surprise total de ma part, je m'attendais vraiment pas à çà de la part de MS)
les Lambdas, du pure bonheur
le xml compilé, excellent
et j'en passe et des meilleurs.

Donc, en résumé, MS s'améliore au fur et à mesure sur certains sujets (l'apparition et l'utilisation de plus en plus courante de Design Pattern, est loin d'être un défaut, il faut juste les utiliser a bon escient) et continue dans la mauvaise voie sur certain sujet.

A quand une plus grand ouverture ou tout simplement moins de restriction marketing pour les développeurs?

A quand un framework de GUI efficace et simple? WPF est sur la bonne voie, sauf en ce qui concerne la simplicité. Un bouton avec plus de 50 propriétés !! chercher l'erreur.
Pour moi, un bouton, c'est ... un évènement click et un caption. C'est tout. Le reste c'est des extensions, çà n'a rien à faire dans un bouton. Mais bon, c'est un autre sujet, donc pour une autre fois.

A quand la libération des langages? j'adore VB, je veux l'étendre, je dois faire un compilo complet? c'est du délire là!

etc etc

On est sur la bonne voie, mais l'évolution est trop contrôlée. Est ce la limite de MS? La suite nous le dira.

Vous l'aurez compris, j'en ai encore des pages et des pages sur le dotnet, j'adore, tout simplement.

Pour information, je suis architecte logiciel spécialisé sur la plateforme DotNet. Je développe depuis toujours; en asm, en basic en passant par le C et j'ai commencé le développement professionnel en 1997.

Voili, voilou, c'est tout pour ce soir... euh ce matin. ++

[B.AF]

Heureusement que la CLR ne fait pas que de l'objet, c'est un paradigme qui n'est pas plus valable que le fonctionnel ou le déclaratif.
D'un point de vue objet, je ne vois pas ce que tu reproche au C# : quand tu disposes d'interface, de la réflexion, de la contra/covariance, à priori, la composition est extrêment simple à mettre en place. Que serait un langage objet "pur" ? Est-ce que ça existe simplement ?

Kleene, aujourd'hui, je ne vois pas ce que ça apporterait par rapport à Linq, ou éventuellement sur F# en prog fonctionnelle, mais peut être que tu peux développer l'idée ? Ca m'intéresserait.

Quant à l'interface implicite, ça peut se gérer très facilement, mais c'est un concept que je trouve encore plus sale que l'héritage multiple du C++.
Si on ne peut pas forcer l'implémentation d'un membre, dans ce cas,autant ne pas le faire. Je trouve que ça fait partie de ces vision "au cas où ?" qui n'apportent pas grand chose.

Pour WF4, contraitement à toi, je le trouve bon et abouti, avec une bonne conception et EF reste compliqué et lourd.

Après, je crois que si tu veux étendre ton environnement, il faut que tu plonges dans la DLR et dans les DSL du SDK.

Sinon, point de vue intéressant en tous cas !

[OsoNet]

Le paradigme de développement par objet a faillit dans ces promesses. Comme beaucoup d'autre paradigme de développement avant lui... et après lui.

Depuis la création du DotNet (environ 10 ans) les connaissances à ce sujet ont évoluées, les limites/lacunes ont été montrées, étudiées, repoussées.
La littérature à ce sujet est nombreuse et je ne vais pas m'attarder sur le sujet. Juste un petit lien qui est assez explicite à mon avis : http://www.google.fr/url?sa=t&source...MNrYKQ&cad=rja

Ce que je reproche à MS sur ce paradigme, c'est d'avoir juste corrigé les défauts d'implémentation (générique, variance...) mais de ne pas avoir suivi les évolutions de ce paradigme pour réduire au maximum ces lacunes.

Certains langages vont beaucoup plus loin dans ce paradigme et dans la qualité du développement (Eiffel, notamment).
D'autres prouvent que certaines choses sont possibles alors qu'on pensait le contraire (Lisaac: prototype compilé)

En résumé, ce paradigme n'est pas fixe, beaucoup de chose reste à découvrir et à implémenter. Et je trouve qu'a ce niveau là, le DotNet ne permet pas d'expérimenter / évoluer correctement. Mais il s'agit de mon avis personnel, et donc en tant que tel, cela n'engage que moi.

Concernant les langages objets "purs", Eiffel, SmallTalk, Ruby entre autre sont réputés "purs" dans leur implémentation du paradigme object.
(un petit lien que je n'ai pas lu complètement mais qui à l'air instructif sur le sujet: http://www.jvoegele.com/software/langcomp.html)

Mode rêve On; une petite chose que j'adorerais pouvoir écrire en DotNet:

Public Structure Point
Public X as Int32 or Int64 or Decimal
Public Y as Int32 or Int64 or Decimal
End Structure

Il s'agit juste d'un exemple qui montre les limitations du typage en dotnet. A savoir que des langages existent où ce genre de chose est possible (Lisaac entre autre).

Concernant l'intérêt des opérateurs Kleene, avant tout chose, un de ces opérateurs est déjà présent en dotnet: le ? des nullables. Seulement son usage est limité au type valeur.
Dans un langage avec relations en tant qu'objet de premier niveau, ces opérateurs peuvent servir à spécifier facilement la cardinalité des relations et à améliorer la sécurité du code, toujours dans l'objectif d'un jour obtenir le rêve de tout développeur, à savoir: çà compile, çà marche. (actuellement c'est plutôt du style, çà compile, çà devrait marcher.)
Il y a beaucoup de recherche sur l'intérêt de modéliser les relations en tant qu'objet de premier niveau, dès que je retrouve des liens à ce sujet, je les ajoute.
Les opérateurs Kleene trouveraient aussi un intérêt certain pour un projet comme Irony (http://irony.codeplex.com/) par exemple.

Concernant les interfaces implicites, l'idée n'est pas de moi, mais je la trouve excellente. Voici un lien qui explique le sujet mieux que moi : http://martinfowler.com/bliki/Implic...mentation.html

Pour WF, je me suis arrêté à la première version (dotnet 3.0), je regarderai quand l'envie me prendra la dernière version pour voir si je change d'avis à son sujet.

Pour les DSL, l'idée est plutôt bonne, par contre c'est l'horreur absolue à mettre en place, le cout d'une réalisation d'un DSL pour aller jusqu'en production est absolument faramineux.

Pour finir, la DLR fait partie des bonnes choses que je n'ai pas cité.
En cherchant bien, il doit y en avoir encore des tonnes et des tonnes.

[B.AF]

En objet, je n'ai rien rencontré que je n'arrive pas à modéliser en Java ou en C#.
Ruby je tripatouille plus pour le fun, parce que c'est quand même plus du script que du dev.

Je trouve que ça fait beaucoup de reproches pour rien en fait; et je ne veux pas être désagréable : déjà il y a suffisamment pour bien faire. Et je suis partisan d'avoir la complexité la plus faible. Trop de possibilité d'implémentation a toujours maximiser le risque d'erreur (pour ceux qui aiment l'héritage multiple en C++ ;-))

[OsoNet]

B.AF, rassure toi, tu n'es pas du tout désagréable.

Pour la modélisation Objet, tout à fait d'accord avec toi.
Mais je pense qu'on peut faire mieux (plus simple surtout).

Pour la complexité la plus faible, oui et non (désolé, c'est mon côté normand). Je pense que les développeurs doivent savoir ce qu'ils font. Et que tout bloquer pour éviter qu'ils fassent des conneries n'est pas la solution. Mais dans le fond, tu as quand même raison.

Pour les reproches, oui je sais, j'ai mis un gros pavé, mais c'est parce que j'aime beaucoup le dotnet (qui aime bien châtie bien, il parait). Pis bon, j'ai aussi donné plein de bon points non?

[B.AF]

B.AF, rassure toi, tu n'es pas du tout désagréable.

Pour la modélisation Objet, tout à fait d'accord avec toi.
Mais je pense qu'on peut faire mieux (plus simple surtout).

Pour la complexité la plus faible, oui et non (désolé, c'est mon côté normand). Je pense que les développeurs doivent savoir ce qu'ils font. Et que tout bloquer pour éviter qu'ils fassent des conneries n'est pas la solution. Mais dans le fond, tu as quand même raison.

Pour les reproches, oui je sais, j'ai mis un gros pavé, mais c'est parce que j'aime beaucoup le dotnet (qui aime bien châtie bien, il parait). Pis bon, j'ai aussi donné plein de bon points non?

Oui, c'est un avis intéressant comme tous les avis étayés, après les réactions de passionnés, c'est toujours rigolo.

[cinemania]

OsoNet tu semble oublier que les développeurs sont pour une grande majorité, trop mal formés, pour savoir ce qu'ils font vraiment.

N'oublie pas non plus qu'une grande partie d'entre eux, a ce titre, mais ne le mérite pas (je pense à ceux qui ne font pas du Dev par plaisir mais juste parce qu'il faut "manger")

Parce que dans ce cas, on laisserait volontiers l'héritage multiple, et tous les inconvénients que cela engendre, si on ne sait pas clairement ce que l'on fait, et les templates à la C++ qui eux aussi sont un bon exemple de généricité tellement complexe, que la grande majorité des développeurs s'y perd et fini par écrire n'importe quoi.

On peut en dire autant du fait que tous les langages actuels font tout pour masquer les pointeurs, probablement parce que c'est une des causes majeure de bugs de la part des développeurs qui ne comprennent rien à ce qu'ils écrivent.

Pourtant dans l'absolu, ces techniques, permettent de facilité le code, et les algorithmes pour ceux qui savent les maîtriser parfaitement...
mais nous sommes tous d'accord pour dire qu'il n'en faut pas.
Il est donc assez logique qu'on verrouille certaines possibilité et ne suivent pas toujours les dernières évolutions des recherches... d'ailleurs dans ce cas tu peux critiquer java également, voir même nettement plus...

Ensuite trop se rapprocher de Ruby... On fait du dev, pas du scripting. C'est bien comme ça rapidement pour un petit truc, ou pourquoi comme support d'extension d'une application, mais pour développer un gros projet, c'est quelque part assez limite...

Pour ce qui est de tes remarques sur Eiffel, le fait est que peu importe ses possibilités, il n'en reste pas mois un langage inapte à une utilisation industrielle, car il est contreproductif, et extraordinairement trop verbeux.
Hors trop de verbosité, fini par nuire plus à la lisibilité qu'autre chose.
Ensuite vu le niveau relativement médiocre des compilateurs pour ce langage... quand tes développeurs écrive en Eiffel le code C# suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
bool ok;
if (a > 1) ok = true;
else ok = false;

ou encore

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
if (ok == true) { /* code */ }
else { /* code */ }

en C/C++ des compilateurs comme gcc/msvc font de l'optimisation post compilation qui vont supprimer ces tests inutiles, alors que if (ok) suffisait amplement... tout cela pour de la soit disant lisibilité... C# ne le fait pas dans le CIL généré, mais plus tard quand le JIT recompile en natif...
Eiffel... ne le fait pas.

Mais plus grave, de façon générale, voir ce genre de code démontre juste une faille dans la formation des développeurs. On ne leur apprend pas à coder correctement, et encore moins relire ce qu'ils ont écrit, et le comprendre.
Il en résulte un code souvent de qualité médiocre que même les compilateurs sophistiqués actuels, ne peuvent pas corriger et optimiser.
C'est pourquoi tu ne peux pas, de façon générale, tout leur donner, toutes les possibilités, nombre le ferais en guise de raccourcis sans savoir ce qu'ils code, et voyant que cela fonctionne une fois, le refaire jusqu'au jour où cela ne fonctionne plus et ... les voila incapables de dire pourquoi...
Cela je l'ai vu tellement souvent que...

Maintenant je suis d'accord pour dire qu'il manque par ci par là quelques choses, et que par exemple, taggué une classe comme sealed n'est pas toujours une bonne idée...
Mais parfois ce choix a une explication différente de l'explication marketting.
Quand on est un heureux msdn, on a accès à certaines parties du code dotnet, et on fini par ce rendre compte que certaines classes sont développées avec des raccourcis... dangereux... les taguer sealed évite qu'on les hérite et multiplie les effets de bords malheureux.
Il est vrai qu'ils ont souvent trop tendance à jouer avec le sealed toutefois, mais bon.
J'y ai déjà trouvé des intérêt dans un applicatif modulaire que j'ai fait.

Si dans les manques tu penses à ce qu'apporte les dynamic de dotnet 4... je dirais en général, que c'est une très bonne chose, mais que très vite, les développeurs fainéants qui n'en ont pas réellement besoin, vont l'utiliser et en abuser.
Hors on sais très bien que tout comme la reflexion, l'abus de cette technique plombe les performances...
Et pour avoir vu du code en pagaille je peux te dire que je ne fait pas confiance aux développeurs.
Dans le projet que je fait, je leur ai clairement proscrit l'utilisation des dynamic... parce qu'on a des contraintes de performances, et que à part dans le noyau de l'application, où certains cas sont facilités par l'utilisation de dynamic, il n'y en a nul besoin.

[OsoNet]

Salut Cinemania.

En effet, le manque de formation des développeurs est un gros problème.
C'est pour çà que je ne suis pas pour une ouverture complète ni pour une fermeture complète d'ailleurs.

Pour moi l'ouverture / fermeture est un outil architectural, pas autre chose.

Le manque de formation, je le comble au cas par cas via des formations justement, mais c'est hélas, pas toujours possible.

Pour l'héritage multiple, je suis aussi du même avis que toi.

Pour les pointeurs, beaucoup moins, je pense que les pointeurs non rien à faire dans un langage de haut niveau; par contre dans un langage de bas niveau, là rien à redire sur leur présence (au contraire, dans un langage de bas niveau, c'est une lacune de ne pas avoir de pointeur)

Pour les templates C++, là franchement, je ne saurais dire, je ne connais pas assez le C++ pour prétendre pouvoir donner un avis sur ce sujet.

Pour critiquer Java ou Ruby, même cause, même conséquence, je ne suis pas du tout expert dans ces langages donc je m'abstiens.

Pour le compilateur Eiffel +100. C'est vraiment dommage d'ailleurs. Lisaac à les mêmes symptômes; beaucoup de concept intéressants, mais syntaxe horrible, compilateur et support quasiment inexistant...
Mais bon dans ces 2 langages, c'est surtout les concepts apportés qui m'ont intéressé.

D'ailleurs, je suis super content que MS ai ajouté les contrats dans DotNet 4.0. Je me laisse rêver au jour où il implémenteront les prototypes compilés comme dans Lisaac, mais bon je m'égare.

Pour l'usage industriel d'Eiffel, je ne sais pas trop, mais justement j'aurais tendance à penser le contraire. Je m'explique: qui a par une grosse industrie peut avoir besoin des contrats au point d'être prêt à tolérer les défauts du compilateur?

Pour les classes Sealed, rien à ajouter, je suis du même avis et je déplore qu'un boite comme MS en abuse.

Pour les dynamics, en visual basic il faut désactivé l'option strict. Autant dire que c'est un frein énorme à leur utilisation.

Pour la reflexion, oui elle plombe les performances comparer à des appels directs. Mais il faut bien avouer qu'elle reste quand même super efficace si utiliser à bon escient.

Sinon, pour revenir au problème de formation, ce que je trouve déplorable, c'est que je vois beaucoup de développeurs avec un niveau de base pas forcément bon (et je suis gentil en disant çà), mais le pire dans tout çà, c'est qu'ils s'en contentent! faut les prendre par la main pour les former! Ça leur vient pas à l'idée de combler leurs lacunes en s'auto-formant. Je trouve çà hallucinant. Il y a des tonnes de documents pour se former sur le web (ce site par exemple), des tonnes de livres sur la POO, les langages... c'est plus difficile à trouver en Architecture logiciel (en français), mais y en a quand même.

Donc que la formation de base soit mauvaise, pas de bol je dirais, mais bon faut savoir se prendre en main après.

J'ai eu une formation d'électronique, j'ai été formé en assembleur et en C (pas en C++). Je me suis formé tout seul sur VB 4 à VB.Net, C#, sur DotNet, sur les paradigmes de développement, sur les architectures...
Jamais mes employeurs n'ont eu à ce plaindre de mes compétences, quand je sais pas, je le dis... et j'apprends.
Je suis devenu architecte logiciel, j'ai des lacunes sur certains points (comme tout le monde) je me forme.

Je déplore aussi le nombre de développeur qui ne connaissent pas les principes de bases de la POO (SOLID), les design pattern ...
Faire le choix de ne pas s'en servir en connaissance de cause (et surtout de conséquence ), c'est un choix, rien à redire la dessus, par contre faire le choix de les ignorer là franchement, y a des claques qui se perdent... mais bon je m'égare encore, désolé.

Je prends l'exemple de mon frère, fac d'infos (donc bac + 4 ou +5 en infos).
A sa sortie de l'école, il trouvait pas de travail, je l'ai pris sur des projets persos. Il ne connaissait pas DotNet, pas les design patterns, pas SOLID...
Je l'ai former pendant 6 mois sur DotNet, Asp.Net etc etc
Je l'ai aussi converti en VB en passant (pas de ma faute j'adore ce langage, et la passion c'est contagieux)
Depuis, il bosse et n'a jamais été au chomage.
Maintenant, c'est un des rares informaticiens que je connais avec qui je peux avoir des discussions passionnantes sur l'architecture logiciel.

Je termine encore en hors sujet, décidément

[cinemania]

Ba c'est un hors sujet, oui mais en fait tu n'y est pas pour grand chose... ce sont des sujets intimement liés.

Un bon architecte logiciel, est quelqu'un qui sait admettre ses lacunes, et sait demander quand il a besoin d'aide...
Normalement c'est ce que l'on est sensé attendre d'un développeur, malheureusement, ce n'est pas la norme, et les développeurs ont plutôt tendance à croire le contraire.
C'est même d'ailleurs cela qui est assez ubuesque finalement, c'est des architectes qu'on devrait attendre qu'ils ne se remettent pas en cause parce qu'ils devraient tout connaitre (je te le concède c'est impossible, c'est pourquoi j'ai dit devraient) et des développeurs qui devraient eux sans cesse réclamer de l'aide...
le monde est ainsi fait malheureusement.

Personnellement je développe alternativement en C# ou en VB.NET parce que divers projets de la société où je travail, sont écrit en VB.NET, même si étant de culture Delphi, C et C++ par la suite, j'ai toujours une préférence pour C#.
ce que je n'aime pas en VB.NET c'est sa trop grande verbosité, qui nuit à la lisibilité pour peu qu'elle soit accompagnée des exemples précités en C#...
néanmoins j'y ai trouvé quelques avantages également, même si globalement VB.NET et C# se valent, il faut aussi admettre que l'intellisense étant plus abouti pour C#... cela facilite aussi le travail à travailler en C#
je débute un gros projet pour la société, et compte tenu de l'envergure, j'ai pris le parti de l'écrire en C# pour des raisons de pure productivité et non de lisibilité...

Lors d'un précédent pavé, tu faisait référence aux "nullable" avec l"opérateur ?... tu dit qu'ils ne sont pas allés assez loin...
Pour les nullable je vois assez mal comment ils auraient pu aller plus loin...
En autorisant les Nullable sur des références ? quel en serait l'intérêt, dans la mesure où les références, sont déjà des nullable en soit.

Pour ce qui est des contrats, c'est effectivement une bonne chose dans la mesure où toute méthode respectant son contrat évite ainsi pas mal de tests unitaires supplémentaires.
Et évite également d'inclure des tonnes de tests parce qu'on doit faire attention à ce que les développeurs donne à la fonction...
Cependant, le problème est que jusqu'ici et ce à part dans Eiffel, l'utilisation d'assertions se faisait un peu de façon désorganisée et tu rencontre dans du code par ci et là des assertions, et le problème c'est que parfois, les assertions sont mal écrites, je l'ai déjà vécu... j'ai même du retirer des assertions car elles n'avaient pas leur place là où elles étaient écrites et ne correspondait pas réellement au contrat fixé.
Enfin bon c'est toujours relatif à la mauvaise formation des développeurs.

[OsoNet]

Pour le choix du langage, comme tout choix, si il est fait en connaissance de cause et de conséquence, y a rien à redire la dessus.
Par exemple, ce que tu n'aimes pas en VB, c'est ce qui m'attire chez lui. Les gouts et les couleurs...

Pour l'intellisense, j'ai toujours penser le contraire, bizarre, j'ai toujours détesté dans visual studio, sous CS, le fait d'avoir à recompiler pour que les erreurs/warnings/intellissense et autre ce mettent à jour.

Pour les nullables, l'intérêt sur les références est juste un intérêt d'unification. A part çà, je vois pas d'autre intérêt.
Ils auraient pu aussi l'inclure dans les opérateurs surchargeables ce qui n'est pas le cas il me semble (à vérifier, j'ai un doute d'un seul coup).

Pour les contrats, je pratique habituellement une programmation défensive, et je me suis déjà fait rappeler à l'ordre par des développeurs (de bon niveau) car après plusieurs évolutions du code, certains tests étaient devenu obsolètes, pas dangereux ou buggés, mais tout simplement inutile.
Donc, oui, on peut tous ce faire avoir à un moment ou un autre, et les contrats, assertions, tests et autres sont du code en plus à maintenir.
Mais bon, doit-on s'en passer pour autant, j'en suis pas certain.
Avec les contrats intégrés dans DotNet 4.0, je vais certainement pratiquer plus souvent une programmation offensive mais, c'est un autre sujet.

J'aime bien ton discours sur les architectes logiciels, je devrais peut-être participer un peu plus à ce genre de discussion sur les forums de developpez.net.

[OsoNet]

Je fais un hors sujet complet, mais bon.

J'aime à croire que j'ai un profil pas courant, j'explique:
Je suis architecte logiciel, mais également développeur "expert" (c'est pas moi qui le dit), et les développeurs avec qui j'ai bossé me disaient souvent qu'ils étaient pas habitué à çà.

Alors un architecte logiciel, çà doit être un développeur, çà doit développer aussi ou pas du tout?

Particulièrement je n'ai quasiment jamais eu de proposition où je ne devais faire que de l'architecture.

Voilà, fin du hors sujet.