I'm using the built-in system class for sending emails in .NET. It's in System.Mail namespace or something like that.
I need to add an interface to this class so I can swap it out for testing or another implementation.
To do this, I just define a class that wraps this built-in class?
Is this an example of the decorator pattern? I'm just a bit confused because the description of the decorator pattern usually states that it is used to add functionality, and I won't be adding any.
No, this is not the decorator pattern, it is the proxy pattern, note: I think Microsoft expects you to make your test class inherit from the SmtpClient class, and implement the Send, AsynchSend etc yourself (in a way that they just write to a text file or whatever -- if you're wanting to plug in a test version). However if you're wanting to do it the correct way, not the microsoft way, do it the way Marc said. You will find more and more examples in .NET of interfaces not being there when they should have been.
Well, that sounds just like encapsulation (the wrapper class) and abstraction (the interface).
However, once you have the interface, you could then use the decorator pattern.
Strictly, in decorator usage each layer has the same interface; the decoration is essentially a daisy-chain of different concrete classes that (when implementing the interface) either pass the method to the next link in the chain, or do something bespoke.
(update: I'm not saying you should do it this way - this is just an example of how the decorator pattern might work, in the context of the original e-mail question)
For example, you might have an interface IEmail, a basic implementation BasicEmail (that uses the built-in .NET code), a LoggingEmail that accepts an IEmail, and just passes things along (but logs things as you go), and a ForwardingEmail that accepts an IEmail and changes the To etc (perhaps for dev/test/live purposes).
Then you could have:
`ForwardingEmail` => `LoggingEmail` => `BasicEmail` => (regular .NET classes)
(where the first three are only known as IEmail)
This allows you to extend functionality without changing the API. Very common in factory / IoC setups, and even more so with AOP.