Discussion :

[gvasseur58]

Ce tutoriel de Robin Valtot, réalisé avec la version 10.1.2 Berlin (Entreprise et Starter) de Delphi, a pour objectif de montrer plusieurs façons d'envoyer un mail au moyen de cet EDI.

S'appuyant sur la présence d'un client de messagerie, seront tour à tour étudiés un serveur SMTP, le pilotage d'Outlook et la mise en œuvre de l'ensemble MAPI.

http://robin-valtot.developpez.com/t...s-avec-delphi/

L'équipe Delphi de developpez.com profite de cette publication pour féliciter chaleureusement l'auteur de ce tutoriel qui vient d'être promu MVP Delphi : c'est la juste reconnaissance des qualités et du travail de ce jeune collaborateur. Bravo Robin, et merci pour tes contributions à la communauté !

Et vous ?

Que pensez-vous de ce tutoriel ?
Comment utilisez-vous Delphi pour tout ce qui touche au Web ?


Retrouver les meilleurs cours et tutoriels pour apprendre Delphi
Retrouver les meilleurs cours et tutoriels pour apprendre la programmation

[Invité]

Merci Gilles

Si vous souhaitez que je développe un sujet précis la prochaine fois, vous pouvez m'en parler : je ferai mon possible pour les prochains articles

[der§en]

Curieux de voir si cela fonctionne avec un Exchange serveur…

[gbegreg]

Félicitations Retwas

As tu pu avancer sur ton autre tutoriel en cours (le jeu du Démineur en FMX) ? Car il est également très bien !
Je comprendrai parfaitement que tu n'ai pas eu le temps : je n'ai pas avancé moi non plus sur mon prochain tuto (remake du jeu The Light Corridor)

[SergioMaster]

Bonjour,

perso, j'ai été dérouté, envoyer des mails, on avait déjà les FAQs, quelques tutoriels et les exemples d'Indy et je me disais (à tort peut être) à quoi bon
En fait c'est plus l'approche par l'intermédiaire des interfaces pour utiliser les différentes possibilités qui est intéressante, à mon avis il aurait fallu plus expliquer le pourquoi de cette démarche.
Ceci étant, bravo, je sais qu'il est difficile d'écrire des tutoriels, surtout si l'on n'est pas un littéraire. J’espère que beaucoup d'autres membres se sentent aussi des talents d'auteurs

[Bernard B]

Beau tuto bien fait !

Par contre en tant que vieux développeur autodidacte qui a commencé en Turbo pascal sur Amstrad (les jeunes zont jamais vu !!) je ne comprend pas tout !

Les interfaces, je rejoins SergioMaster, elles apportent quoi de plus ? Je n'y vois qu'une couche de complexité supplémentaire. Peut-on m'éclairer ?
Autre interrogation : dans l'objet TMessageSenderSMTP pourquoi faire des get et des set dans la gestion des property alors qu'il me semble qu'une simple référence à la variable interne fait l'affaire.

Je vais tester de ce pas car je suis en plein dans l'envoi de mails !
Actuellement j'utilise plutôt l'objet SmtpClient de ICS car je trouve la bibli Indy horriblement compliquée et assez mal documentée.

[Paul TOTH]

Beau tuto bien fait !

Par contre en tant que vieux développeur autodidacte qui a commencé en Turbo pascal sur Amstrad (les jeunes zont jamais vu !!) je ne comprend pas tout !

Les interfaces, je rejoins SergioMaster, elles apportent quoi de plus ? Je n'y vois qu'une couche de complexité supplémentaire. Peut-on m'éclairer ?
Autre interrogation : dans l'objet TMessageSenderSMTP pourquoi faire des get et des set dans la gestion des property alors qu'il me semble qu'une simple référence à la variable interne fait l'affaire.

Je vais tester de ce pas car je suis en plein dans l'envoi de mails !
Actuellement j'utilise plutôt l'objet SmtpClient de ICS car je trouve la bibli Indy horriblement compliquée et assez mal documentée.

alors en lisant rapidement le code, je ne vois pas bien non plus l'intérêt des interfaces plutôt qu'une classe ancêtre avec des méthodes virtuelles....

pour ce qui est des propriétés et des setters, c'est justement lié aux interfaces qui réclament des getter/setter qu'il faut donc implémenter.

[Invité]

Curieux de voir si cela fonctionne avec un Exchange serveur…

J'ai testé sur le serveur Exchange je n'ai pas eu de problème

Félicitations Retwas

As tu pu avancer sur ton autre tutoriel en cours (le jeu du Démineur en FMX) ? Car il est également très bien !
Je comprendrai parfaitement que tu n'ai pas eu le temps : je n'ai pas avancé moi non plus sur mon prochain tuto (remake du jeu The Light Corridor)

Merci gbegreg
Pour le démineur je vais me pencher à nouveau dessus ce mois ci, il me reste seulement le soucis des images sur la version mobile ..
Hâte de voir ton second tutoriel, je connais pas le jeu original, je dois être trop jeune

Bonjour,

perso, j'ai été dérouté, envoyer des mails, on avait déjà les FAQs, quelques tutoriels et les exemples d'Indy et je me disais (à tort peut être) à quoi bon
En fait c'est plus l'approche par l'intermédiaire des interfaces pour utiliser les différentes possibilités qui est intéressante, à mon avis il aurait fallu plus expliquer le pourquoi de cette démarche.
Ceci étant, bravo, je sais qu'il est difficile d'écrire des tutoriels, surtout si l'on n'est pas un littéraire. J’espère que beaucoup d'autres membres se sentent aussi des talents d'auteurs

Merci pour tes remarques et effectivement je suis loin d'être littéraire..
Les interfaces permettent justement d'apporter quelque chose de nouveau par rapport aux autres tutoriels ou FAQ et de passer cette impression de "déjà vu".

Beau tuto bien fait !

Par contre en tant que vieux développeur autodidacte qui a commencé en Turbo pascal sur Amstrad (les jeunes zont jamais vu !!) je ne comprend pas tout !

Les interfaces, je rejoins SergioMaster, elles apportent quoi de plus ? Je n'y vois qu'une couche de complexité supplémentaire. Peut-on m'éclairer ?
Autre interrogation : dans l'objet TMessageSenderSMTP pourquoi faire des get et des set dans la gestion des property alors qu'il me semble qu'une simple référence à la variable interne fait l'affaire.

Je vais tester de ce pas car je suis en plein dans l'envoi de mails !
Actuellement j'utilise plutôt l'objet SmtpClient de ICS car je trouve la bibli Indy horriblement compliquée et assez mal documentée.

alors en lisant rapidement le code, je ne vois pas bien non plus l'intérêt des interfaces plutôt qu'une classe ancêtre avec des méthodes virtuelles....

pour ce qui est des propriétés et des setters, c'est justement lié aux interfaces qui réclament des getter/setter qu'il faut donc implémenter.

Merci Bernard B, je suis curieux de connaitre ton retour
Les interfaces sont là pour apporter quelque chose de nouveau par rapport aux tutoriels existants mais aussi montrer une autre façon de coder.

Une interface ne peut contenir que des méthodes (public) c'est pourquoi il y a des getter et setter.
Si tu as besoin il y a une explication ici ou alors dans l'excellent livre de Nick Hodges "Coding in Delphi".

Le point fort des interfaces est de permettre de découpler son code, limiter la dépendance des classes, avoir un code plus clair, plus propre et plus facile à maintenir, de proposer uniquement la ou les méthodes nécessaires et pas forcément travailler avec/sur l'objet en entier, la portée d'une interface permet aussi de se passer de sa libération.
Cela permettra de voir un peu plus tard les injections de dépendances.

Quoi qu'il en soit, comme le souligne Paul TOTH cela est aussi possible avec des classes "normales"

[Paul TOTH]

Le point fort des interfaces est de permettre de découpler son code, limiter la dépendance des classes, avoir un code plus clair, plus propre et plus facile à maintenir, de proposer uniquement la ou les méthodes nécessaires et pas forcément travailler avec/sur l'objet en entier, la portée d'une interface permet aussi de se passer de sa libération.
Cela permettra de voir un peu plus tard les injections de dépendances.

alors oui et non, si tu regardes Firemonkey par exemple, ils ont mis des interfaces partout...sauf que comme ce n'est pas toujours bien documenté, on est amené à se plonger dans le code pour comprendre ce qu'il se passe, et là on tombe sur des interfaces pas plus documentés et il faut aller à la pêche pour retrouver où c'est implémenté bon ceci dit avec des classes virtuelles ça donne un peu la même chose, mais il est plus facile de retrouver les Constructor que quand on tombe sur ce genre de code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
procedure TCommonCustomForm.BeginInternalDrag(const Source: TObject; const ABitmap: TObject);
var
  D: TDragObject;
  DDService: IFMXDragDropService;
begin
  if Assigned(Source) then
  begin
    Fillchar(D, SizeOf(D), 0);
    D.Source := Source;
    if TPlatformServices.Current.SupportsPlatformService(IFMXDragDropService, IInterface(DDService)) then
      DDService.BeginDragDrop(Self, D, FMX.Graphics.TBitmap(ABitmap));
  end;
end;

cf http://lookinside.free.fr/delphi.php?FMXBasedDragDrop

mais pour le découplage c'est bien oui...par exemple au lieu de faire référence explicitement à une fiche mère, on peut exploiter une interface dans la fiche fille qui sera implémentée par la fiche mère, du coup la fiche fille pourra facilement être utilisée dans n'importe quel projet, y compris en changeant la fiche principale, pour peu qu'on implémente l'interface quelque part.

[Bernard B]

Bien il semble que les interface permettent de séparer l'utilisation de la mécanique interne. Mais dans la POO de base c'est bien la différence entre public et private.

L'article dont retwas me donne le lien, je l'avais déjà parcouru il y a un certain temps. Je l'ai relu et je suis toujours aussi dubitatif. C'est compliqué et finalement on ne voit pas surgir l'élément incontournable qui fait que l'on s'y colle.
Je n'avais pas tout suivi et rebelote c'est compliqué pour quoi ?
Je dois dire que l'exemple que donne Paul est assez impressionnant. Perso je n'y comprend rien ! et le pire c'est que l'on ne devine pas à quoi cela peut conduire.
La POO suivant son implémentation ce n'est pas toujours simple, mais les interfaces ressemblent à la forêt vierge.
Les cerveaux plus jeunes sont certainement plus malléables mais là le mien à atteint le seuil de son incompétence !

[Invité]

@PaulTOTH : Exactement c'est vrai qu'en débogage faut parfois aller chercher un peu plus loin, mais c'est une autre façon de coder que je trouve peut être plus "moderne", je vois d'ailleurs que tu les utilises pour le TMouse3D mais je n'ai pas la prétention de pouvoir t'apprendre quelque chose

[Bernard B]

OK retwas pour ta proposition, mais je n'ai pu te répondre en message privé, il semble que ta boite est saturée

[Paul TOTH]

Bien il semble que les interface permettent de séparer l'utilisation de la mécanique interne. Mais dans la POO de base c'est bien la différence entre public et private.

L'article dont retwas me donne le lien, je l'avais déjà parcouru il y a un certain temps. Je l'ai relu et je suis toujours aussi dubitatif. C'est compliqué et finalement on ne voit pas surgir l'élément incontournable qui fait que l'on s'y colle.
Je n'avais pas tout suivi et rebelote c'est compliqué pour quoi ?
Je dois dire que l'exemple que donne Paul est assez impressionnant. Perso je n'y comprend rien ! et le pire c'est que l'on ne devine pas à quoi cela peut conduire.
La POO suivant son implémentation ce n'est pas toujours simple, mais les interfaces ressemblent à la forêt vierge.
Les cerveaux plus jeunes sont certainement plus malléables mais là le mien à atteint le seuil de son incompétence !

les interfaces c'est un juste un outil, des fois il est pratique de s'en servir.

1) pour les DLL

dans Delphi 7 Studio, et notamment le chapitre 19 qui est disponible en ligne, je parle entre autre des plugins. Il n'est pas possible de partager un objet entre une DLL et un EXE sous Delphi, mais avec une Interface ça ne pose aucun problème.

2) l'héritage multiple

dans la POO si tu veux manipuler deux objets différents par le même code, ils doivent avoir un ancêtre commun. Grâce aux interfaces tu peux lever cette limitation très facilement (j'en parle ici d'ailleurs).

techniquement, une interface est un tableau de méthodes, dans Delphi 7 Studio je montre d'ailleurs qu'on peut très bien manipuler les interface à partir d'un simple RECORD
Quand un objet implémente une interface donnée, c'est qu'il est capable de fournir un tableau contenant l'adresse de toutes les méthodes de l'interface dans un ordre établi. Du coup l'objet qui utilise ce tableau peu invoquer la méthode n°x car il sait que c'est la fonction attendue.

tu peux même faire les choses à l'envers, imaginons que tu as deux objets qui ont une fonction Draw(Canvas: TCanvas), les deux fonctions sont totalement différentes , ne sont pas virtuelles, mais tu voudrais pouvoir appeler indifféremment l'une ou l'autre en plaçant ces objets dans un TList, ce n'est pas possible en POO, mais si tu ajoutes l'Interface suivante à ces deux objets;

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
  IDraw = interface
  // ajouter ici un GUID généré par Ctrl+Shift+G
    procedure Draw(Canvas: TCanvas);
  end;
 
  TObjet1 = class(..., IDraw)
    procedure Draw(Canvas: TCanvas);
  end;
 
  TObjec2 = class(..., IDraw)
    procedure Draw(Canvas: TCanvas);
  end;

tu peux manipuler les deux objets comme des TObject et faire un (TObject(List[Index]) as IDraw).Draw(Canvas);et ça c'est plutôt pratique...le seul bémol c'est que toute interface implique l'usage de IInterface qui ajoute AddRef et Release pour gérer la durée de vie de l'objet et si tu ne dérives pas de TInterfacedObject ou TComponent tu dois aussi ajouter ces méthodes.

@PaulTOTH : Exactement c'est vrai qu'en débogage faut parfois aller chercher un peu plus loin, mais c'est une autre façon de coder que je trouve peut être plus "moderne", je vois d'ailleurs que tu les utilises pour le TMouse3D mais je n'ai pas la prétention de pouvoir t'apprendre quelque chose

si tu parles de ce TMouse3D, c'est normal, c'est un objet COM

[joc02]

Comme le dit "Paul Toth", les interfaces peuvent résoudre certains problèmes de base.
Mais si on va un peu plus loin, les interfaces sont un élément de base de la programmation-objet. Effectivement la POO vous donne accès aux portées (private, public, ....). Mais cela serait vraiment trop restrictif de se limiter aux portées et au polymorphisme.

Lorsque vous avez appris le dev, on vous a expliqué quelques règles de bases :
- Si on connait le nombre d'itération et que l'on veut tout parcourir alors on utilise un FOR
- Si on ne connait pas le nombre d'itération ou si l'on souhaite sortir avant d'avoir parcouru tous les items alors on utilise un WHILE
- Ne pas copier-coller du code, mais en faire une procédure
...

Pour le développement objet c'est pareil il y a des règles. Et une des règles de bases est de concevoir ses objets par composition. Afin que chacune des responsabilités de classe soit bien séparée. Les interfaces deviennent donc quasi obligatoires.
Certains développeurs utilisent cette méthodologie :
- Ecriture des interfaces
- Ecriture des classes
- Implémentation
- Test fonctionnel (soit test unitaire / soit sous console dos)
- Implémentation de l'interface graphique.

[Paul TOTH]

[...]
Pour le développement objet c'est pareil il y a des règles
[...]

je crois que c'est ce qui me distingue des développeurs académiques, j'ai commencé la programmation tout seul sur un commodore 64 dans les années 80, j'ai découvert la programmation objet tout seul avec la doc de Turbo Pascal 5.5, j'ai découvert les interfaces quand elles ont été ajoutées à Delphi (2 ou 3 je ne sais plus)....bref j'ai une approche de la programmation très empirique et autodidacte...de nos jours Internet permet d'avoir toute la doc que l'on veux sur tous les sujets...mais ce que je vois c'est plus souvent "il faut appliquer les règles" que des explications sur le pourquoi...or à mon sens le pourquoi est fondamental, les règles sont secondaires et j'aime les transgresser car je sais pourquoi je le fais