Refactoring to Patterns

I got the opportunity to refactor some code this past week.  We had an .aspx page that streamed an m3u playlist file that would open in Winamp.  We wanted to modify the page so that it would stream an .asx file for Windows Media Player or a playlist for a Flash based mp3 player, based on the user’s preferences.

Since the page wasn’t currently reading any preferences, the code to
create the m3u file was right in the page’s class file.  If I had
wanted to add two more formats, I could have added the code for those
two right into the page as well, but I wanted to make it more flexible
so that we could add even more formats later on, in an easy fashion.

So I created an abstract Playlist class and then made three
subclasses, M3UPlaylist, ASXPlaylist, and FlashPlaylist.  Now all
the logic for creating the appropriate playlist files was contained in
its respective class.  Next, I created a PlaylistFactory class
that had one static method

  • static Playlist CreatePlaylist(PlaylistType type)

So now the code on the page looks something like this:

Playlist list = PlaylistFactory.CreatePlaylist(playlistType);
list.Stream(Request);

Now when we want to add a new playlist type, all we need to do is
create the subclass of Playlist, add the new type to the PlaylistType
enum, and we’re all set, no need to change anything on the page. 
This is whats nice about using a factory pattern like this;  when
you want to add something to the system, you just need to write new
code, not change existing code, which makes for less regression
errors.  Theres nothing really like the satisfaction
of refactoring some code.

4 Comments so far »

  1. Anonymous said,

    Wrote on July 10, 2005 @ 8:50 pm

    As you are adding new functionality, this isn’t refactoring!

  2. Anonymous said,

    Wrote on July 11, 2005 @ 4:53 am

    I disagree with the previous post to a point. While by true definition it might not be refactoring how many developers simply refactor code just to refactor. Typically you are refactoring b/c what you are trying to do can’t be done well with the current implimentation. Don’t be so picky. It is refactoring but the developer is also adding more functionality.

  3. breichelt said,

    Wrote on July 11, 2005 @ 5:44 am

    I think yudanja has it right. While I was adding some functionality, I still refactored the current implementation that returned the m3u file. That code was no longer in the page, but rather in the M3UPlaylist class. Had I stopped there it would just be refactoring, but then I went and also added functionality for the other 2 playlist types.

  4. Anonymous said,

    Wrote on July 11, 2005 @ 6:59 pm

    For the results of your refactoring to be verifiable, you should first re-structure the code without adding any additional functionality. Only when this is complete, and your unit tests still pass, should you add anything new.

    It sounds like this is pretty much what you did, but this wasn’t made clear in the original post.

Comment RSS · TrackBack URI

Leave a Comment

Name: (Required)

E-mail: (Required)

Website:

Enter my name (ben) in this box, so I know you're a human.

Comment: