Structures des fichiers à inclure

Bonjour à tous
Premier post de ma part depuis la bêta ouverte de ZdS. Comme cela m'arrive de temps en temps, j'ai des interrogations (plus ou moins poussées…) sur la programmation. D'habitude j'allais les poser sur SdZ (puis sur OC).

Ma question du moment est : Vaut-il mieux avoir un seul gros fichier avec toutes mes fonctions, ou un fichier par fonction? (avec du PHP)

Voilà

J'aurais tendance à dire qu'un gros fichier vaudrait mieux question performance pour l’accès disque (encore que si les minifieurs PHP existent pas, c'est qu'il doit pas y avoir une grosse différence question accès disque).

Ok, merci
Si c'est la même chose question performance, je crois que je vais opter pour la solution avec un seul fichier.

Je plussoie ( ) grandement LoupSolitaire, le classement par thèmes est une bonne pratique, il est même envisageable, pourquoi pas, de les réunir dans des classes, sans pousser très loin la conception objet, des méthodes statiques sont souvent pratique…

Exemple :

1

FonctionsDate::Time2Fr(1405734954);

Merci à vous deux
Je vais voir comment je peux découper mes fonctions en plusieurs parties, mais j'ai déjà une idée.

Oh que non grand fou ! Ca n'a pas de sens de faire des classes / objets qui n'ont pas de sens, à part "répertorier les fonctions". Enfin, c'était cool… A l'époque de PHP 5.2. Mais maintenant, y'a les namespaces qui remplissent par-fai-te-ment ce rôle…

Salut,

je ne suis pas d'accord. Déjà je ne vois pas en quoi les namespaces sont liés à l'utilisation de méthodes statiques, les namespaces servent à éviter les collisions de nom de classes/fonctions et oui, il faut les utiliser, mais ça n'est pas en rapport avec le fait d'utiliser des méthodes statiques, d'ailleurs on peut utiliser des namespaces dans tous les fichiers php.

Une classe thématique (IO, Strings…) composée de méthodes statiques qui ne sont pas liées entre elles, ne nécessitent pas d'instanciation d'objet et utilisables comme des fonctions est parfaitement raisonnable, d'ailleurs un paquet de frameworks le font. Regrouper ses fonctions comme des méthodes statiques dans une classe facilite aussi l'utilisation de frameworks de tests unitaires.

Le faisaient, nuance. Enfin, du moins ça reste très episodique, et souvent en tant que stub de fonctionnalités qui ne peuvent être assurées à un moment donné. Et comme je l'ai dit, c'était plus vrai en 5.2. Par exemple, je prends du Symfony ; tu as peut-être 2/3 classes sur l'ensemble qui font ce genre de trucs. Et encore, ce sont des stubs…

Une classe, qui est le modèle d'un Objet, doit correspondre une fois qu'elle est utilisée (instanciée ou non) à un objet justement. Ses méthodes doivent toutes avoir un sens, une action vis à vis de cet objet. Si tu regroupes tes fonctions par thème, c'est comme le nom l'indique… un thème. Pas un objet.

D'ailleurs, tu me cites les tests unitaires… Pour les mocks etc, je veux bien te croire… Mais sauf que tu peux pas mocker une méthode statique, sans installer une extension php ou autre dégueulasseries (cf le lien).

D'ailleurs les méthodes statiques, il faut vraiment en limiter l'usage (déjà parce que c'est pas facilement utilisable en cas d'extension, puis pas facilement utilisable dans un test unitaire), soit à manipuler en effet des données qui sont communes à toutes instance de l'objet, ou la création d'un objet lié justement.

Les namespace sont réellement fait pour ça : en plus d'éviter en effet les collisions, ca permet aussi de regrouper ses classes / fonctions dans des themes.

Là tu es dans la pure idéologie OO désolé. Les méthodes statiques ne sont pas mauvaises, sinon elles ne seraient pas implémentées dans la plupart des langages, ce n'est pas parce que tu crées une classe utilitaire avec des méthodes statiques que tu corromps le sacro-saint modèle objet. PHP est un langage multi-paradigmes, se focaliser sur un seul c'est à mon avis louper beaucoup, beaucoup de choses.

Au passage, ton argumentation sur le fait qu'il faut arrêter de faire du 5.2 me fait sourire, je n'ai pas fait de code pour 5.2 depuis au moins 2008 et je n'ai plus de projet sous 5.3 depuis 2011, 5.3 va d'ailleurs avoir sa toute dernière version en août avec la sortie de 5.6.

Qu'il ne faille pas utiliser de méthodes statiques quand on fait de la programmation orientée objet je peux sans problème en convenir (et encore il y a toujours des exceptions), mais dans ce fil personne ne te parle de faire de l'objet, et non, réunir des méthodes dans une classe n'est pas faire de l'objet. Ce n'est pas parce que des gens ont fait du pseudo objet il y a 10 ans en utilisant des méthodes statiques et ont pondu des horreurs que le principe de réunir des méthodes statiques dans des classes utilitaires est mauvais en soi.

Ah, et je n'ai jamais eu aucun problème pour tester des méthodes statiques, il faut dire que j'utilise Atoum et pas PhpUnit (mais pour être honnête, PhpUnit dans une version récente et une version de PHP actuelle, donc >=5.4, ne doit pas avoir le moindre problème non plus, les problèmes de tests de méthodes statiques, c'était surtout lié au late static binding qui n'a été implémenté qu'en 2009 avec la 5.3).

Puisque tu mentionnes Symfony, je suis allé voir: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Yaml/Inline.php https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Intl/Util/IcuVersion.php https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Intl/Util/Version.php …

j'ai pas eu à chercher plus d'une minute, la première classe sur laquelle j'ai cliqué est une classe utilitaire contenant uniquement des méthodes statiques. Eh oui, Symfony utilise aussi cette technique, et pas du tout marginalement, et ils ont d'ailleurs bien raison d'utiliser toute la panoplie d'outils fournis par le langage.

Au passage tu peux nous expliquer comment faire facilement de l'autoloading de tes fonctions namespacées sans les mettre dans une classe ? L'autoloading ne fonctionne qu'avec les classes, encore une raison pour réunir ses fonctions dans une classe thématique avec des méthodes statiques. Composer offre une solution en permettant l'autoloading d'un fichier de fonctions (il rajoute un require_once dans son autoloader) mais ce n'est pas encore l'autoloader universel et c'est juste beaucoup plus simple de faire une classe thématique. Au passage la classe avec méthodes statiques, c'est l'une des solutions conseillées par Anthony Ferrara (ircmaxell) sur stackoverflow pour cette même question, core dev PHP à qui on doit l'API de gestion des mots de passe et un des plus grands experts en orienté objet de la communauté PHP, comme quoi… http://stackoverflow.com/questions/4737199/autoloader-for-functions

Sinon, tu penses quoi des traits depuis 5.4? Parce que finalement, c'est des classes utilitaires aussi, ça doit te faire hurler

Attention, je n'ai pas dit que les méthodes statiques sont le mal absolu. J'ai même énoncé des cas om ca pouvait être utile. Et pour les trois fichiers de Sf2 que tu me sors : comme je l'ai précisé, y'en a en effet quelques un qui se baladent, mais à genre même pas 1% du total.

Pour l'autoload, oui j'ai bien suivi, mais je pense qu'a la manière qu'on doit quand même inclure quelque chose pour composer (via un include 'vendor/autoloader.php), on fait toujours une inclusion… Après composer peut rajouter d'autres inclusions, dont les fonctions. Mais oui, je reconnais que le manque d'autoloader est marquant.

Concernant les propos de Ferrara, tu observera qu'il nuance les possibilités. Dont le fait de repenser ses fonctions en objet plus approprié, ou le require avant l'utilisation / lors du call global (soit ici composer).

D'ailleurs, ca va en s'améliorant pour 5.6, il y aura également les use func et use const. Ca sera déjà un truc plus propice à l'utilisation de fonction… dans des namespaces.

Les traits, quant à eux, non, pas vraiment des classes utilitaire… Plutôt des bouts de classes. Des bouts qui peuvent être commun à plusieurs classes. Je cite les tests unitaires avec PHPUnit tiens par exemple. Chaque Test doit étendre une classe Framework_TestCase. Deux solutions :

• Faire une classe My_TestCase (en reprenant la casse employée ; sinon pernser PSR0, Composer, … etc), duquelle tous les Test étendront.
• Faire un trait qui regroupe, thèmes à thèmes les helpers … etc, et les utiliser dans les classes de Test. Ce qui je trouve a un plus grand sens, car ces méthodes sont vraiment utilisées, alors qu'en chargeant la classe globale, certaines ne seront aps utilisées.

Voilà comment je vois les traits d'un bon oeil.