空对象模式的好例子？ （通过邮件服务提供一些服务）
对于我正在开发的网站，我创建了一个在前端和后端 (CMS) 中使用的媒体服务对象。该媒体服务对象操作本地存储库 (DB) 中的媒体；它提供了上传/嵌入视频和上传图像的功能。
换句话说，网站访问者可以在前端执行此操作，但网站管理员也可以在后端执行此操作。
当访问者在前端上传/嵌入新媒体时，我希望此服务向管理员发送邮件，但当他们自己在后端上传/嵌入媒体时，不要向管理员发送邮件。
因此，我开始想知道这是否是将模仿邮件功能的空对象传递到后端媒体服务的好例子。我认为当他们决定后端也需要实现邮件功能时，这可能会派上用场。
简而言之，我想做这样的事情：
前端：
$mediaService = new MediaService( new MediaRepository(), new StandardMailService() );
后端：
$mediaService = new MediaService( new MediaRepository(), new NullMailService() );
您对此有何看法？这有道理吗？或者我是否正在为未来的问题做好准备？
For a website I'm working on, I made an Media Service object that I use in the front end, as well as in the backend (CMS). This Media Service object manipulates media in a local repository (DB); it provides the ability to upload/embed video's and upload images.
In other words, website visitors are able to do this in the front end, but administrators of the site are also able to do this in the backend.
I'ld like this service to mail the administrators when a visitor has uploaded/embedded a new medium in the frontend, but refrain from mailing them when they upload/embed a medium themself in the backend.
So I started wondering whether this is a good case for passing a null object, that mimicks the mail funcionality, to the Media Service in the backend. I thought this might come in handy when they decide the backend needs to have implemented mail functionality as well.
In simplified terms I'ld like to do something like this:
Frontend:
$mediaService = new MediaService( new MediaRepository(), new StandardMailService() );
Backend:
$mediaService = new MediaService( new MediaRepository(), new NullMailService() );
How do you feel about this? Does this make sense? Or am I setting myself up for problems down the road?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我是这种模式的粉丝。我也喜欢重命名对象以匹配语义。
如您所知，使用 NullObject 可以获得的两个好处是：
1) 避免在代码中检查 null
2) 将行为合并到一个对象中，该对象表示返回 null 时语义上发生的情况。
如果您有一些 if 语句在管理员上传时返回 null，那么是的，我认为在对象中捕获它很便宜并且可能有用，即使您为后端上传发送邮件的可能性很小。如果您将邮件服务视为通知服务，那么您可能拥有 FrontendNotificationService（发送邮件）和 BackendNotificationService（当前不发送邮件，但可能会积累有关上传的有用统计信息（数量、总大小等） .)。
如果以上都不成立，那么我个人会发现一个没有 NullMailService 的构造函数更具可读性，而一个带有 StadndardMailService 的构造函数则更具可读性，
好消息是，当您认为它有用时，可以轻松进行重构。 ，或者如果您想尝试 NullService 并发现它没有用，请撤消它
，
贝里尔
I am a fan of this pattern. I'm also a fan of renaming objects to match semantics.
As you know, the two benefits you get from the use of a NullObject are:
1) avoid checks for null in your code
2) consolidate behavior into an object that represents what is happening semantically when null is returned.
IF you have some if statement that returns null when the administrators upload, then yes, I think capturing that in an object is cheap and potentially useful, even if you the likelihood of sending mail for backend uploads is small. IF you look at the mail service as a notification service instead, then you might have FrontendNotificationService (which sends mail) and BackendNotificationService (which currently doesn't send mail, but may accumulate useful statistics about the uploads (how many, total size, etc.).
If none of the above is true, then I would personally find a constructor without the NullMailService more readable, and one with the StadndardMailService, more readable.
The good news is that it is an easy refactoring to do when you decide it's useful, or undo if you want to try out your NullService and find it isn't useful.
HTH,
Berryl