Discussion :

[grinder59]

Bonjour,

Je me pose une petite question concernant la conception de mon application.

J'ai plein de petites fonctions "couteau suisse" : formatage de date, manipulation de strings, affichage conditionnel de balises... :

Jusqu'à présent, toutes ces fonctions se trouvaient dans un fichier de fonctions...

J'ai entrepris de ramener ces fonctions dans une classe DAO, et pour la très grande majorité d'entre elles, je les déclare static afin de pouvoir les appeler de n'importe où et sans devoir instancier ma classe DAO.

Y'a-t-il un intérêt ? Si oui lequel, car je me demande si j'ai pas perdu du temps et si mon fichier de fonctions n'était finalement pas si malcommode que cela !

merci de votre aide !

[Fench]

Bonjour,

Je ne comprends pourquoi tu parles de DAO alors que tes fonctions sont de petits utilitaires qui n'utilisent pas d'acces aux données de la base.

Tu aurais du les laisser dans un fichier d'utilitaires ou voir même plusieurs fichiers contenant chacun une même classe d'utilitaires (au passage, il existe maintenant une classe Date).

Edit: j'espère que l'USAP va aller mieux dans les prochaines semaines (quoique je préfère l'ASM)

[grinder59]

DAO, c'est le nom de ma classe, rien de plus. J'aurai pu l'appeler Toto... (apparemment, je l'ai mal nommée )...

Tu aurais du les laisser dans un fichier d'utilitaires ou voir même plusieurs fichiers contenant chacun une même classe d'utilitaires

Si je comprends, tu me conseilles de faire une ou plusieurs classes comportant des méthodes "utilitaires" d'un même sujet (date, calcul...) ?

j'espère que l'USAP va aller mieux dans les prochaines semaines

Faut dire que le calendrier ne leur est pas super favorable. Mais ils ont une belle équipe et particulièrement 2 centres de folie (Mafi / Piukala), ils devraient remonter rapidement (en supposant que la guigne des blessés s'arrêtent)

[Fench]

DAO, c'est le nom de ma classe, rien de plus. J'aurai pu l'appeler Toto... (apparemment, je l'ai mal nommée )...

C pour celà que tu as eu peu de réponses, les gens ont vu DAO et sont partis en courant s'ils ont pensés au DAO comme autocad ou aussi au DAO pour implémenter une nouvelle couche d'orm comme doctrine par exemple. Bref hard.

Si je comprends, tu me conseilles de faire une ou plusieurs classes comportant des méthodes "utilitaires" d'un même sujet (date, calcul...) ?

Excuses-moi, je voulais dire pas de classe mais de fichier avec des include_once en fonction des utilitaires demandé, pour moi, je laisserais tomber l'idée de passer par ta méthode si tu restes sur des petites fonctionnalités.

Pour l'USAP, effectivement pas de chance sur les blessés , je vous souhaite de remonter mais pas trop vite et pas au dessus de l'ASM

[grunk]

Si tu as un ensemble de petite fonctions utilitaire sans réel rapport , c'est pas non plus une mauvaise idée de les garder sous forme de fonctions et d'inclure ce fichier de fonctions là ou tu en as besoin.

Faire des classes "helper" static n'a de sens que si tu peux regrouper un nombre de fonctions conséquent dans un même helper

[grinder59]

OK merci du conseil...
Je vais donc regrouper les méthodes utilitaires par catégories, les mettre dans des fichiers de fonction à inclure au besoin...

Petites questions subsidiaires :

J'ai une classe Ecriture qui permet de définir une écriture à facturer (taux, temps, dossier à laquelle elle appartient, devise, personne qui facture...).

L'un des écrans de mon application est l'affichage d'une ensemble d'écritures.

Pour le moment, j'ai créé une classe Application avec la méthode AfficheEcriture() qui boucle sur les résultats d'une requête SQL, mais je me demande si c'est bien la façon la plus simple et pratique de faire ?

Déjà, à chaque ligne de ma requête, comme il ne s'agit que d'affichage, ai-je vraiment intérêt à instancier Ecriture ? De plus, n'est-il pas plus logique de mettre la méthode AfficheEcriture dans la classe Ecriture ?

Merci encore de tes conseils !

---

Clermont, Toulon et Toulouse sont largement au-dessus. L'USAP se battra avec Castres, le Racing et le SF pour une place en Hcup et se sera déjà pas mal... Mais perso, j'ai vraiment aimé la façon dont il se sont défoncés jusqu'au bout à Clermont malgré les blessures, le score... et avec un excellent état d'esprit... On était loin des chamailleries Le Corvec / Cudmore... pourvu que ça dure !

[grinder59]

Faire des classes "helper" static n'a de sens que si tu peux regrouper un nombre de fonctions conséquent dans un même helper

Ok, mais quel est, dans ce cas, l'avantage d'une classe de méthodes static sur un fichier de fonctions ?

[Fench]

Je laisse de côté la classe 'helper', je connais pas trop ...

Déjà, à chaque ligne de ma requête, comme il ne s'agit que d'affichage, ai-je vraiment intérêt à instancier Ecriture ? De plus, n'est-il pas plus logique de mettre la méthode AfficheEcriture dans la classe Ecriture ?

Pour l'affichage, tu peux rester sur chaque ligne d'une requête sans passer par les classes ... Pour la méthode, bien que nous ne connaissons pas ta méthodologie, comme ça à vue sur le nom, je prendrais une méthode AfficheEcritures (avec le s) dans la class Apllication pour passer en revue toutes les écritures et puis une méthode AfficheEcriture dans la class Ecriture pour effectivement un affichage propre.

Pour le Rugby, je donne bien Toulon pour une bonne saison (à voir), maintenant pour l'usap, je dirais que le B.O sera dur à passer.

[grinder59]

En effet,
Application::AffichageEcritures et Ecriture::AffichageEcriture seraient logique.
Maintenant cela nécessite d'instancier Ecriture pour chaque résultat de la requête... Pour un simple affichage, je trouve cela très lourd, d'autant que l'affichage des écritures reste sensiblement identiques pour tous les résultats...

A moins d'utiliser mysqli_fetch_object... à réfléchir...

---

Moi aussi je vois bien Toulon ! Ils sont vraiment énormes cette saison... En espérant que la concurrence Michalak (recruté comme ouvreur) / Wilko ne joue pas en défaveur de l'équipe...

[grunk]

Ok, mais quel est, dans ce cas, l'avantage d'une classe de méthodes static sur un fichier de fonctions ?

Dans une application full objet , avoir des classe static permet de profiter de l'autoloader et de rester dans l'esprit de l'application.

[grinder59]

...profiter de l'autoloader...

ok, merci !

[Fench]

En fait, si tu veux utiliser un affichage Html sur un simple tableau contenant les lignes des écritures, restes sur un affichage ligne à ligne sans passer par tes classes. Sinon, pour l'utilisation transparente dans l'application pour un affichage dédié aux écritures tu peux utiliser les deux méthodes comme tu as dis. Les méthodes contiendront tout pour l'affichage et la gestion des écritures dans la base (ça ressemble un peu aux beans dans Java) en fait tu auras une collection d'objet ecriture en mémoire et dans le controleur tu pouras aisement modifier les objets puis sauver toute la collection.

Dans ton cas je pense que la première solution est la mieux,

[grinder59]

Dans ton cas je pense que la première solution est la mieux,

Je le pense aussi, même si je vais me laisser le temps de la réflexion...

Merci !

[gene69]

oui

et en même temps ya des gens qui critiquent ça. mais moi je n'y vois pas de mal de détourné l'autoloader pour ça. y avait une actu pour ça. moi j'aime bien les classes sac à fonction.

[GrandFather]

Il y a quand même deux arguments qui peuvent inciter à préférer la class « Helper » au fichier de fonctions à inclure.

1) regrouper un ensemble de fonctions sous forme de méthodes statiques d'une classe « helper » revient à leur attribuer explicitement un espace de noms, et à diminuer les risques de conflits de noms. Exemple :

Code :

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

MyHelperClass::myMethod();

2) On peut factoriser du code de ces méthodes statiques dans une autre méthode sans qu'elle ne soit appelable, il suffit de la déclarer private dans la classe (elle devra par contre être également déclarée static). Exemple:

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
16
17
18
19
class MyHelperClass {
 
public static function a() {
  ...
  self::c();
  ...
}
 
public static function b() {
  ...
  self::c();
  ...
}
 
private static function c() {
  ...
}
 
}

Dans un simple script contenant les fonctions, la fonction c() pourrait être appelée alors qu'elle n'est pas censée l'être.

[grinder59]

Arguments intéressants, merci à tous !