Discussion :

[Clorish]

Je me retrouve face a un leger souci de conception.
J'ai une serie d'apis a creer qui touchent plusieurs domaines.
J'hesite entre creer une unitee avec tout un tas de procedures libres effectuant les traitement ou les regroupper par theme dans des classes abstraites contenant uniquement des methodes de classes.

L'avantage de la 2e solution est d'eviter un prefixe thematique a chaques nom de procedures, et d'effectuer un "tri" sur les procdure grace a la completion automatique du code par Delphi.

Par contre, je me demande si c'est vraiement interessant d'utiliser ce type de codage pour juste une ergonomie dans l'ecriture du code ?

Quels sont vos avis et avangtages/inconvenient de ces 2 methodes ?

Merci

[Paul TOTH]

personnellement, je ne trouve aucun intérêt aux classes de ce type, la complétion de code fonctionne très bien avec les noms d'unité.

donc si le soucis est juste là, je ferais une série d'unités regroupant les fonctions par thèmes.

[sjrd]

Je suis assez de l'avis de Paul Toth. C'est ce que je fais en général.

Il m'est toutefois arrivé, une fois, de créer une classe utilitaire comme tu la décris. J'ai fait cela parce qu'en fait, cette classe fournissait des méthodes un peu "add-on" à la classe TStrings. Je sais qu'il existe maintenant les class helpers, qui sont prévus pour, mais ce devait être compatible Delphi 4, donc...

Donc je crée une classe utilitaire lorsque je travaille, dans toutes les méthodes, sur un type d'objet bien particulier, pour ajouter à sa classe des méthodes supplémentaires.

Mais dans le cas de mini-SDK, je préfère nettement les routines dans des unités

[Clorish]

ok merci
C'est bie nce qui me semblais. Je prefere aussi les routines point de vue execution .. mais les classes point de vue codage semblait interessantes.

Pour ce qui est de la separation en unitees c'est vrai que ca marche aussi. J'utilise souvent (et dailleur comptais encore l'utiliser) la completion via le nom d'unitee. D'ailleur ca evite aussi pas mal de soucis en cas de methodes portant le meme nom

Par contre cette (ces) unitees seront developpés progressivement. et je me vois mal creer 10 unitees de 2 ou 3 routines, le temps qu'elles s'etoffent au fils des mois/ans.
D'un autre coté, regroupper au moment du codage toutes les routines de meme theme est bien .... d'ou l'idee du prefixe thematique.
Par contre ca oblige a tapper suffisement de carracteres, que ca rends le systeme caduque

Bref, je viens juste de rentrer de vacances et deja je me prends la tete .... ca doit pas me reussir de partir en vacances
Vais peut etre proposer au boss de revoir mon contrat

[Bloon]

J'hesite entre creer une unitee avec tout un tas de procedures libres effectuant les traitement ou les regroupper par theme dans des classes abstraites contenant uniquement des methodes de classes.

Juste une remarque sur le vocabulaire : Une classe abstraite est une classe qui contient au moins une méthode abstraite. Ce n'est pas ce que tu souhaites faire, toi c'est plutôt une classe statique, mais je ne sais pas si ce terme existe

Bloon

[ALWEBER]

L'approche par classe me semble bien. Elle est proche de la notion d'objet telle qu'elle est pratiquée dans d'autres domaines (UML en autres). J'initialise mon objet dans initialization , je le "free" dans finalization. J'obtiens ainsi un singleton. J'utilise cela depuis une dizaine d'années pour des unités génériques et j'en suis satisfait. Deplus c'est compatible entre toutes les versions de Delphi depuis au moins la 5

[sjrd]

Juste une remarque sur le vocabulaire : Une classe abstraite est une classe qui contient au moins une méthode abstraite. Ce n'est pas ce que tu souhaites faire, toi c'est plutôt une classe statique, mais je ne sais pas si ce terme existe

Bloon

Classe statique, c'est du C++. En Delphi, statique a une toute autre signification (une méthode statique est par opposition à une méthode virtuelle ou dynamique).
Mais comme tu le dis, ce n'est en tout cas pas classe abstraite.
Je préfère appeler ça une "classe utilitaire", mais ce n'est pas un terme officiel, c'est le miens

[Clorish]

L'approche par classe me semble bien. Elle est proche de la notion d'objet telle qu'elle est pratiquée dans d'autres domaines (UML en autres). J'initialise mon objet dans initialization , je le "free" dans finalization. J'obtiens ainsi un singleton. J'utilise cela depuis une dizaine d'années pour des unités génériques et j'en suis satisfait. Deplus c'est compatible entre toutes les versions de Delphi depuis au moins la 5

La je me pose la question suivante : A quoi sert une initialisation ?!?
Le propre des methodes de classes n'est elle pas de s'executer au sein de la classe et non d'une instance ?

[sjrd]

ALWEBER a une autre approche que la classe "utilitaire" ou peu importe comment on l'appelle.

Il utilise le fameux design pattern singleton : une classe qui n'accepte qu'une et une seule instance, au travers de laquelle tu travailles.

Mais la classe utilitaire et le singleton n'ont pas les mêmes objectifs. Dans ton cas il s'agit plutôt de classe utilitaire.
Cela dit, je suis bien incapable d'expliquer clairement les différences d'objectif Je les "sens" plutôt qu'autre chose

[Clorish]

Oui je comprends
Techniquement je ne voit pas en quoi creer une instance d'une classe possedant uniquement des methodes de classes soit une heresie.
Donc pourquoi pas.

Je me demandais juste quel etais l'interet de ce genre de chose dans la tete de son concepteur car je suis bien d'accord avec une chose : Il y a autant de methode que de perception des choses.

C'est justement sur ce point que repose ma question. Je pourrais aussi bien choisir l'une ou l'autre des methodes que j'ai evoqué sans que cela soit considere comme une erreur ... mais n'etant pas convaincu par chacune de ces methodes, j'en appel a vos avis sur la question, afin de m'aider a me forger ma propre idee

[Graffito]

Bonjour,

En Delphi, il me semble que l'inconvénient de la solution "methodes d'objet" est la nécessité d'instancier un objet (On peut créer une variable globale instanciée dans la section initialisation de l'unité contenant la classe).

Pour Delphi, j'utilise donc la solution "procedure".

Pour info, en C#, la solution "methodes d'objet" s'impose puisqu'il existe des méthodes avec l'attribut "static" qui peuvent être utilisées sans qu'on ait besoin d'instancier l'objet.

[Clorish]

C'ets pour cela que Delphi a inventé le mot clef class a poser devant une methode d'objets

D'ailleur au passage, lors de precedent tests, toutes methodes ne faisant pas reference aux variables d'une classe est consideree comme "methode de classe" et peut etre appelée sans instance d'objet.
ce n'ets que des suppositions lié a des tests empiriques ... mais je l'expliquerais du fait que le code des methodes est contenue dans la classe et non dans l'isntance. L'instance elle ne contenant que les variables.
A confirmer bien sur

[Graffito]

C'est pour cela que Delphi a inventé le mot clef class a poser devant une methode d'objets

Raah, je suis vert. Cà marche au moins depuis Delphi 6 et j'avais jamais vu cette possibilité.

Donc, la solution class procedure et class function d'un objet par thème me semble être la bonne solution.
Je l'aurais adoptée depuis longtemps si j'avais su...
De plus, ca pourrait être utile dans la perspective d'une migration vers .net (à vérifier).