Bon cas pour un modèle d'objet nul? (Fournir un service avec un service de messagerie)

Question

Pour un site Web sur lequel je travaille, j'ai créé un objet Service Média que j'utilise dans le frontal, ainsi que dans le backend (CMS). Cet objet Service de médias manipule les médias dans un référentiel local (DB); il offre la possibilité de télécharger/intégrer des vidéos et télécharger des images. En d'autres termes, les visiteurs du site Web peuvent le faire dans le frontal, mais les administrateurs du site peuvent également le faire dans le backend. Je voudrais que ce service envoie un mail aux administrateurs quand un visiteur a téléchargé/incorporé un nouveau support dans le frontend, mais évite de les poster quand ils téléchargent/embarquent eux-mêmes un support dans le backend.

J'ai donc commencé à me demander si c'est un bon cas pour passer un objet nul, qui imite la fonctionnalité du courrier, au service multimédia dans le backend. Je pensais que cela pourrait être utile lorsqu'ils décident que le backend doit également avoir implémenté la fonctionnalité de messagerie.

En termes simplifiés I'ld aiment faire quelque chose comme ceci:

Frontend:

$mediaService = new MediaService(new MediaRepository(), new StandardMailService()); 

Backend:

$mediaService = new MediaService(new MediaRepository(), new NullMailService()); 

Comment vous sentez-vous à ce sujet? Est-ce que ça a du sens? Ou est-ce que je me prépare à des problèmes sur la route?

Answer 1

Je suis fan de ce modèle. Je suis également un fan de renommer des objets pour assortir la sémantique.

Comme vous le savez, les deux avantages que vous obtenez de l'utilisation d'un NullObject sont:
1) éviter les contrôles NULL dans votre code
2) consolident le comportement dans un objet qui représente ce qui se passe sémantiquement valeur NULL revenu. Si vous avez une instruction if qui renvoie null lorsque les administrateurs téléchargent, alors oui, je pense que la capture dans un objet est bon marché et potentiellement utile, même si la probabilité d'envoyer du courrier pour les téléchargements backend est faible. Si vous regardez plutôt le service de messagerie comme service de notification, FrontendNotificationService (qui envoie le courrier) et BackendNotificationService (qui n'envoie pas de courrier, mais peuvent accumuler des statistiques utiles sur les téléchargements (combien, taille totale, etc. .).

Si aucun des est vrai, alors je personnellement ci-dessus trouve un constructeur sans NullMailService plus lisible, et une avec le StadndardMailService,

plus facile à lire. les bonnes nouvelles sont qu'il est un outil facile refactoring à faire quand vous décidez que c'est utile, ou annuler si vous voulez essayer votre NullService et trouver que ce n'est pas utile

HTH,
Berryl