Discussion :

[souviron34]

Je vais te poser une question qui à mon avis fait la différence entre POO et pas POO.
Tu cites l'exemple d'un objet Messager et d'un objet CentreDeTri qui tous les deux transmettent un courrier. Dans la version POO, nous sommes d'accord que ces 2 classes pourraient hériter d'une même classe (ou interface) parente qui exposerait une méthode TraiterCourrier() dans son contrat. Un objet tiers qui voudrait simplement envoyer un courrier sans se soucier des détails de l'expédition pourrait juste manipuler un objet du type de la classe parente qu'on lui passerait, et grâce au polymorphisme le bon traitement serait appliqué : par messager ou par centre de tri. On aurait alors une bonne maintenabilité du système puisque pour étendre notre gamme de modes d'expéditions, il suffit de créer une nouvelle classe implémentant le contrat TraiterCourrier() et d'en passer une instance à l'objet qui souhaite envoyer un message. Pas besoin de "casser" le code de la classe appelante ni de la classe de base.

Est-ce que la même chose serait possible dans le cas de fonctions statiques CentreDeTri_prendreCourier() et Messager_prendreCourier() et du code "procédural" que tu décris ? Si oui, et je veux bien savoir comment, je considère que c'est de l'orienté objet (ou du fonctionnel, à la limite).

Facile

On utilise la notion de "callbacks", ou de fonctions enregistrées (exactement simlaires aux callbacks d'un widget dans une IHM)

Un petit exemple en C : (je simplifie un peu : je ne mets pas toutes les fonctions, et plusieurs options sont possibles)

Soit un include de définitions d'actions diverses :

Code C :

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

1
2
3
4
#define ENVOYER 1
#define TIMBRER 2
#define PESER   3
....

et un include de définition d'une structure de fonction callback commune :

Code C :

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

1
2
..
typedef int HandlerFunction ( void *Clientdata );

On a un module de gestion des events :

Code C :

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
typedef struct pEventHandler {
 
     int              EventType ;
     int              ObjectType ;
     HandlerFunction *Function
 
} EventHandler ;
 
static EventHandler *TableEvents=NULL ;
static int           NEventHandlers=0 ;
 
int RegisterEventHandler ( int EventType, int ObjectType, int *Function )
{
   EventHandler *tmp ;
 
   tmp = realloc ( TableEvents, (NEventHandlers+1)*sizeof(EventHandler) );
   if ( tmp != NULL )
     {
         TableEvents = tmp ;
         Table€vents[NEventHandlers].EventType = EventType ;
         Table€vents[NEventHandlers].ObjectType = ObjectType ;
         Table€vents[NEventHandlers].Function = Function ;
         NEventHandlers = NEventHandlers + 1 ;
         return SUCCESS ;
     }
   else
       return ERROR ;
}
 
int CallRegisteredFunction ( int EventType, int ObjectType, void *ClientData )
{
  int i, s = SUCCESS ;
 
 
   for ( i = 0 ; i < NEventHandlers ; i++ )
     {
         if ( (TableEvents[i].EventType == EventType) &&
              (TableEvents[i].ObjectType == ObjectType) )
           {
                 s = TableEvents[i].Function ( ClientData ) ;
                 break ;
           }
     }
 
   return s ;
}

On a un code de création des "classes" et de leurs méthodes :

Code C :

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
 
#define CENTRE_TRI 0
#define MESSAGER   1
...
/* Crée centre de tri */
...
RegisterEventHandler ( ENVOYER, CENTRE_TRI, &EnvoyerParCentreDeTri );
..
/* Crée messager */
..
RegisterEventHandler ( ENVOYER, MESSAGER, &EnvoyerParMessager );
..
..
int EnvoyerMessageParCentreDeTri ( void *Data )
{
....
}

et on a un code d'utilisation :

Code C :

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

1
2
3
4
...
/* La variable TypeEnvoi est définie par l'appli, par l'usager via l'IHM.. */
 
statut = CallRegisteredFunction ( ENVOYER, TypeEnvoi, &MyData );

Tu vois, c'est pas bien long

Pour étendre les moyens d'envois, il suffit de créer la classe correspondante dane le module de création, et d'ajouter le choix dans l'IHM par exemple.. (on ne touche même pas les modules applicatifs)


Il y a d'autres moyens de faire, mais là je te donne un exemple... Utilisé absolument couramment en procédural un peu évolué (on peut même rajouter des structures dépendantes des actions (ce qui se fait dans les callbacks de widgets))

D'autre part, comme le code de gestion des handlers est général, le même module (oui oui, juste ces 45 petites lignes) peut s'appliquer pour enregistrer des fonctions d'édition, d'IHM, d'accès à des BD, de traitement d'image, ce qu'on veut..

[souviron34]

J'ajouterais que, pour réaliser l'héritage d'une classe, voire un héritge multiple, c'est aussi simple.

• Il faut d'une part enlever le "break" dans la boucle qui passe à travers les EventHandlers, pour pouvoir appeler plusieurs handlers pour chaque combinaison type événement/type objet (ce que j'aurais pu faire dès le départ)
  
  
• Ensuite, dans le module de création, comme on peut enregistrer plusieurs eventhandlers par action / par objet, il suffit d'écrire :
  
  

  Code C :

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

  1
  2
  3
  4
  5
  6
  #define NEW_WAY
   
  /* Création d'une classe héritant de Messager */
  ....
  RegisterEventHandler ( ENVOYER, NEW_WAY, &EnvoyerParMessager );
  RegisterEventHandler ( ENVOYER, NEW_WAY, &EnvoyerParNouveauMoyen );

Comme j'ai dit, diverses options sont possibles.. On pourrait aussi se passer du paramètre ObjectType dans les EventHandler,, et faire une vraie "classe" avec une structure, qui ne nécessiterait même pas de ré-enregistrer la fonction du parent (par contre, dans ce cas on a besoin d'une structure de callback, contenant au minimmum l'id de l'objet émétteur) :

Code C :

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
typedef struct _pSendingMean {
 
   int Type ;
   _pSendingMean *Parent ;
 
} SendingMean ;
 
SsndingMean CentreDeTri, Messager, Moyen ; 
...
/* Création du centre de tri */
...
/* Cation du Messager */
...
/* Création d'un nouveau moyen */
Moyen.Parent = &Messager ;
RegisterEventHandler ( ENVOYER, NEW_WAY, &EnvoyerParMoyenQuelquonque, &Moyen );
....
 
int EnvoyerMessageParMoyenQuelquonque ( void *Data, void *Origine )
{
  SendingMean *Moyen = SendingMean *)Origine, *Parent ;
 
   Parent = Moyen->Parent ;
 
  if ( Parent != NULL )
     CallRegisteredFunction ( ENVOYER, Parent->Type, Data ); 
....
}

La première version, quoique moins "objet", est plus facile.. Mais on peut utiliser d'autres manières..

Tout ceci pour dire que oui, c'est absolument faisable.. Et c'est normal, puisque par exemple C++ est dérivé du C : les notions de void, void*, et structures imbriquées du C sont à la base de l'objet, donc on peut faire tout ce qu'on fait en objet en C...


Note: faire une implémentation "full object" n'est pas vraiment plus compliqué (voire plus simple encore)..

Il suffit se créer un objet global, et de se servir de ça dans les eventhandler à la place des types d'objets :

Code C :

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

1
2
3
4
5
6
typedef  struct pObjet {
 
     pObjet  *Parent ;
     void  *Struct ;
 
} Objet ;

Code C :

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
int RegisterEventHandler ( int EventType, Objet *SObjet, void *Function )
{
..
}
 
int CallRegisteredHandler ( int EventType, Objet *SObjet, void *Data )
{
     int i, s ;
 
     for ( i = 0 ; i < NEventHandlers ; i++ )
       {
           if ( (TableEents[i].EventType == EventTYpe) && (TableEvents[i].Objet == SObjet) )
              {
                  if ( SObjet->Parent != NULL )
                      s = CallRegisteredHandler ( EventType, SObjet->Parent, Data );
                  s = TableEvents[i].Function ( SObjet, Data );
              }
       }
 
    return s ;
}

Et là le module des "classes" devient :

Code C :

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

1
2
3
4
...
s= RegisterEventHandler ( ENVOYER, &Messager, &EnvoyerParMessager );
..
s= RegisterEventHandler ( ENVOYER, &Moyen, &EnvoyerParAutreMoyen );

Dans ce cas, la fonction EnvoyerPar.. recevra en premier paramètre un pointeur sur l'objet, l'équivalent du "this" en C++. et l'héritage est géré en interne..

Et là, ajouter (ou changer) la classe d'un élément est direct...

[ptah35]

... donc on peut faire tout ce qu'on fait en objet en C...

... le compilateur C++ arrive même à faire de l'objet en langage machine! C'est dire ;-)

[psykokarl]

Je vais te poser une question qui à mon avis fait la différence entre POO et pas POO.

On peut faire de tout avec n'importe quel langage pourvu que celui soit complet. La réelle question est si l'on se trouve dans un cas ou la conception OO simplifie ou complexifie le problème.
En fait le choix de tel ou tel paradigme se fait assez naturellement pour peu qu'on a la culture suffisante et que l'on ne soit pas psychorigide.

Tu cites l'exemple d'un objet Messager et d'un objet CentreDeTri qui tous les deux transmettent un courrier. Dans la version POO, nous sommes d'accord que ces 2 classes pourraient hériter d'une même classe (ou interface) parente qui exposerait une méthode TraiterCourrier() dans son contrat. Un objet tiers qui voudrait simplement envoyer un courrier sans se soucier des détails de l'expédition pourrait juste manipuler un objet du type de la classe parente qu'on lui passerait, et grâce au polymorphisme le bon traitement serait appliqué : par messager ou par centre de tri. On aurait alors une bonne maintenabilité du système puisque pour étendre notre gamme de modes d'expéditions, il suffit de créer une nouvelle classe implémentant le contrat TraiterCourrier() et d'en passer une instance à l'objet qui souhaite envoyer un message. Pas besoin de "casser" le code de la classe appelante ni de la classe de base.

Je vais raisonner de façon mimétique à la POO pour l'exemple.

En situation réelle, il est possible que la finalité du dev m’amène à penser le code autrement. Cela en changerait l'aspect pour plus de compréhension/efficacité.

En procédural implémenté les deux "classes" donnerait:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
//classe Messager
struct Messager
{
	int unAttribut;
	int (*TraiterCourrier)(struct courrier);
};

int rendUnServiceAUnPote(struct courrier)
{
	//code
	return 0;
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
//classe centre de Tri
struct CentreDeTri
{
	int unAttribut;
	int (*TraiterCourrier)(struct courrier);
};

int preparerBoulotPourLeFacteur(struct courrier)
{
	//code
	return 0;
}

L'appel se ferait de la façon suivante:

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
int main()
{
	struct courrier lettre = ...;
	
	struct Messager unMessager;
	unMessager.TraiterCourrier = rendUnServiceAUnPote;
	
	unMessager.TraiterCourrier(lettre);
	
	struct CentreDeTri centrePTTDeRoissy;
	centrePTTDeRoissy.TraiterCourrier = preparerBoulotPourLeFacteur;
	
	centrePTTDeRoissy.TraiterCourrier(lettre);
}

Je peux même pousser le vice jusqu’à imiter la syntaxe objet.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
int main()
{
	struct courrier lettre = ...;
	
	struct CentreDeTri *centrePTTDeRoissy;
	centrePTTDeRoissy = malloc(sizeof(struct CentreDeTri));
	(*centrePTTDeRoissy).TraiterCourrier = preparerBoulotPourLeFacteur;
	
	centrePTTDeRoissy->TraiterCourrier(lettre);
}

Je peux pousser la ressemblance encore plus loin en recréant les opérateurs class et new avec des macro, gérer l’auto-référencement en stockant l'adresse de l'instance dans un attribut, etc. Je vais m’arrêter la.

Et pour reprendre l'exemple d'origine, si on a un ServiceExpédition et 2 classes dérivées ServiceExpéditionCentreDeTri et ServiceExpéditionMessager, alors oui, c'est de l'orienté objet même s'il y a des solutions plus élégantes que d'utiliser le mot-valise "Service" pour ça.

Cette question est plus embarrassante.
Il est également possible de créer un système d'héritage avec des macro ou des fonctions mais j'ai la flemme d'en concevoir qui soit élégante.
Si je dois pousser aussi loin la ressemblance avec OO, autant passer sur un langage OO.

Petite pique cependant:
Le système d'héritage c'est bien pour organiser le code non pas au niveau de l'architecture du code mais au niveau des librairies(appelé framework chez les 00). J'ai déjà perdu des heures à faire de beau framework. C'est amusant mais ça ne rapporte rien au projet: ni à la compréhension, ni à l'optim.

J'enchainerai avec la notion d'attribut de classe.
D'un point de vue de programmation procédurale structuré, un attribut de classe en OO se rapproche d'une variable globale. Il est vrai qu'elle est protégée et disponible uniquement au niveau de l'instance ou des instances de la classe dans le cas d'un attribut statique.
L'exemple donné par Souviron34 est souvent préféré à celui que j'ai donné comme exemple parce qu'il s'affranchit totalement des variables statiques. Cela veut dire que si je veux utiliser une méthode de Souviron34 dans ma classe CentreDeTri pour x raisons, il me suffit de récupérer sa "méthode" et uniquement sa méthode.
Je n'ai pas a récupérer toute sa "classe" à cause des variables d'instance et encore moins son "framework" dans le cas ou sa classe serait en bas d'une arborescence d'héritage. En terme de modularité il n'y a pas photo !

Il est possible d'avoir une modularité équivalente en POO mais la plupart des dev OO n'ont pas cette culture.
Quand un dev OO qui n'a cette culture de la programation vient raconter à qui veut l'entendre que l'OO permet plus de modularité ben le dev élevé à l'école du procédural grince des dents...

La modularité est une question de méthode et non de langage !

[ptah35]

Il est possible d'avoir une modularité équivalente en POO mais la plupart des dev OO n'ont pas cette culture.
Quand un dev OO qui n'a cette culture de la programation vient raconter à qui veut l'entendre que l'OO permet plus de modularité ben le dev élevé à l'école du procédural grince des dents...

La modularité est une question de méthode et non de langage !

Entièrement d'accord, mais il faut leur accorder une certaine indulgence car le problème vient bien souvent de l'enseignement. En effet, trop souvent on leur apprend les bases de la programmation structurée avec un langage tel que Java en utilisant une seule classe (en fait simplement un module mais dont ils ne soupçonne même pas l'existence) avec une méthode static main comme point d'entrée dans laquelle ils font leurs programmes en appellant, au mieux, quelques procédures et fonctions définies ce même module. On leur dis ensuite que ce qu'ils ont fait là c'est de la programmation procédurale et que c'est vieux et ringare et que maintenant ils vont apprendre la bonne programmation c'est-à-dire celle orientée-objet. Là ils apprennent que pour faire de l'orienté-objet il faut des classes, de l'héritage, des interfaces, et tout et tout; alors du coup, quand ils tombent sur un langage qui ne supporte pas directement ces notions, ils en déduisent naturellement que ce langage ne permet de faire que de la programmation procédurale. Comment pourraient-ils se douter que si des langages supportent les notions de classe, d'héritage, d'interface, c'est justement parce que ces notions permettent de réaliser plus facilement ou plus directement des choses que des programmeurs réalisaient en C, en Pascal, en Ada ou dans je ne sais quel autre langage encore depuis bien longtemps et que la POO en tant que paradigme a précédée les langages qui la supporte.

C'est d'ailleurs la raison pour laquelle j'essaie autant que possible dans mon enseignement de remettre les choses dans un contexte historique et montrer autant que faire peut que ces concepts ne sont pas tombées du ciel un beau jour.

[psykokarl]

Entièrement d'accord, mais il faut leur accorder une certaine indulgence car le problème vient bien souvent de l'enseignement.

Je ne dis pas autre chose.
J'ai eu un cursus plutôt universitaire. J'y ai vu indifféremment plusieurs familles de langages. J'ai été encouragé à les critiquer et les comparer. Lorsqu'il m'a fallut trouvé du boulot j'ai séché lors des entretiens techniques parce que je ne connaissais pas telle syntaxe de tel fonction de tel langage. Il faut voir les vieux piège qu'ils mettent (ordre des paramètres, underscore, cases de caractère, etc...) .

Aujourd'hui on forme d'avantage sur un type de techno à coup d'éloge sur les possibilités offertes par telle version. La programmation en tant que matière tend à disparaitre. Ceux qui sortent de ces écoles sont très prisés sur le marché du travail, jusqu’à ce que l'on change de techno...

[souviron34]

C'est d'ailleurs la raison pour laquelle j'essaie autant que possible dans mon enseignement de remettre les choses dans un contexte historique et montrer autant que faire peut que ces concepts ne sont pas tombées du ciel un beau jour.

Et aussi, j'ajouterais :

• que ce n'est pas antinomique
  
• que ce n'est pas "mieux", simplement différent
  
• que prendre une option plutôt que l'autre devrait amener au même soft si la réflexion est bien faite
  
• que il y a un overhead non négligeable pour de grosses applis avec l'OO (initialisation systématique par les new alors qu'en procédural si on sait ce qu'on manipule on peut s'en passer (et que de plus on pourrait avoir des tableaux avec une seule allocation, ou des tableaux partiellement dynamiques, réduisant le nombre d'allocations), variables "globales" via les attributs de classe, complexification du source via les factories, multiplications des sources par classes, et les héritages pour la compil,..)

bref, que "historique" ne veut pas die "obsolète".. et "nouveau" n'est pas synonyme de "mieux", mais de "différent"..

[ptah35]

bref, que "historique" ne veut pas die "obsolète".. et "nouveau" n'est pas synonyme de "mieux", mais de "différent"..

Cela va de soit, un nouveaux concepts n'invalide que très rarement un anciens. Le plus souvent on ne fait tout au plus qu'ajouter un niveau d'abstraction --- le but étant toujours de tendre vers une meilleure gestion de la complexité --- mais plus abstrait est rarement synonyme de plus efficace.

[Luckyluke34]

Cette question est plus embarrassante.
Il est également possible de créer un système d'héritage avec des macro ou des fonctions mais j'ai la flemme d'en concevoir qui soit élégante.

Le problème, c'est que c'est justement à travers l'héritage et le polymorphisme notamment qu'on peut éviter les forêts de if et qu'on respecte le principe ouvert/fermé qui permet de rajouter des comportements en cassant le minimum de code existant. Ce qui au passage n'est pas le cas du code que tu as posté puisqu'il n'y a pas de type de données abstrait au-dessus de CentreDeTri et Messager qui permettrait un couplage faible du code appelant avec le mécanisme d'envoi de courrier.

Maintenant, je n'ai pas lu le code de souviron, si vous dites que c'est possible et que vous le faites tous les jours dans un langage procédural (C en l'occurrence) je vous fais confiance et c'est tant mieux. Le fait est que je préfèrerais même avoir à maintenir ce genre de code que du code écrit avec les pieds dans un langage objet.

Si je dois pousser aussi loin la ressemblance avec OO, autant passer sur un langage OO.

Heureux de te l'entendre dire

Petite pique cependant:
Le système d'héritage c'est bien pour organiser le code non pas au niveau de l'architecture du code mais au niveau des librairies(appelé framework chez les 00). J'ai déjà perdu des heures à faire de beau framework. C'est amusant mais ça ne rapporte rien au projet: ni à la compréhension, ni à l'optim.

Je ne le vois pas du tout comme ça. L'héritage et le polymorphisme sont avant tout le mécanisme utilisé en POO pour avoir des types de données abstraits, autrement dit assurer un couplage faible entre unités de code en permettant aux classes de considérer leurs dépendances comme des boîtes noires.
Le fait de pouvoir utiliser l'héritage pour utiliser ou étendre des fonctionnalités d'une bibliothèque tierce me parait secondaire et la corrélation avec le manque d'intérêt des frameworks, douteuse.

bref, que "historique" ne veut pas die "obsolète".. et "nouveau" n'est pas synonyme de "mieux", mais de "différent"..

Je ne doute pas que tu appliques le même principe aux développeurs et que tu accordes ce crédit aux "petits jeunes" qu'ils peuvent apporter quelque chose qui, à défaut d'être mieux, est différent et amène à réfléchir et évoluer

Bref... je ne crois pas que l'objectif de la personne qui a posté la question d'origine était d'obtenir un troll de 12 pages sur le thème "anciens langages vs nouveaux langages" (il y a la taverne pour ça), et à vrai dire ça m'intéresse aussi assez peu.

Pour revenir au sujet de départ, je vais donc rester sur ma réponse (avec laquelle chacun a le droit de ne pas être d'accord) : non, orienté objet ne veut pas dire 100% objet, orienté objet ne veut pas dire bannir les services, et orienté objet ne veut pas dire objets métier obèses et charger 250 Mo de données en mémoire.
Je conseillerais aussi la lecture du PoEAA de Fowler qui pour le coup reste assez neutre sur l'utilisation d'un Transaction Script procédural ou d'un Rich Domain Model objet.

[psykokarl]

En fait je suis d'accord avec ta réponse. C'est une solution élégante.

Quand tu dis:

Je pense que le stéréotype largement répandu selon lequel l'orienté objet a pour but de modéliser des objets du monde réel est en grande partie faux. Faire de l'orienté objet, ce n'est pas prendre un terme métier, en faire une classe et essayer de fourrer des méthodes dedans pour faire tourner notre appli.

J’adhère à 100 %. Je ne sais pas si tu t'es rendu compte de cette évidence grâce au cours que tu as reçus ou par une recherche personnelle mais en tout cas bravo !

mais quand tu ajoutes.

L'orienté objet, c'est avant tout l'encapsulation de données et comportement à l'intérieur de petites unités de code dont on peut gérer finement les interdépendances grâce à l'inversion de contrôle. Le procédural, c'est l'exécution en séquence de routines et sous-routines, généralement de taille plus large, peu réutilisables, et opérant souvent sur des données (variables) partagées par toute l'application.

Tu adhères à un autre stéréotype.

Les bonnes pratiques, les techniques d'optim, d'encapsulation, de modularité, presentation sont bien antérieure à la POO. Ce sont des techniques transverses valable pour tout type de langage.
Le truc bien avec l'OO c'est que le langage facilite la mise en œuvre de certaines d'entre elles. En contre partie dans certain cas l'OO complique la mise en œuvre de certains type d'algo, optim ou manière de présenter le code. C'est pour cela que l'on a créé les patterns.
Pour quelqu'un qui à fait du procédural les patterns n'ont rien de révolutionnaire. C'est de la traduction de ce qui se fait simplement en procédural vers de l'objet.
De la même manière les exemples que l'on ta montré plus haut pourraient etre des "patterns procéduraux" pour retranscrire en procédural ce qui se fait simplement en objet.
Si tu piges ça, un jour tu pourras écrire ton propre bouquin sur les patterns.

Cela dit, tu as raison, ce n'est pas le sujet d'origine. Enfin si un peu.
Par exemple il y en a qui ont créer des ORM pour ne pas trahir la philosophie 100% objet du code (ou pour combler les lacunes des devs).
C'est plus lourd à l'utilisation, plus dur à optimiser et moins souple que le SQL, si on se donne la peine d'apprendre ce langage.

Personnellement, je crois en le multi-pradigme.

[souviron34]

C'est pour cela que l'on a créé les patterns.
Pour quelqu'un qui à fait du procédural les patterns n'ont rien de révolutionnaire. C'est de la traduction de ce qui se fait simplement en procédural vers de l'objet.

C'est d'ailleurs tellement naturel en procédural que (à part le fait de s'adresser à des gens n'ayant manipulé que de l'objet) le fait d'en faire tout un plat et de leur donner des noms et de s'écharper sur savoir si c'est MVC ou autre chose me laisse sans voix ni argument...

(encore une fois, le modèle en couche ISO, ou l'architecture du Web , d'un navigateur, des sockets, ou la bibliothèque et serveur X, en sont des exemples "anté-diluviens" pour reprendre les termes actuels )

Personnellement, je crois en le multi-pradigme.

moi je crois encore plus en l'absence de paradigme

Ayant appris sur le tas, un "paradigme" est pour moi un truc de théoricien.. Je prend le langage qu'on m'impose (j'ai rarement le choix), et je me débrouille pour faire ce qu'on me demande avec, de la manière la plus élégante et la plus maintenable possible...

Que ce soit en C, en Fortran, en Pascal, en Delphi, en C++, en Postscript, Prolog, Java, ou n'importe quoi..

Le seul "paradigme" auquel je crois c'est que toute norme est mauvaise, car elle est (à 99%) prise à la lettre, alors que ce n'est censé être qu'un guide...

Et qu'on formatte des "ouvriers à la chaîne" à qui on a bourré le crâne de certitudes, au lieu de former des gens ouverts et polyvalents, dotés d'esprit critique et de doutes.. Que ce soit en "paradigme", en "méthodologies", ou en "postes"..


Ce qui me déçoit beaucoup en info, c'est que ce qui devrait être du domaine de la Recherche et d'équipes de chercheurs tombe très souvent dans les formations, et donc sur le "marché"... Autant je peux comprendre qu'en médecine un nouveau médicament soit immédiatement mis sur le marché et/ou enseigné, autant dans des sciences plus éloignées de la santé, j'ai beaucoup de mal à comprendre. Je viens de l'astronomie... Je ne pense pas qu'on enseigne la Matière Noire et les réactions nucléaires au sein des étoiles aux élèves/étudiants se destinant à faire de l'électronique ou même aux futurs ingénieurs physiciens. Personnellement je ne l'ai vu qu'en DEA... De même on n'enseigne pas la Relativité Générale aux futurs mécaniciens..

Alors c'est certainement dû à l'aspect "nouveauté" (et j'oserais dire marketing) de l'informatique, mais ça me fait irrésitiblement penser à la course aux bio-technos et aux annonces de clonage, ou ces derniers temps à tout ce qui a touché le Réchauffement Climatique.. ou dernièrement le Gluten... On crée un buzz, on forme des gens, on reçoit des subventions..

Je suis peut-être pessimiste... ce soir

[_skip]

Bref... je ne crois pas que l'objectif de la personne qui a posté la question d'origine était d'obtenir un troll de 12 pages sur le thème "anciens langages vs nouveaux langages" (il y a la taverne pour ça), et à vrai dire ça m'intéresse aussi assez peu.

J'irai pas jusqu'à dire que c'est du troll. Mais j'avoue que j'aurai aussi préféré qu'on ne se pende pas trop sur les détails des questions style "peut-on simuler de l'objet en pur C" car ce serait un autre sujet.

Pour revenir au sujet de départ, je vais donc rester sur ma réponse (avec laquelle chacun a le droit de ne pas être d'accord) : non, orienté objet ne veut pas dire 100% objet, orienté objet ne veut pas dire bannir les services, et orienté objet ne veut pas dire objets métier obèses et charger 250 Mo de données en mémoire.

Comme je l'ai écrit précédemment dans mon post qui faisait suite au tien, je pense également que le monde ne peut pas être tout blanc ou tout noir. Il y a clairement des responsabilités qui sont faciles à confier à un objet métier sans se retrouver à lazy-loader à tout va et à jouer aux apprentis sorciers, mais d'autres seront plus faciles à concevoir et à optimiser si on les externalise derrière un "service" avec une méthode symbolisant une transaction.

Après on peut sûrement mixer et opter pour un objet métier qui utilise les services pour se procurer des données. Attention à ce moment là, si l'on utilise des collections de ces objets à ne pas tomber dans les pièges du n+1.

Je conseillerais aussi la lecture du PoEAA de Fowler qui pour le coup reste assez neutre sur l'utilisation d'un Transaction Script procédural ou d'un Rich Domain Model objet.

Je note la référence .

Cela dit, tu as raison, ce n'est pas le sujet d'origine. Enfin si un peu.
Par exemple il y en a qui ont créer des ORM pour ne pas trahir la philosophie 100% objet du code (ou pour combler les lacunes des devs).
C'est plus lourd à l'utilisation, plus dur à optimiser et moins souple que le SQL, si on se donne la peine d'apprendre ce langage.

L'utilisation d'ORM et de mappers doit toujours se faire avec prudence. A mon avis celui qui utilise ces outils au sens "je veux pas faire du SQL" il a bien des chances de se tromper.
Le problème c'est que l'un des buts recherchés par certains développeurs à travers ces outils, ce serait de pouvoir faire abstraction du fait que derrière, c'est une base de données relationnelles. Le problème c'est que la réalité vous rattrape assez vite, mais pas forcément assez pour ne pas nuire à la réussite d'un projet.

[souviron34]

Mais j'avoue que j'aurai aussi préféré qu'on ne se pende pas trop sur les détails des questions style "peut-on simuler de l'objet en pur C" car ce serait un autre sujet.

Mais c'est pourtant toi qui a proposé / questionné à propos de technicité (post #7)

Et le post suivant de LuckyLuke semblait se baser sur de telles faussetés concernant le "procédural" qu'on ne pouvait pas le laisser passer..

[ptah35]

Ce qui me déçoit beaucoup en info, c'est que ce qui devrait être du domaine de la Recherche et d'équipes de chercheurs tombe très souvent dans les formations, et donc sur le "marché"...

La programmation orientée-objet est aussi ancienne que la programmation structurée et il est même possible qu'elle l'ait un peu précédée. Je ne pense pas que la POO soit du domaine de la recherche ou de l'avant-garde à telle point d'ailleurs que, comme le montre ce file, les idées de la programmation orientée-objet ont fait leur chemin bien avant l'arrivée de Java, .NET et consort. Fin 70 début 80, Objective-C et C++ ont amené un support pour l'orienté-objet au C en reprenant les idées de smalltalk et simula, alors que plus ou moins dans le même temps Ada sans se vendre comme un langage orienté-objet faisait, entre autre, la part belle au modules et à un contrôle assez fin de la visibilité ce qui permettait de réaliser efficacement des type abstrait. Cela fait donc bien 30 ans que plus personne ne fait de la programmation purement procédurale et que presque tout le monde applique les idées de l'orienté-objet (encapsulation, polymorphisme, etc.) jusque dans des programme en assembleur. Inversement personne ne fait non plus du 100% OO, ce terme ne voulant rien dire puisqu'il n'y a pas de définition consensuelle de l'orienté-objet (c'est tout juste si la notion de classe fait l'unanimité).

un "paradigme" est pour moi un truc de théoricien.. Je prend le langage qu'on m'impose (j'ai rarement le choix), et je me débrouille pour faire ce qu'on me demande avec, de la manière la plus élégante et la plus maintenable possible...

c'est, je pense, la meilleures conclusion qu'on puisse donner à ce file. La programmation n'est pas une science, encore moins de la mathématique et surtout pas une religion; rien n'y est "pur". J'aime voir la programmation comme un artisanat; les programmeur comme des artisans avec plus ou moins les mêmes outils et savoir faire de base mais chacun avec ses petites recettes et même si tous n'ont pas la même habileté, la plupart ont cette passion qui distingue l'artisanat de l'industrie.

[psykokarl]

La programmation orientée-objet est aussi ancienne que la programmation structurée et il est même possible qu'elle l'ait un peu précédée.

En fait le concept de classe, disons le prototype de la classe, est apparu avant le concept de POO...
Bien que le paradigme fonctionnel (en cours de démocratisation) se soit fait connaitre après le paradigme objet objet, le Lisp est apparu avant le Simula.

Alors la programmation structurée est elle apparu avec le paradigme fonctionnel me demanderez vous ?
Ben non, ce n'est pas le cas non plus.

La programmation structurée est née et s'est développée en même temps que la programmation. Elle est le bébé de techniciens qui avaient le souci de répondre à des exigences de lisibilité, d'efficacité et de modularité.
En cela la programmation vient enrichir d'autres sciences qui ont précédé l'informatique comme logique, la linguistique et toutes les autres qui peuvent regrouper sous la bannière des sciences du langage.

Le but ultime est de programmer en utilisant le langage naturel. Nous autres avec nos langages et nos technos sommes perdu quelque part entre le début et la fin de cette aventure.

[arkhamon]

Bonjour à tous,
je viens de lire ce post très intéressant, car très "passionné".
J'ai lu beaucoup de choses, et je vous rassure je n'ai pas tout compris. Du coup, comme d'habitude, je vais faire le terre-à-terre.
Au final, et quoi qu'on en dise, notre cher bon vieux PC (ou MAC suivant les cas) est encore basé sur 2 principes de base : le binaire et Von Neumann.
Donc toutes les couches OO et consors ne sont à mon avis qu'une façon certes élégantes mais artificielle de piloter la logique d'un soft. Je m'explique...

Autrefois, des gens faisiaent des applis en BASIC, ou en COBOL ou en PASCAL. On avait quoi ? L'affichage d'un menu et ensuite une boucle qui tournait (idle process) et qui en fonction de l'option sélectionnée, exécutait une fonction ou une autre contenant du code.

Maintenant on a quoi ?

• Une série de méthodes (fonctions) contenant du code.
• une sorte de gestionnaire d'évènement qui déclenche une méthode en fonction d'un choix

Au risque de paraître désagréable, j'ai deux remarques :

1. Elle est où la différence ?
2. au final, on obtient pas de l'assembleur parfaitement PAS OO ?

J'avoue qu'en termes de lisibilité, il est probablement plus facile de comprendre un programme écrit en POO. Encore que...
Comme le disait une personne dans ce post, la POO permet d'avoir une vue d'ensemble de ce qu'il est possible de faire, en programmation structurée (ou procédurale), on s'attache plus à la logique de l'application. D'un côté on regarde les possibilités, de l'autre on regarde la logique...
En programmation structurée, on sait ou on en est. Suffit de suivre le déroulement. En POO, ca devient tout de suite plus difficile, car le déroulement peut être interrompu par un appel de méthode...

La POO introduit des concepts comme l'héritage et la réutilisabilité du code. On faisait pareil sans, avec les librairies... Masi il faut reconnaitre que ça semble plus simple en POO puisque justement c'est prévu pour.
Maintenant, comme tous les dogmes, et la POO en est un, il y a du bon et du mauvais. Du bon car bien utilisé ça s'avère redoutable d'éfficacité. Mais mal utilisé, ca devient un calvaire pour ceux qui passent après.
Un peu comme SAP.
Un peu comme les BDD.
Un peu comme l'assembleur.
Un peu comme la plomberie.
Un peu comme la maçonnerie.
Un peu comme l'informatique...

[OneEyedJack]

Bon, je suis tombé sur cette file un peu par hasard et un peu tard. Je n'ai pas pu m’empêcher de donner mon avis sur les différents échanges.

En fait j'ai un peu l'impression que cette histoire de 100% objet est un mythe, un cas d'école qui n'est réalisable que dans les applications triviales. Est-ce qu'on peut vraiment concevoir ses objets métiers en faisant abstraction du système de stockage comme on semble nous vendre dans les recueils de bonnes pratiques?

Avec plus de 20 ans d'expérience en conception et développement de systèmes complexes distribués (Smalltalk, C++, Java), je dirais que ce n'est pas un mythe, j'en ai développé des dizaines.

Je pense simplement que cette vision tout OO est une aberration de principe :

Pour reprendre un exemple que j'ai déjà cité dans un autre débat, il ne vient à l'idée de personne de penser qu'une lettre "possède" une méthode "se poster"..

Si maintenant on prend un humain, le nombre d'actions est tellement gigantesque et imprévisible - non dénombrable - que l'action "poster" en est effectivement une, mais que l'on connaît a posteriori et non a priori

En ce qui concerne l'enveloppe (et non la lettre) et sa capacité à se poster, je dirai que si la Poste disposait de la technologie le permettant et si elle vendait de telles enveloppes à prix abordable, je serai preneur (qui aime faire la queue pour poster un recommandé ?) On appelle çà une innovation.

Qui décide de ce qu'un objet peut faire ou ne pas faire ? son concepteur

Pour ce qui est de l'humain, c'est aussi une question de conception. Il n'y a pas si longtemps que çà :

• une femme ne pouvait pas ouvrir un compte en banque, son mari était le seul habilité
• une femme ne pouvait pas voter
• les téléphones ne nous prévenaient pas de l'arrivée d'un email

Il n'est absolument pas intuitif de penser et de modéliser des choses en OO, pour quiquonque n'est pas informaticien (qui plus est ayant appris le concept), à cause, comme précisé plus haut, de l'aberration conceptuelle que cela sous-tend dans la majorité des cas..

Pour avoir expliqué l'OO à des informaticiens (ne connaissant pas l'OO) et des non-informaticiens, je peux vous dire que les non-informaticiens s'en sortent mieux. Les objets font partie de notre quotidien et leurs fonctions associées aussi. Il y a même des environnements de développement Smalltalk pour les enfants...

En fait, il me semble que l'impact de l'OO provient de l'importance des grandes banques et sociétés de services oeuvrant dans le domaine des banques, qui ont toujours manipulé des BDD relationnelles, où les relations entre les données étaient le schéma de base, occultant même l'architecture globale.. et dont les "penseurs" n'avaient pas l'esprit scientifique...

A mon humble avis, les banques et les bases de données relationnelles n'ont rien à voire avec tout çà. Le paradigme dans lequel les SGBDR s'inscrivent est la théorie des ensembles et non pas l'OO, l'OO s'inscrit dans la systémique (la théorie des systèmes). C'est d'ailleurs pour çà qu'il existe des ORM : des outils qui permettent de passer d'un paradigme à l'autre en minimisant les impacts.

L'importance que prend l'OO depuis des dizaines d'années vient surtout du fait que ces technologies permettent de construire des systèmes complexes (au sens systémique) plus facilement.

Pour maîtriser la complexité, on n'a pas inventé mieux (pour l'instant) que le polymorphisme, la généralisation/spécialisation et la séparation interface/implémentation. Les langages non OO en sont dépourvus mais cela ne veut pas dire que l'on ne peut pas développer avec eux des systèmes complexes avec du code clair, facile à lire, modulaire,... c'est juste plus long et plus difficile : plus de code à écrire pour un résultat équivalent donc plus de bugs potentiels, plus de code à lire quand on modifie,...

Je pense surtout que l"object-oriented design" est, tel qu'il est conçu, une aberration' conceptuelle..

Le postulat de base est faux : un objet est inerte et n'a pas de "volonté", donc pas d'actions..

Je connais beaucoup de personnes disant être perpétuellement dérangés par leur téléphone. Si les objets étaient aussi inertes que çà... Et je connais des gens pas inertes et sans volonté...

Juste un exemple, avec la dernière version d'Android, votre téléphone apprend et réagit.

• S'il constate que vous partez tous les matins (il a un GPS) d'un point A pour aller à un point B, il comprend que vous habitez au point A et que vous travaillez au point B.
• Il est en mesure de vous avertir s'il constate que vous ne partez pas à l'heure habituelle (vous êtes-vous rendormi après avoir éteint le réveil ?)
• Le soir, vous rentrez chez vous à l'heure habituelle. Avant que vous ne partiez et sans que vous ayez demandé quoi que ce soit, votre téléphone constate des bouchons sur votre parcours préféré, il estime le temps de trajet et vous informe que vous rentrerez 30 min plus tard que d'habitude

Il y a ne serait-ce que 10 ans, on aurait dit que c'est de la science fiction.

Bien sur, il existe aussi des objets inertes. Un verre est tout ce qu'il y a de plus inerte, il ne porte que des informations de type contenance, couleur, structure physique, etc... Cela dit, lorsqu'il tombe par terre, un verre de cristal se casse. Est-ce un comportement, une fonction ? encore une fois, c'est une question de conception. Dans le logiciel, on ne prendra en compte que les caractéristiques pertinentes. Dans un site de vente, les caractéristiques seront essentiellement financières. Dans un jeu vidéo, le verre n'aura peut-être pas de prix mais il aura peut-être une capacité à se déformer.

Bon, je ne serais pas contre des verres qui auraient la capacité de se remplir lorsqu'ils sont vides... ok , c'est de la SF

Mais ce style de logiciel est de toutes façons très rare... La majorité manipule des "objets" non fixes, ou dépendants de fonctionalités précédentes...
A mon avis donc l"OOD n'est applicable QUE pour un petit nombre de logiciels... Comme pouvant être une facilité de programmation..

Rares comme :

• les suites bureautiques
• les environnements de dev
• les studios de montage vidéo
• les OS
• les outils de supervision industrielle
• les jeux vidéos
• les softs embarqués dans nos téléphones portables
• les compilateurs dont plus aucun n'est développé en mode procédural
• etc...

Mais la logique et la facilité de pensée, modélisation, et programmation, est souvent plus du côté du "procédural", manipulant des objets, que des objets effectuant des actions...

Cela dépend beaucoup du penseur. Einstein disait : « Quand on a marteau dans la tête, on voit tous les problèmes en forme de clou. » Quelqu'un "procédural" fera des systèmes procéduraux, quelqu'un "objet" fera des systèmes objet.

Il est aussi facile de modéliser un traitement d'image par une série d'actions appliquées sur des objets que l'inverse.

Dès lors que le traitement en question consiste en de la reconnaissance de forme, une approche procédurale me parait une perte de temps et d'énergie, d'ailleurs beaucoup de labo privés traitent le problème par des approches OO et SMA (Systèmes Multi Agents)

La réelle question est: "Faut il couper un cheveux en quatre pour faire créer un modèle 100% OO ?".
J'ai tendance à penser que cela n'est pas pertinent. Cela ne se justifie pas forcément au niveau productivité, au niveau de la lisibilité et encore moins au niveau de l'optimisation. Creer un modèle 100% OO, pour créer un modèle 100% OO est de l'ordre de la masturbation intellectuelle.

Tout à fait d'accord, d'ailleurs, créer un modèle 100% procédural pour créer un modèle 100% procédural, est tout autant masturbatoire.

Dans les gros projets avec des équipes importantes et beaucoup de débutants, il est important de repérer les composant qui seront développés par tel ou tel développeur en fonction de sa sensibilité et des exigences de maintenabilité, testabilité, évolutivité,... dont fait l'objet le composant

C'est bien le problème : cette "mode" du OO voudrait que tout soit OO pour le fait d'être OO...

Le but d'un bon soft c'est primo de bien fonctionner, et secondo d'être facile à maintenir..

A partir du moment où ces 2 conditions sont remplies, peu importe comment il a été fait ou sur quel paradigme il se base...

Les gens qui te font ces remarques ne sont pas des "professionels", à mon sens, mais des gens avec des oeillères..

Tout à fait d'accord. Cependant, s'il est possible d'avoir une bonne idée du bon fonctionnement (tests unitaires avec couverture de code, tests d'acceptance), c'est beaucoup plus coton pour ce qui est de la maintenabilité. Quelqu'un qui pense procédural trouvera un système OO compliqué et difficilement maintenable et quelqu'un qui pense OO trouvera le système procédural compliqué et difficilement maintenable.

Et pour ce qui est des oeillères, elles dépendent de la capacité à adopter le point de vue de quelqu'un qui pense différemment de soi, bref c'est de la tolérance. Et je suis d'accord avec toi, ce n'est pas professionnel, toute conception qu'elle soit OO, procédurale ou autre, est valable dès lors qu'elle se justifie de manière factuelle.

moi je crois encore plus en l'absence de paradigme

Ayant appris sur le tas, un "paradigme" est pour moi un truc de théoricien..

Le seul "paradigme" auquel je crois c'est que toute norme est mauvaise, car elle est (à 99%) prise à la lettre, alors que ce n'est censé être qu'un guide...

Ben, un paradigme c'est un système de pensée... http://fr.wikipedia.org/wiki/Paradigme. Là où il y a une pensée, il y a un paradigme. Les systèmes politiques, les organisations humaines, les religions et les systèmes informatiques se construisent sur des paradigmes. L'important est de détecter lorsque l'on est dans l'un ou dans l'autre parce que les règles, les façons de faire changent.

Pour ce qui est des normes, elles sont là pour faciliter les choses. Un exemple : tous les téléphones vendu depuis quelques temps ont des chargeurs standardisés. Le chargeur d'un Samsung fonctionne sur un HTC, etc... bon çà marche pas pour les iPhones mais Apple paie des amendes pour préserver sa connectique non-standard.

Ce qui me déçoit beaucoup en info, c'est que ce qui devrait être du domaine de la Recherche et d'équipes de chercheurs tombe très souvent dans les formations, et donc sur le "marché"... Autant je peux comprendre qu'en médecine un nouveau médicament soit immédiatement mis sur le marché et/ou enseigné, autant dans des sciences plus éloignées de la santé, j'ai beaucoup de mal à comprendre.

En fait, c'est plutôt l'inverse : çà tombe d'abord dans le marché quand le marché juge de l’intérêt puis çà tombe dans les formations. Et Dieu merci, heureusement que les nouveaux médocs ne sont pas mis immédiatement sur le marché. J'ai travaillé pour des organisations qui sont chargées de contrôler la conformité des nouvelles molécules avant mise sur le marché et je peux dire que ce n'est pas immédiat.

Au final, et quoi qu'on en dise, notre cher bon vieux PC (ou MAC suivant les cas) est encore basé sur 2 principes de base : le binaire et Von Neumann.
Donc toutes les couches OO et consors ne sont à mon avis qu'une façon certes élégantes mais artificielle de piloter la logique d'un soft. [...] Autrefois, des gens faisaient des applis en BASIC, ou en COBOL ou en PASCAL. [...] au final, on obtient pas de l'assembleur parfaitement PAS OO ?

Tout à fait d'accord pour le binaire et Von Neumann mais il est des systèmes que l'on ne peut se permettre de développer sur ces principes (qui a déjà développé un site web en assembleur ?)
Pour ce qui est des couches OO et consors, elles sont toutes autant artificielles que le binaire et Von Neumann : toute construction humaine n'est-elle pas artificielle (valable pour les systèmes politiques, religieux, informatiques,...) ?

Juste une comparaison imagée
Pour faire une paella il faut du riz, des fruits de mer, des epices,...
Le riz, c'est quoi ? c'est un féculent qui contient des protéines, des glucides, des fibres, du phosphore,...
Le phosphore, c'est quoi ? c'est un élément chimique dont le numéro atomique 15.
C'est quoi un atome ? c'est la plus petite partie d'un corps simple pouvant se combiner chimiquement avec une autre, constitué d'un noyau et d'un nuage électronique
Ok, et le noyau ?
Bon après on en vient à parler de protons, neutrons, quarks, gluons et compagnie et on a le vertige.

Tous ces éléments cités constituent le monde tel qu'on le connait et sont stratifiés (en info, on parle de couches) dans des mondes très différents avec des lois différentes (on pourrait parler de paradigmes (cuisine, chimie moléculaire et organique, physique nucléaire,...). Ces couches sont super intéressantes : je ne dois pas être un spécialiste de la physique quantique pour faire une paella. Sympa, non ?

On a le même vertige lorsqu'on se dit qu'un jeu vidéo comme Assassin's Creed est le résultat d'un séquencement d'instructions élémentaires dans le micro-code embarqué dans les CPU et GPU. De tels softs ne peuvent se développer que parce qu'il y a des couches qui démarrent avec le hardware et qui finissent avec des objets animés eux mêmes en interaction avec des moteurs de rendu 3D, des moteurs physique, des moteurs d'IA,... Ces derniers sont construits avec des composants logiciels qui eux-mêmes se décomposent en objets interagissant ensemble.

Si des jeux comme Pacman peuvent être développé en procédural (j'en ai développé un quand j'étais jeune), ce n'est plus le cas avec les jeux d'aujourd'hui non pas parce que c'est impossible mais tout simplement parce que ce serait trop cher. Combien coûterait une paella en partant de la physique quantique ? combien de temps faut-il attendre pour manger ?

En résumé par rapport à OO vs procédural, il y a du procédural dans l'OO mais il y a aussi des concepts de haut niveau comme le polymorphisme et autres. Ces derniers permettent de construire des abstractions qui constituent des systèmes plus complexes, plus interactifs, plus ergonomiques. Comme cela a été dit dans les différents posts, on peut simuler en C le polymorphisme avec des pointeurs de fonctions et des pointeurs de pointeurs, des macros, etc... mais c'est plus long à écrire et lire, à comprendre, à modifier, il est aussi plus difficile de trouver des personnes compétentes pour monter une équipe projet.
La quantité d'OO par rapport au procédural (si tant est que cette notion de quantité ait un sens) dans un système dépend de la maturité des développeurs et de l'effort que cela leur demande pour le concevoir et le développer.

[souviron34]

je ne répondrais pas sur tout - ni l'envie ni le temps - tellement ton post est orienté...

La quantité d'OO par rapport au procédural (si tant est que cette notion de quantité ait un sens) dans un système dépend de la maturité des développeurs et de l'effort que cela leur demande pour le concevoir et le développer.

Donc selon toi un développeur "mûr" va forcément évoluer vers le OO ??

Je ris....


Quant aux billevesées sur "la maîtrise de la complexité passe par le polymorphisme" et autres "Il y a ne serait-ce que 10 ans, on aurait dit que c'est de la science fiction", ou "Dès lors que le traitement en question consiste en de la reconnaissance de forme", ils montrent simplement une ignorance crasse de ce qui se faisait avant...

Tes exemples sur Android sont simplement dûs au fait que la majorité des gens maintenant - ici - a un smartphone.. Mais dans les années 80 et 90 cela se faisait aussi, avec ce qui à l'époque s'appelait des "pagets" ou "pager", et mais leur utilisation était restreinte aux gens en ayant réellement besoin... Et pour infos sur tous les OS SAUF Windows les sockets étaient asynchrones depuis le début des années 80... Et donc les serveurs/services surveillaient en temps réel des arrivées sur les ports et pouvaient prendre des dcisions tels qu'envoyer des messages, le tout en C, Fortran , Pascal, ou n'importe quoi, avec des programmes conçus en procédural...

Bref, tes arguments pourraient être intéressants si ils n'étaient pas aussi orientés et basés sur des conceptions fausses (en particulier par rapport à l'historique)

Je ne répondrais donc pas plus...

[I_believe_in_code]

Quand j'ai commencé mes études d'informatique (1998-1999), l'OO était le monothéisme à la mode. Je n'avais auparavant fait que du procédural impératif et j'ai accroché tout de suite à l'OO, devenant moi-même fanatique du truc. Heureusement, nos profs avaient équilibré leurs contenus pédagogiques pour qu'il n'y en ait pas que pour l'objet.

Quelques années plus tard (je dirais qu'il a bien fallu attendre 2003-2004), j'en suis un peu revenu, de la POO. Quand je programme je fais ce qu'il y a à faire avec un soucis de correction, de maintenabilité et de performance. Savoir si mon code tient, au final, plutôt de tel paradigme ou de tel autre n'a aucune importance ; cela dépend bien évidemment des projets et de mon évolution intellectuelle.

[rimram31]

L'approche de skip en tout début de post n'est pas "son" approche mais celle utilisée par tous et qui, bien heureusement, n'utilise pas la vision "puriste" de l'OO. Un exemple tout bête, si on suivait a la lettre l'OO, un pattern comme un MVC serait une aberration et en poussant le bouchon plus loin, il faudrait n'utiliser que du polymorphisme en lieu et place des délégations.

Bâtir son architecture sur des objets simples, voir même simplistes, séparer les responsabilités et orchestrer le tout avec d'autres composants, heureusement que nous n'avons pas écouté l'OO a la lettre et avons découpé en tranche les objets en layers réduisant par la même la complexité relative a intégrer lors de tout changement.