People sometimes ask how to get involved in open source software.  In fact Scott Hanselman posted on a the subject in great detail over two years ago when detailed how you could submit a patch to an open source project.  Good intentions aside, getting involved at the source code level of a mature open source project can be quite daunting. There is a often large, hopefully active, codebase which you might not be too familiar with. Despite your sincere interest in contributing, often the startup "cost" is too great and you find that there is a sense of hopelessness in achieving that goal.  It really doesn't have to be this way.

I'd like to suggest that a great way to getting started with open source is getting involved in the mailing list for a project by answering questions posted by the community.  Nearly all, if not all, of the open source projects I use have either a forum or a mailing list associated with them.

My History in Open Source

Despite my use and open support of open source software I have to date only submitted 2.5 patches to the open source community (the 1/2 patch was me assisting in writing a RegularExpression for the developer who was actually writing the meat of the patch).  Despite my best intentions, I have yet to know an open source codebase well enough in my opinion to submit substantive contributions to the project, so I do my best to contribute in other ways.

I am currently an active participant on the RhinoMocks mailing list where I try to provide answers and guidance on RhinoMocks and testing in general.  When I made the decision to start contributing on the list, my goal was simply to beat Ayende every once in awhile to the answer...seriously, the guy is fast. As I've spent some time on the list I've become more comfortable answering questions and I've seen others jump in and help as well.  I like to think that I'm contributing to the project as a whole, if only by answering questions posed by other users of the framework. Often times, in the absence of others to assist, answering questions falls to the contributors of the project which takes away from the time they would have to further the development of the project.

If you've had a desire or an interest in getting involved and you aren't comfortable contributing via source code, think about getting involved with a project you already use and are familiar with.  Subscribe to the forum and mailing list and challenge yourself to answer a single question, then two or three. I think you'll find that the managers of these projects will be very appreciative of the help!

S.O.L.I.D. principles seem to be a hot topic.  The guys over at LosTechies.com explored it last year in March as their topic of the month and did a great job of it. I know when I read blogs I enjoy when different authors post on similar topics.  I find that often the different examples and explanations paint a clearer picture than can be had with only one example.  I'd like to share an area where we use the Single Responsibility Principle (SRP) in our application

Note: The "aha" moment won't be some thrilling display of how we averted some disastrous bug or how we eliminated some thousands of lines of code.  It will be much more subtle but that's ok.  A good design should strive for an element of simplicity.  Great design is asking to hear the answer to a riddle and then thinking, "duh!  of course"  When you hear the answer you realize how "obvious" it was.

Background

In our application we queue all emails to be handled by a different process since sending email is a blocking call which slows your response times (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. An example of this would be a confirmation email for a new account or a password reset request.

The Fix

We already had a QueuedEmailService class so adhering to SRP, I built a RealTimeEmailService class whose job, and only job, it is to send the email right away.  Thinking of responsibility driven design, classes:

• Know things
• Do things
• Make decisions

With that in mind I needed another class to make the decision to when to send the email through the RealTimeEmailService or when to use the QueuedEmailService:

(At this point some of you might be reading thinking how easy of a problem this would be to solve and you're quite right.  What I want to point out is not the problem, but how one solves the problem.  Nearly anyone could've gone into the QueuedEmailService and added an if statement and sent emails real-time if that is what is needed, thus ignoring SRP.  By lumping all of the work together you aren't building object oriented software...sorry.  And while you might be okay with that and you're software WILL work, you run the risk of more maintenance issues and modularity problems).

Here's what a quick summary of what I've got:

   1: public QueuedEmailService : IEmailService

   2: {

   3:     public void Send(...)

   4:     {

   5:         // add to some queue

   6:     }

   7: }

   8:  

   9: public RealTimeEmailService : IEmailService

  10: {

  11:     public void Send(...)

  12:     {

  13:         // send right now

  14:     }

  15: }

  16:  

  17: public PriorityBasedEmailService : IEmailService

  18: {

  19:     public void Send(...)

  20:     {

  21:         if (priority == MailPriority.High)

  22:             // send using realtime service

  23:         else

  24:             // send using queued service

  25:     }

  26: }

  27:  

  28:  

I know many people who would look at the code above and think it is possibly overkill.  I would disagree for a few reasons:

• Each class does only one thing.  If we have a problem with some piece of functionality it is much easier to debug.  Each of the three classes above in their full implementation will fit on your screen without the need for scrolling.  It's quite refreshing.
• Modular design - since the application only knows that it's dealing with an IEmailService I can easily swap out implementations.  For example, if we decide that we want all emails to be sent real-time, I just change how I've configured Windsor (my IoC container) and it works, because I have a concrete class which sends real-time.  If you were to combine all of your code into one class, you'd have to go back and change your code and go through the pain of deployment.
• Open-Closed principle - since each of the classes only have only one thing they do, I can more easily say they are closed for modification, reducing the chance that I introduce a bug later on.  If you put this code into one big method, you can change the code to meet your new needs, but each change introduces the possibility of introducing a bug.

There are cases when a design can go overboard, but for the vast majority of cases this simply isn't the case.  I'd rather see a solution where someone has gone too far than what I typically see in classes that do it all, with no clear responsibility.

I hope this helps augment your knowledge of SRP.  If you're still a little fuzzy on SRP and what it is, let me know, I'd love to discuss it with you.