Nice post Tim.

+1 Really nice post. Thanks!

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Nice post.  I don't currently use SRP but thanks to this post i know exactly what it is and how i would use it.  Good Stuff!

"(Note to BCL junkies: yes I know there is a SendAsync method).  There are a few instances in our application where we want email to be sent right away and not queued."

Are you suggesting that SendAsync doesn't send the email immediately? Not a big deal, but it works the same as "Send", but the call itself is asynchronous.

First, thanks for re-reminding me of the RDD concepts: Know, Do, Decide - it's a great, and useful, distinction.

Second, I found the "now you might be thinking..." comments kind of annoying, until I realized that, yes, that's exactly what I was thinking. It was useful to get called on it. So...thanks for that, too.

You don't show how these classes are being used.  When do you know whether to use Queued or Realtime if you don't use an if statement?  There's an if statement in the PriorityBasedEmailService which seems like more conditions could be added on later.

Ok, I was just trying to clarify what you were saying.

Personally, I avoid SendAsync as well.

I'm talking about how consumers would use this class.  How would they know to use one mail service or the other?  If the only difference is the mail priority, I'm not sure why the Queued or Real time services would even need to be exposed to the client since sending it to the PriorityMailBasedService would take care of sending the email without the client needing to worry about the priority which seems to be more agree more with the Law of Demeter.  Forgive me if I am being dense.

@Lance probably IoC would do that, you can configure a specific class to be resolved.

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #258

Pingback from  Dew Drop - January 6, 2009 | Alvin Ashcraft's Morning Dew

What happens when you have a second high priority message to send before the previous high priority message send is complete?  Don't the high priority messages need to queue up also?

Not to disagree with how you implemented the solution you decided upon but rather to suggest another solution; Did you consider have multiple queues and a class to pull from the queues based on priority?  Ie. a low priority and high priority queue. Many MTA's use this approach as it is conceivable that many high priority emails will need to be sent at any given time. At that point, you need to work through all the high priority items before returning to normal or low priority items in the simplest approach. Others might do a biased round robin H-H-N-H-H-N-H-H-L-H-H-N ..... kind of thing.

Nice post.  However, I would remind people to also adhere to the DRY principle, in the chance that you have email-sending-related code that is the same in all three classes.

A few months ago I blogged about how we're using the single responsibility principle in our application

A few months ago I blogged about how we're using the single responsibility principle in our application

Hi Tim,

I really dig Uncle Bob the SOLID principles, but many of my esteemed colleagues are still skeptical.  Which method do you find to be the most effective in convincing your team members to adhere to SRP when adding code or making changes?

a) Bribery (I myself am fond of fine chocolates)

b) Blackmail

c) Clockwork Orange-style ultra-violence

thanks.

i wonder if this wouldn't be a good place to implement a specification and strategy pattern?

if you simply created an abstract EmailService class with an abstract method of Send and an abstract method of Satisfies then you can simply have Queued and RealTime both inherit from the EmailService class

by doing this the RealmTime and Queued class "know" if the message is valid for their type of service (through the Satisfies specification method) rather than having the PriorityBased class "knowing" that information

not only does this give you SRP but this would also give you the open closed principle as well

and while i think that the you do have (or are implementing) DRY... there still seems to be something about the EmailService class that i feel is common across all of the services (e.g. the bounce email address, the smpt server name, validation etc...)

any ways... just my two cents

meisinger

I like the idea of the strat pattern and I am busy learning the mechanics of it. Could you maybe post some sample code of how you would achieve this using strat pattern.

Cheers