Discussion :

[fredero]

Bonsoir,

Le programme que je suis en train de développer commence à grossir (grâce au forum d'ailleurs). J'ai créer plusieurs fonctions et procédures et je finis par ne plus m'y retrouver lorsque je dois modifier quelque chose.

Je me suis aperçu qu'il y a certaines grosses fonctions auxquelles je ne touche pas beaucoup. Est-il possible de les mettre dans une unité à part qui ne servirait qu'à stocker des fonctions et faire une sorte d'include ?

D'une manière générale comment vous y prenez-vous pour vous y retrouver dans votre code ?

[MD Software]

Est-il possible de les mettre dans une unité à part qui ne servirait qu'à stocker des fonctions et faire une sorte d'include ?

Oui, bien sûr. Créé une nouvelle unité, déclare les fonctions dans la partie interface, définie les dans la partie implémentation, et fait un uses de cette unité dans les unités qui en ont besoin.

D'une manière générale comment vous y prenez-vous pour vous y retrouver dans votre code ?

Une seule classe par unité et architecture par couche.

[sjrd]

Pour les untiés à part, MD Software t'as répondu.

Pour ce qui est de l'organisation générale, cela dépend beaucoup du projet.
Si je prends en exemple mon plus gros projet, j'organise mes différentes classes en unités selon les fonctionnalités des classes. Par exemple, toutes les fonctions d'utilité générale à propos de Sepi sont dans SepiUtils.pas (il y par exemple la plupart des chaînes de ressources, des déclarations de types - énumérations, redéclarations, etc. - quelques classes très générales - comme la gestion des auteurs - et quelques routines). Ensuite, j'ai une unité SepiUnits qui contient une petite dizaine de classes gérant les unités compilées.
Tu commences à comprendre le concept de fonctionnalité ?
Finalement, après toutes ces unités utilitaires, il me reste une unité par fiche de mon application qui ne sert plus que d'interfaçage entre les composants visuels et les fonctionnalités du programme.

Ceci répond à ta question ?

[Clorish]

Moi je suis d'accord avec SJRD : Un unites "Common" qui sert a regrouper toutes les fonctions standard.

Mais je rajoute 2/3 autres unites en fonction des besoins :
CST.pas est reserve a la declaration de toutes les constantes de mon programme. Quand je dit toutes c un grand mot. Disons que je met ici toutes les constantes relatives a la "configuration" de mon application : LEs chemins par defaut, des chaines de messages, les chaines d'exceptions, etc ...
Eventuelement je la decoupe en sous parties : CST_Config, CST_Extpetion, CST_Messages, etc ...

Une autre reserve elle a la declaration d'une classe TNfo qui possedes des methodes et proprietes de traitement des infos standard (chemins d'acces, port de connection, adresse ip, numeros de versions, auteurs, etc ....

Eventuemement une 3e pour les var globales si yen a bcp.
Moins ya de code dans une unite mieux je me porte ;p

Ensuite je met en place une unite de debug avec des methdoes et classes de gestion des messages de debogages et pkoi pas une form de type motinotring.

ensuite : Un unitee par classe et quand elles sont pas trop grosses, une unitee par theme comme delphi (Stdtrls, buttons, etc..) mais en general c une unite par classe et la fusion se fait plus tard quand le debogage est assez avance.

Voila en gros ;p

[fredero]

Merci pour ces infos.
Voilà une discussion que je relirai plus tard, quand j'aurai compris plus de choses ...