XML FeedsI suspect that if you are reading this blog then you are using an IoC container to resolve your dependencies. If you do not and you just read this blog because you think I'm an awesome guy then that is fine too, but you should now take the time to learn how to use IoC/DI.
For those of you using IoC, I wonder how many of you have this.
- Public Interface IInterface1
- Sub DoSomething()
- End Interface
- Public Class Class1
- Implements IInterface1
- Public sub DoSomething() Implements IInterface1.DoSomething()
- End Sub
- End Class
All this in the hope that someday you will get another class that implements IInterface1. But will you ever get a second implementation, think very carefully now, you know that if the answer is no, that you should call YAGNI.
And with most containers you can easily go without the interface since they will let you register a class without the interface. And whenever you do need that second implementation you can just use Resharper and it will take care of it.
I know that in the past I made to much interface I never was going to use anyway. And although programming to interfaces is nice it also adds some overhead. More code is more maintenance.
So there are pros and cons to both approaches. But at this point in time I am of the opinion that you should use them wisely. I might change my mind again sometime soon. I am open to discussion.
Christiaan is a forensic technician who programs on the side, although my function description says that I do IT-things for 90% of the time . I'm an avid VB.NET fan and I use lots of the ALT.Net techniques, like unit-testing, nhibernate, logging, IoC, ...
Don't you run into issues trying to mock concrete classes for unit tests? I thought that was a good reason for having the interface w/ one implementation, I would love to be proven wrong though. 
If you use mocks then yes that is a good reason. But you could just make your methods overridable. I guess in java this is less of a problem since everything is overridable by default. 
You have to be careful with mocking concrete objects. I don't know for sure on others, but I know Rhino Mocks will still call the constructor of the conrete object when you create the mock and it's very tricky to debug a test that is inadvertently calling the real method for some calls and the mocked one for others. 
I find interfaces a better way of communicating the design then class definitions, so I'm not sure YAGNI applies here as I find it easier to re-factor and communicate a design using interfaces, than scrolling through all the implementation to find the method/property definitions.
LTD Social Sitings
Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.