Salut,Cette réflexion montre sans doute que tu as une très mauvaise idée de la manière de concevoir ton application d'un point de vue orienté objet...
Tu sembles concevoir tes classes en fonction des membres qui les composent.
Si c'est un point de vue on ne peut plus correct en conception "non orienté objet", c'est, malheureusement un point de vue totalement erroné (j'aurais meme tendance à dire "obsolète") lorsqu'il est question de concevoir une application dans une optique orientée objet.
En effet, l'idée même de la conception orientée objet est de ne plus réfléchir en termes de donnée utilisées, mais en termes des services que tu peux attendre de la part des différentes classes que tu envisages d'utiliser.
Les données membres ne doivent donc plus être envisagées sous la forme de l'ensemble des données qu'il faut utiliser pour représenter un type particulier, mais bien comme ce qui es nécessaire pour permettre à ta classe de fournir les services au tu en attends.
En respectant ce principe, on se rend compte que l'utilisation d'accesseurs ou de mutateurs devient tout à fait marginale, la plupart des services offerts par la classes en prenant facilement la place
Si tu respecte ce principe, et que tu respectes, en parallèle, le principe de la responsabilité unique, tu te rends compte que le fait de connaitre le serveur POP ou SMTP (ou le port sur lequel se connecter au serveur) ne fait pas partie des services que tu es en droit d'attendre de ta classe mail.
Cette responsabilité devrait échoir à... la classe qui devra soit récupérer les mails soit les envoyer
La moralité de cette histoire, c'est : commence par déterminer exactement quelle responsabilité tes classes doivent avoir, en veillant à ce qu'elle reste unique, détermine ensuite les services que tu es en droit d'attendre de ces classes.
Les données qui permettront à tes classes de fournir les services attendus "tomberont" alors sous le sens, et ton design n'en sera que meilleur
Partager