Re: L'orienté objet c'est surfait

il y a aussi des limites à cette façon de procéder.

Il n'existe pas de panacée, clairement, cependant dans le cas de l'objet vs impératif, je dirais que l'objet est une évolution de l'impératif, et que la plupart des bibliothèques de fonctions C essaient de mimer au maximum (des capacités du C, qui sont très, très limitées) l'objet.

Par exemple, en C il y a typiquement des structures, qui ont chacune un jeu de fonctions dédiées, dont à minima une pour les initialiser, et une autre pour les détruire: il faut juste systématiquement penser à les appeler (aucun mécanisme de création ou destruction automatique), ce qui est une vraie cause de bugs (il est nécessaire d'être plus concentré pour écrire du C correct que pour écrire du C++ correct, et c'est vrai avec bien d'autres langages (que C requiert plus de concentration)). Ça rend l'écriture laborieuse, mais aussi la lecture et, pire, la maintenance.

D'un autre côté, la bibliothèque standard du C++ (langage multi-paradigme dans le sens ou, contrairement à du java par exemple, il n'y a pas besoin de se battre contre la syntaxe pour utiliser du code non-objet) la tendance est à réduire (et unifier) la richesse des interfaces objet de façon a avoir plus de fonctions, qui en fait exploitent implicitement l'interface des objets, de manière uniforme.

Pour essayer de faire plus clair, et en reprenant l'exemple de la DEL plus haut, on pourrait avoir:

class clignotant
{
public:
 virtual void allumer() =0;
 virtual void eteindre() =0;
 virtual bool actif() const =0;
};
class led : public clignotant {
private:
 pin_t m_broche;
 colour_t m_couleur;
 bool m_active;
 void actualiser() { m_broche = m_active ? 0xDEAD : 0xBEEF; }
public:
 void allumer() override { m_active = true; actualiser(); }
 void eteindre() override { m_active = false; actualiser(); }
 bool actif() const override { return m_active; }
};
void clignoter( clignotant& cible )
{
 if( cible.actif() ) { cible.eteindre(); return; }
 cible.allumer();
}

Et avoir clignoter à l'extérieur, comme une fonction générique. L'avantage de la sortir de l'objet, c'est qu'on peut dès lors lui passer des objets d'un type différents, mais qui peuvent aussi clignoter, a condition d'exposer la même interface (je n'ai pas d'exemple en tête pour compléter celui-ci).

Ce type de choses est impossible à faire proprement en C ou en java, puisque ces langages étant mono-paradigmes (enfin, pour java, c'est plus nuancé (templates), et ça a peut-être changé, mais je me souviens qu'il était nécessaire de faire une classe avec une méthode statique pour la fonction main(), obligatoire pour lancer un programme, ce qui montre le ridicule du purisme et n'est pas propre...).
Dans le cas de Java, tout doit être dans un objet, quitte a être déclaré statique.
Dans le cas du C, il n'existe pas de possibilité d'attacher un type utilisateur à une interface, d'une part, et d'autre part, en C, les arguments d'une fonction ne font pas partie de la signature de la-dite fonction, ce qui mène à ce genre de code:

double round(double x);
float roundf(float x);
long double roundl(long double x);

Il faut donc appeler une fonction différente selon le type de variable que l'on passe (c'est particulièrement criant quand on utilise opengl).

Malgré que l'exemple soit particulièrement trivial, on voit déjà plusieurs problèmes, qui sont certes contournables dans les langages cités, plus ou moins proprement, mais qui restent une charge mentale pour le développeur.

Mon point n'est pas de dire que C++ est meilleur, loin de la, juste, je considère que l'objet est une amélioration de l'impératif, qui, selon les langages, peu permettre d'avoir un code plus simple à maintenir sur le long terme, à condition de ne pas en abuser. Ce qui a été fait, encore et encore, et typiquement, les outils que je vois qui sont issus du début des années 2000 ou des 1990, sont bourré de l'idéologie "full-object" ce qui en rend souvent le code lourd, complexe, et ironiquement, peu réutilisable.

D'un autre côté, un langage comme prolog sera radicalement différent, et permets d'écrire certaines parties des programmes bien plus efficacement (en terme de temps passé à écrire le code, en tout cas) puisqu'au lieu de décrire ce que le programme fait, pas par pas, on décrit les règles qu'il doit appliquer à des données.
Je sais que ça a l'air similaire, mais ça ne l'est vraiment pas, je ne sais pas trop comment l'expliquer mais on laisse en fait le programme décider lui-même dans quel ordre il appliquera les règles.

Prolog est "un langage de programmation logique" selon wikipedia, et on peut vraiment parler de paradigme différent, du fait que la façon de réfléchir pour obtenir le programme final est vraiment différente, bien plus que dans la guéguerre impératif vs objet (qui gagnent de toute façon a être utilisés ensemble, et non l'un contre l'autre).