Non

Question : Y a t'il des Frameworks qui n'utilisent pas la POO ?

J'ai commencé un projet en MVC, ça m'a beaucoup compliqué, du coup sur un autre je voulais pas utiliser cette architecture mais je me suis rendu compte que c'était assez indispensable.

C'est 1000 fois plus clair.

@Starkdop : sans doute mais quel est l'intérêt ?

Tout se qu'on peut faire en POO, on peut le faire en procédurale et inversement.

C'est juste une façon de coder.

On va dire que j'ai un peu de mal avec la POO.
J'aime bien quand c'est des fonctions moi

Entre une méthodes d'un objet et une fonction y'a pas énormément de différence

J'entends bien, mais la plupart des frameworks PHP sont en POO de nos jours. J'attends impatiemment la sortie de Drupal 8 qui implémentera des briques de Symfony. D'ailleurs, il faut que je me mette à Symfony.

Starkdop
Posté le 23 septembre 2012 à 12:21:42
On va dire que j'ai un peu de mal avec la POO.
J'aime bien quand c'est des fonctions moi

Dis toi qu'une classe en POO c'est comme si tu nommais tes fonctions en procédurale comme ceci:
Membre_ajouter() , Membre_supprimer() , Membre_modifier().

Alors qu'en POO t'aura une classe Membre avec à l'intérieur des méthodes (donc des fonctions) ajouter(), supprimer(), modifier().
Mais que pour y accéder faudra une étape en plus (instancier ton objet, sauf pour les méthodes statiques).

J'étais comme beaucoup encore un vieux de la vieille éduqué au procédural !!! Et la POO, je ne m'y suis mis que depuis très peu de temps (incité par Symfony, entre autres) non sans difficulté car on garde des réflexes du passé.
Ca fait 15 ans qu'on me parle de l'objet et je ne comprenais rien à l'intérêt de cette "révolution".

Eh bah oui, parce que ce n'est tout bonnement pas une révolution : on code toujours pareil depuis l'invention de la puce MAIS on s'organise autrement... et c'est là la seule valeur ajoutée de la POO et du MVC, partager le travail, réutiliser ce qui a été fait avec le minimum d'apprentissage... les objets sont comme des services administratifs qui s'entremêlent : on voit ce qui entre dedans et ce qui peut en sortir, et on a en théorie plus à se soucier de comment ça fonctionne à l'intérieur !!!

Donc pas de quoi se pavaner... la maîtrise de ce mode d'organisation s'appelle aussi le conformisme !!! Et quand on voit l'état du service public (rapport aux services administratifs opaques), on peut avoir des doutes sur l'efficacité à terme de la POO : dupliquer de mauvais concepts très rapidement pourraient nous coûter chers au final.

Mais dans l'immédiat, dans l'intérêt de l'industrie du développement et le peu d'implication des salariés sur le long terme dans une entreprise donnée, c'est indispensable d'avoir des développeurs standardisés, interchangeables en limitant les risques de perte de garantie de bon fonctionnement sur les applications existantes.

Si vous comptez travailler toujours seul, choisissez votre méthode sans vous soucier de rien... si vous comptez faire grossir votre projet, adoptez la POO pour établir une compatibilité avec le marché actuel OU créez la future organisation qui fédérera les prochaines générations.

Eh oui, on ne peut pas avoir un avis sur la programmation sans faire de la politique... quoiqu'en dise les ingénieurs !

Je m'auto-insulte :
"quoiqu'en disent" évidemment, et "cher" plus haut
Voilà ce qui arrive quand on se relit avec publication.
Imaginez si vous utilisiez mes classes d'objets ????

La standardisation du code et la séparation logique des couches se fait très bien en procédural. On parle pas mal d'effet de mode sur mon salon irc et j'ai tendance à penser la même chose. Cependant, pour écrire du code sur de gros projets avec notamment Symfony, on est plus ou moins contraint d'en faire un jour. Mais au final il y a ceux qui vont écrire des classes et ceux qui vont faire de l'objet…