1. Le discours du vieil homme
Delphi VS VC est déjà un sujet très ancien, mais je veux toujours en parler ici, c'est mon opinion. Si vous n'êtes pas d'accord, riez.
Les avantages de RAD sont faciles à constater. En termes de conception d'interface, Delphi est en fait meilleur que VC. Je veux écrire un bouton transparent non conventionnel. Dans Delphi, il me suffit de trouver un contrôle, de cliquer sur la souris et de modifier la légende. Qu'en est-il de VC ? Il faut au moins 10 lignes de code pour y parvenir. Bien entendu, l'approche de MFC permet aux utilisateurs de comprendre les principes sous-jacents de Windows, mais l'encapsulation de la POO n'est pas bien reflétée. Les développeurs doivent comprendre tous les principes sous-jacents avant de pouvoir écrire du code. Pour moi et pour la plupart, être débutant est une torture car il n'y a pas besoin de le faire. Oui, les délais de développement sont toujours serrés et le temps n'est jamais suffisant. Nous ne pouvons pas nous attendre à ce que les programmeurs connaissent tous les aspects de la programmation Windows. Certaines personnes en savent beaucoup sur les vidéos et d'autres sont bonnes en réseautage, mais personne n'est polyvalent et n'est bon. en tout, c'est irréaliste, donc l'encapsulation est très importante. Si je dois passer 30 % ou plus de mon temps sur un bouton transparent ou une belle interface à chaque fois que je développe un nouveau produit, alors je me jetterai à l'eau :) Delphi est en effet meilleur que MFC en termes d'interface ! Bien sûr, cela ne signifie pas que MFC ne peut pas concevoir de belles interfaces, mais cela prend tout simplement trop de temps et n'en vaut pas la peine.
Le RAD est-il vraiment une question d’avantages ? Ni l'un ni l'autre. Du moins pas pour les débutants, car cela fait mal comprendre que la programmation consiste simplement à déplacer la souris et à tirer le cadre. Le résultat final est que les gens pensent que Delphi n'est utilisé que pour écrire des interfaces et que la couche inférieure ne peut rien faire. Il semble que les programmeurs MFC parlent tous des programmeurs Delphi : « En plus d'avoir une belle interface, que peut faire d'autre votre programme ? En fait, à part DDK, qu'est-ce qui ne peut pas être développé dans Delphi ? Quel fichier d’en-tête d’API Delphi ne possède-t-il pas ? Borland n'a pas converti, mais JEDI l'a converti Même si JEDI n'a pas converti, c'est pareil si vous me donnez le fichier d'en-tête C, je peux le convertir. devrait être un must pour tout programmeur Delphi avec la documentation requise. Une fois les fichiers d’en-tête convertis, il ne reste plus qu’à commencer à écrire. Ce que MFC peut faire, Delphi peut le faire aussi ! vidéo? réseau? directx ? Du son ? Qu'est-ce que Delphi ne peut pas faire ?
2. Sous-processus
Lors de l'écriture d'un événement, de nombreuses personnes commencent simplement à l'écrire, peu importe la durée du code ou le nombre de choses effectuées, tant que cela est fait dans le cadre d'un événement, ils l'écrivent simplement dans leur tête. n'ont aucun moyen de commencer lorsqu'ils le révisent quelques mois plus tard, car l'extrait de code est trop long. Alors pourquoi ne pas séparer les extraits de code ? L'attention humaine est limitée et vous aurez le vertige si vous lisez plus de 100 lignes de code en une seule fois. Les seniors de Delphi m'ont dit une chose : tous les processus (le processus ici inclut la procédure et la fonction) ne doivent pas dépasser 25 lignes ! Parce que cette longueur de code ne vous fera pas tourner la tête, vous comprendrez facilement ce que fait le processus.
Alors, comment démonter les choses qui ont été faites à l’origine lors d’un événement ? Il existe de nombreuses méthodes, mon expérience est modulaire. Par exemple, s'il y a beaucoup de choses différentes à faire dans un événement, alors les différentes choses sont converties en différents sous-processus, puis appelés dans le processus principal. La plupart des processus principaux sont des jugements et des boucles, et il y en aura. pas de processus d’implémentation spécifique. Cela créera beaucoup d’extraits de code, mais cela gardera votre concentration !
Principe : Un processus ne fait qu’une seule chose et le fait bien.
Référence : code source VCL. En regardant le code source de la VCL, il y a rarement plus de 25 lignes de code !
3. Nom du paramètre
Je me souviens que lorsque j'ai appris le SDK pour la première fois, j'avais le vertige en voyant la notation hongroise, c'était trop ! Je ne m'en souviens pas ! Donc je déteste cet inventeur :) Enfin Delphi apparaît et l'époque où l'on dansait enchaîné est révolue ! Dans Delphi, définir une chaîne avec un nom de variable comme strDoSometing est ridicule et inutile. Tant que votre procédure est courte et qu'aucune variable globale n'apparaît, vous n'avez pas besoin d'un tel préfixe. Par exemple:
procédure SubPro ;
var
je : octet;
Largeur, Hauteur : entier ;
commencer
Largeur := GetWidth;
Hauteur := GetHeight;
pour i:=0 à 9 fais
commencer
DrawThread := TDrawThread.Create;
DrawThread.Width := Largeur;
DrawThread.Height := Hauteur;
DrawThread.Start ;
fin;
fin;
Je pense que même si un tel segment de code ne contient aucun commentaire, il est facile de savoir ce qu'il va faire. Veuillez donc supprimer tous les préfixes et traits de soulignement, les programmes Delphi n'en ont pas besoin ! Nos noms de paramètres n'ont besoin que d'un verbe + nom. Nous devons seulement expliquer la fonction de ce paramètre. Nous ne voulons pas de choses redondantes. L'avantage de Pascal est que le code semble parler plutôt que de lire du ciel. . Dans votre tête, ce que vous pensez est à quoi ressemble le code. Elégant et simple, tels sont les avantages de Pascal, respectez-le !
Principe : La simplicité est belle !
4. Sous-fenêtre
De nombreuses personnes actionnent directement les commandes de la sous-fenêtre lorsqu'elles appellent une sous-fenêtre, telles que :
si SetAlarmParamDlg.ShowModal = MrOK alors
commencer
AlarmTimes := StrToInt(SetAlarmParamDlg.Edit1.Text);
AlarmArea := SetAlarmParamDlg.SpinEdit1.Value;
fin;
Oh mon dieu, si demain les utilisateurs trouvent que l'Edit ou SpinEdit que vous utilisez est moche et le remplacent par un beau contrôle, que ferez-vous ? Non seulement vous devez modifier le code de la sous-fenêtre, mais vous devez également modifier le code du formulaire principal. Bien sûr, un programme avec une ou deux sous-fenêtres ne vous posera aucun problème. Et s'il s'agissait d'un programme avec plus de vingt sous-fenêtres ? Cela a pris une journée, mais la raison était simplement pour changer une commande ! Pourquoi ne pas essayer une autre méthode ? Si vous utilisez des attributs pour représenter les paramètres que vous souhaitez utiliser, vous enregistrerez d'innombrables codes.
//formulaire principal
si SetAlarmParamDlg.ShowModal = MrOK alors
commencer
AlarmTimes := SetAlarmParamDlg.AlarmTimes;
AlarmArea := SetAlarmParamDlg.AlarmArea;
fin;
// sous-formulaire
interface
privé
FAlarmTimes : entier ;
FAlarmArea : entier ;
publié
propriété AlarmTimes : entier lire FAlarmTimes écrire FAlarmTimes ;
propriété AlarmArea : entier lire FAlarmArea écrire FAlarmArea ;
mise en œuvre
...
FAlarmTimes := StrToInt(Edit1.Text);
FAlarmArea := SpinEdit1.Value;
RésultatModal := MrOK ;
...
Tant que vous persistez dans cette voie, vous trouverez de grands avantages. Une sous-fenêtre ne fait que son propre travail, et l'interaction entre la fenêtre principale et elle se fait via des attributs. Tant que l'interface reste inchangée, des modifications sont apportées à l'interface. La sous-fenêtre n'affectera pas la fenêtre principale. Peu importe la façon dont l'apparence de la sous-fenêtre change, la façon dont les contrôles sont remplacés ou la façon dont le code est modifié, l'ensemble du programme reste le même, seule l'interface a changé.
Principe : Modularisez vos sous-fenêtres. Les fenêtres sont également des classes. La manière de communiquer entre les classes devrait être la manière dont les fenêtres doivent communiquer.