Plus souvent, vous n'aurez probablement pas lieu dans une situation où vous pourriez avoir besoin d'une fonction ou d'une procédure, il est probable que vous avez déjà écrit ce code avant.
Ma question est de savoir comment l'organisez-vous afin que vous ne devez pas tout réécrire, en d'autres termes, quel est le meilleur moyen de maintenir un code redoutable?
Je pensais mettre toutes mes procédures et toutes mes procédures dans une seule unité et ajouter cette unité à la clause utilisée des formulaires requis, etc.
Mais ensuite, l'appareil deviendrait plutôt volumineux, et afin d'utiliser peut-être une ou deux fonctions à partir de la grande unité d'une grande unité ajoutera de taille inutilement en vrac à l'application.
Ce que je demande essentiellement, c'est quelle est la meilleure méthode pour la performance et la commodité sage, de gérer, de maintenir et d'utiliser un code réutilisable?
Après quelques postes informatifs, j'ai décidé de procéder et d'utiliser une seule unité source contenant toutes mes routines réutilisables. J'ai incorporé l'utilisation du code du code du code de code DELPHI pour créer des régions personnalisées, pour séparer les différents types en groupes, des régions de puits. Toutes les régions seront effondrées ainsi que des noms de région significatifs. J'ai ajouté l'unité SIMPLE SOURCE sur le chemin de la bibliothèque, que je peux ajouter à n'importe quelle clause utilise des formulaires et avoir accès à toutes les routines réutilisables. Voir la capture d'écran pour une meilleure idée:
Beaucoup plus de routines ont besoin d'ajouter là-bas. Les régions aident à garder le code organisé et plus facile à lire, je peux développer tout si nécessaire.
Merci. 
4 Réponses :
Premièrement, votre hypothèse selon laquelle les grandes unités entraînent de grands exécutables sont fausses. Seules les pièces usées sont liées à l'exécutable final.
Placer des routines réutilisables dans une ou plusieurs unités distinctes est une pratique courante. À qui vous étendez-vous que cela dépend de votre propre procédure ou de règles imposées (par exemple, votre entreprise).
Personnellement, j'aime nommer des unités telles que Delphi: awcontrols, Awutils, AWDB, Awutils, AWDB, AWLES, AWMENUS pour ces routines et classes qui étendent la VCL par défaut ou contiennent des composants neufs ou dérivés. Mais je crée également des unités distinctes pour des composants plutôt gros ou pour des routines ou des classes peu communes comme Awplangrid, AWDXF, AWIPTYPES. Juste une suggestion.
Un autre conseil: Ajoutez le dossier contenant ces unités à votre page de recherche de projet par défaut (pour définir les options de projet tout en n'ayant aucun projet chargé dans l'IDE).
Tout le code dans la grande unité est compilé, mais seules les pièces usagées sont liées à l'EXE final.
la construction n'est pas bonne non plus. Une construction peut désigner le processus général de production de l'EXE final d'un ensemble de sources, ou cela pourrait désigner la ré-compilation de tous les fichiers source, même si des fichiers DCU apparemment à jour. La liaison est le processus de collage ensemble de tous ces DCU pour obtenir un grand exe. L'idée est, une construction ou une compilée compilera tout le fichier Big Pas à un gros DCU, mais le linker ne prendra que les parties de la DCU dont elle a besoin. Comme mon premier commentaire dit: «Seules les pièces usagées sont liées à l'EXE final».
@Cosmin Prund: OK, très clair. J'ai toujours considéré les balles bleues dans la gouttière représentant le code compilé, mais c'est le code lié. Et bien sûr, sinon, DCU n'aurait pas beaucoup de but ...;)
@Cosmin je ne savais jamais ça! J'ai supposé que n'importe quel code dans une unité qui n'est pas espacée ni commentaire serait inclus dans l'exécutable, vous apprenez quelque chose de nouveau tous les jours :)
au lieu d'une unité, utilisez un dossier avec plusieurs unités.
Organisez les unités en fonction du sujet et de s'efforcer de maintenir une cohésion élevée, un faible accouplement. En d'autres termes: les unités doivent contenir des fonctions et des procédures étroitement liées et utilisent le moins de vos autres unités que possible (VCL / RTL peuvent être utilisées librement bien sûr).
Si vous avez besoin d'inspiration sur quel type d'unités vous pourriez avoir: je prendrais une feuille hors du VCL et RTL. La manière dont les unités sont organisées et ce que des trucs sont réunis par rapport à ce que sa propre unité peut vous donner une compréhension assez claire de la façon d'organiser vos propres trucs.
+1, j'aime le dossier contenant plusieurs unités (toutes?). Le dossier unique peut être facilement ajouté au chemin de la bibliothèque IDE afin que toutes les unités soient automatiquement disponibles sur tous les projets.
@Cosmin mieux inclure dans le projet correctement et utiliser le contrôle de révision que le chemin IDE.
J'ai fait cela pour mon cadre et vous pouvez télécharger les utilitaires à partir d'ici ( CSInnovations.com/framework/ Csiutities.zip ) Pour avoir une idée de la façon de faire cela.
+1 pour éviter le couplage. Une unité n'évite pas le couplage, c'est le type de couplage ultime.
@David, cela pourrait être une question de préférence, mais je ne vois aucun avantage à ajouter le même chemin à chaque projet que je crée. Et je conserve mon chemin de la bibliothèque mondiale sous la version de la version, ainsi que toutes mes unités partagées et mes composantes 3ème partie, dans un projet nommé environnement de travail.
@COSMIN i Faites confiance Votre projet partagé peut avoir des versions différentes dans les différents projets qui l'incluent
@David, je peux consulter une version plus ancienne de mon projet d'environnement de travail si j'en ai besoin d'un plus ancien, mais il n'y aura qu'une version du "Notre projet" actif à un moment donné. Mon "projet de notre projet" inclut également des composants qui doivent être installés dans l'IDE (3ème partie et mes propres composants), de sorte que plusieurs versions actives en même temps soient vraiment un cauchemar. Si vous aurez jamais besoin de travailler sur une ancienne version de mon projet, je vais simplement installer une machine virtuelle fraîche et vérifier les deux projets dont j'ai besoin: The Nous et le projet qui nécessitent du travail.
@David, @cosmin: Ah, c'est là que nous différerons cosmin. Nos projets spécifient chacun la version des composants dont ils ont besoin dans une "version de la version de composante requise" distincte et que nous disposons d'un utilitaire qui mettra à jour toutes les chemins de tous les DPROJ de notre Suite en fonction de ces fichiers. Ces fichiers sont également utilisés (avec une astuce très intelligente incluent l'un de mes collègues) pour vérifier les versions spécifiées par rapport aux versions compilées au moment de l'exécution. Cela fonctionne exceptionnellement bien que nous pouvons généralement «faire» avec une ancienne version au moment de la conception lors de l'exécution de la version correcte.
Oh et pour faire triple sûr: le chemin de la bibliothèque de mon IDE est vide (oui, vide, pas même $ (BDS) \ lib est inclus). Maintenant, nos unités de bibliothèque générale se trouvent dans les branches «normales», mais quelques composants que nous entretenons (maintenant) nous-mêmes sont dans le dossier Composants utilisé par tous les projets. Et les composants obtiennent une nouvelle version enregistrée pour chaque changement ... De cette façon, nous ne devons jamais changer l'IDE pour compiler une ancienne version. En fait, je peux simplement tirer les sources d'une version de deux ans et la compiler sans rien faire spécifique (et n'essayez pas de modifier les formulaires ...)
@marjan votre avis ne diffère pas de la mienne, ils sont complètement alignés
@David: Avez-vous peut-être manqué le "cosmin" après mon "où nous différons" intro? Je vous ai inclus dans mon adresse car je m'appuyais sur une discussion entre vous et COSMIN.
Aujourd'hui, j'ai essayé d'ajouter une unité à mon code et d'une autre unité. Cette unité utilisait trois autres. Et les trois que celui-ci utilisé, a utilisé un total de 27 autres unités.
Étant donné que ces unités n'étaient pas dans un seul dossier, je devais configurer un chemin de recherche ou ajouter un total de 27 unités à mon projet de démonstration, pour que je puisse appeler une de mes fonctions de bibliothèque.
Si vous pensez que ceci est extrême, essayez simplement d'utiliser une partie de la JEDI JCL ou JVCL sans en utiliser beaucoup plus.
Ceci est un exemple de type de couplage qui le fait que cela ne ressemble pas qu'il ne vaut pas la peine d'essayer de réutiliser votre code.
Je pense que pour mon prochain projet, au lieu d'un Dunit monolithique pour des tests d'unités, que tous les tests d'un seul morceau réutilisable du code devraient être intégrés à leurs propres exécutables distincts, par classe qu'ils testent et configurés pour explicitement Incluez les unités dont ils ont besoin, sans y compris les dossiers de recherche / dossiers de bibliothèque pouvant permettre de nouvelles unités de s'ajouter silencieusement au code. Ensuite, je chaque fois que quelqu'un coule, ils briseraient les tests de l'unité et nous saurions quelque chose de mal arriver.
Quoi qu'il en soit, cela me semble être un moyen de garantir que votre code évite le couplage, et que vous pourriez écrire une petite ou nouvelle application et tirer dans votre code, juste les pièces (composantes si vous aimez) , sans un train géant de "Hell-hell de dépendance à l'usage-clause".
Ditto à la déclaration de Marjan selon laquelle une seule unité n'est pas la voie à suivre; Les dépendances dans une énorme unité utilitaire vont aller à Haywire. Pour construire n'importe quel projet utilisant cette unité utilitaire, vous devrez disposer de toutes les unités dans sa section d'interface et de mise en œuvre.
Gardez-le simple. Gardez-le séparé. Couplage mauvais. La réutilisabilité facile et amusante n'est possible que si vous évitez le couplage.
Je sais exactement ce que vous entendez par le couplage d'unités. Je ne vois pas pourquoi me mettre mon code dans une grande unité est une mauvaise chose cependant, il suffit d'ajouter une unité à une forme et j'ai accès à tout. Avec les régions en place, il est facile de maintenir et de voir.
«Essayez simplement d'utiliser une partie du Jedi» - - - Je sais que vous voulez dire.
Craig même si vous évitez les utilisations de la clause HELL, et votre méga unité ne dépend de rien d'autre, ce sera un travail très difficile ultérieurement de maintenir votre unité. Ma prédiction est que vous commencerez à éviter d'éviter les utilisations unitaires-enfer, mais que, dans une mort par mille coupes de papier, c'est exactement là où de telles mégies se dirigent inexorablement. Vous ne pouvez l'empêcher que de ne jamais commencer la route de l'unité méga.
True Warren, mais avec les régions pliantes et personnalisées de code, je le trouve facilement facile à ajouter, à maintenir et à trouver du code. Et vous frappez le clou sur la tête, je veux éviter les utilisations de la clause de la folie. Ajout de x, y, z unités et d'oublier quelle unité contenait de la fonction de fonctionna, de fonctionnement, de fonctionC, etc. dans l'unité MEGA, il suffit d'ajouter ceci à utiliser la clause, puis de n'importe quel type d'événement quelque chose comme: MyLib. Pour remplir la liste complète automatique pour trouver la fonction dont j'ai besoin de l'unité Mega.
S'ils sont tous pour un seul but, comme le traitement du fichier audio, puis les mettre dans une unité conviennent parfaitement. Avoir un réseau, une chaîne, une date, un format de fichier, un disque, une API, un conducteur et qui sait-savoir-quoi-autre dans chiensbreakfast.pas est une erreur.
Je mets tout mon code commun dans une bibliothèque commune (en réalité, il y a environ 4 fichiers PAS dans le même dossier). Qui est bien huuuge. Mais seul le code nécessaire sera ajouté à votre EXE, pas la bibliothèque entière. Le compilateur DELPHI est suffisamment intelligent pour savoir quel code est nécessaire.
Que voulez-vous dire avec la bibliothèque? Paquet Delphi? Durée d'exécution ou temps de conception? Ou dll? La liaison intelligente ne fonctionne pas entre les limites de package d'exécution. Je ne sais pas sur les packages de temps de conception.
Methinks - subjectif et argumentatif
Une seule unité méga est tout simplement fausse.