Certains clients sont à juste titre souvent réticent à passer à du tout objet, notamment en PHP.

De mon point de vue, le débat n'est pas forcément POO ou Procédural (même si, je l'avoue je suis un POO-convaincu), mais plutôt, industrialisés/rationnalisés/maîtrisés/testables/bouchonnables versus "non homogènes, non-bonnes pratiques,non cadrés, non-testable".

L'implémentation POO que je propose en règle général de mettre en place à mes clients correspond dans une certaine mesure à une compilation de fonctions rangées par groupes qui correspondent à des classes et des packages (répertoires).
Concrètement il ne s'agit pas de POO pure mais plutôt d'une forme de POO "allégée" avec des fonctionnalités de procédural (ex: une classe "PliService" qui contient une liste de méthodes listPlis(), getPlis(), deletePli($pliId), addPli($pliInfos), ...) en POO pur on aurait plutôt eu une classe "Pli" avec les méthodes "save(), delete(), check(), send()...".
Les avantages induits, sont qu'étant en programmation objet (même non puriste), nous pouvons bénéficier d'un certains nombre de design patterns pertinents tels que Adapter, Mock, Singleton, MVC... et bien sûr ne pas réinventer la roue et utiliser des composants tout fait tels que ceux proposer par ZF (ou d'autres frameworks) et pouvoir les étendre facilement pour les adapter à nos besoins (pas possible en procédural).

D'autre part, je suis loin d'être omniscient, mais je ne connais aucune librairie ou framework, développée récemment ou activement développée (en dehors de produit sur étagère bien spécifique) qui soient full procédural, tous sont POO-enabled, a priori, cela marque bien la mouvance actuelle que prend PHP pour sa professionnalisation.

Au delà de POO versus procédural, les questions concrètes auxquelles il faut répondre sont :

  • comment j'organise mes fichiers
  • comment je factorise mes fonctionnalités
  • comment je rend testable / bouchonnable mes fonctionnalités
  • comment je séparer la logique, du rendu, comment j'utilise une seule fois la logique pour plusieurs rendu différent
  • comment j'interface les outils de tests fonctionnels exécutables (une NECESSITE pour les fonctionnels et donc pour ceux qui motivent les développements)
  • comment je garanti qu'un nouveau développeur pourra prendre en main n'importe quelle partie du code sans trop de douleurs
  • comment je garantie qu'il n'y aura pas de collision de nommage entre mes fonctionnalités
  • comment je garantie que mes développeurs ne seront indépendants et ne s'interbloqueront pas mutuellement dans leur développement (i.e. travailleront sur des fichiers différents)
  • comment je package mon application pour qu'elle soit facilement déployable sur un environnement de production différent de l'environnement de développement
  • comment j'intègre mon code à une usine de développement de type intégration continue
  • comment je garantie que mes développeurs peuvent à tout moment exercer leurs connaissances précédemment acquises sans forcément avoir assimilé tout les concepts, frameworks, librairies, techniques, méthodes (what ever you want), qui composent la stack applicative et de pratiques mises en place pour les développement.
  • comment je capitalise sur mes développements pour tout mon parc applicatif (pas seulement que pour une seule application)
  • ... (j'ai de multiples questions de ce type encore...)

De mon point de vue, POO-allégée (celle que je propose au quotidien à mes clients), permet avec tout un tas de conventions (que je propose aussi à mes clients) de répondre à la majorité de ces questions. Une utilisation procédurale-exclusive de PHP avec des conventions adaptées pourraient je pense répondre positivement à pas mal de ces questions, toutes je ne sais pas (admettons, je n'ai pas essayé), elle irait juste à rebrousse-poil de tout ce que la communauté PHP met en oeuvre depuis l'arrivée de PHP 5 (et des iterators, des exceptions, des interfaces, des classes, ...).

Petit rappel, en PHP, contrairement à Java, TOUT N'EST PAS OBJET, ce qui veut dire que finalement si on fait des classes et objets, à l'intérieur de leurs méthodes, ce sont des fonctions (procédurales) qui sont utilisées (toutes la batteries de fonctions très fournies que PHP propose en standard). La structuration en classe, est donc une coquille qui permet de s'organiser et de rendre plus clair la modélisation et la séparation de responsabilité (MVC et autres joyeusetées).

Zend Framework (ou Symfony dans une certaine mesure) n'est finalement qu'une implémentation de tout un tas de design patterns (i.e. de réponses à des problèmes connus, traités une bonne fois pour toute), ne pas utiliser ni Zend Framework, ni tout autre framework, reviendrait à faire une croix sur les solutions aux problèmes communs déjà trouvés par toutes les communautés.
Une limitation cependant, tout framework "généraliste" prend sa force dans la généralité, pas dans l'adéquation à des besoins spécifiques (tels que la performance, la finesse, l'exhaustivité...). Il est donc très souvent nécessaire de se poser la question "Pour ce besoin précis, dois-je prendre tel composant de tel framework ou dois-je mettre en oeuvre mon propre développement ?", la réponse dépend du contexte, 8 fois sur 10, il ne sera pas nécessaire de redévelopper votre propre composant, ceux déjà existant suffiront (et seront éprouvés / matures / stables / documentés / utilisés contrairement à vos éventuels développements à mener), mais 2 fois sur 10, les composants spécifiques montreront leurs limites et vous devrez créer le vôtre aux petits oignions. Faire une croix sur la POO et/ou les frameworks existants vous pénalisera dans 8 cas sur 10, et ne vous aidera pas non plus dans les 2 autres cas sur 10 (c'est dommage, vous êtes dans le monde de l'open source avec PHP, vous auriez pu prendre/étendre/réutiliser/améliorer) il faut en être conscient. Il est possible alors de créer son propre framework (c'est peut être ce que certains ont fait), pourquoi serait-il mieux qu'un framework téléchargé plus de x millions de fois, financé par Google, Adobe, IBM,... et utilisé chez de plus en plus de grand comptes entre autres français ?

Le grand débat dans les grands comptes est souvent ZF ou Symfony, jamais POO ou Procédural (en tout cas chez ceux que j'ai eu la chance de croiser jusqu'alors), mais bon pourquoi pas, c'est peut être les autres qui se trompent me dira-t-on...

Et vous, la communauté, quel est votre point de vue ?

PS: PHP 4 n'est plus supporté depuis plus d'un an, si vous développez procédural only, n'oubliez pas de mettre à jour vos pratiques pour être au moins compatibles avec les bonnes pratiques de développement procédural en PHP 5 ;)