I think a lot of people try to over-engineer solutions.
They take the "Adam&Eve" approach when just a slightly more
practical one would simplify things by a great deal.
Specialized classes are not evil, they're the natural
consequence of sound software design.
Many programmers, in my opinion, fail to understand this and
there is no book that I know of which makes this outright clear.
Another thing that certainly helps is TDD, that lets you
understand "how" you will be using the class in practice and can in
many cases save the day, because it shows eventual problems/limitations
early on in the day.
Last, another VERY important thing I would look for if I was you is design patterns.
Design patterns are how people smarter than you or me solve programming problems.
The idea behind patterns, guess what?, is that they're not to be used as cookbooks,
recipes that you just slam there, but thoughtfully and understanding your
application domain first and foremost.
A wise use of pattern will reduce greatly the quantity of details you have to manage.
A good design pattern library designed around your very needs, will prove invaluable.
Let's see a very simple example just to put things in context:
imagine you have a form where, when a button is pressed, other forms have to update
themselves. This is a typical "observer" pattern. You have a subject and several
observers, which register them selves with the subject.
Why do you need to implement an interface? You can just add the methods, or
better yet, use an interface for the observers and a generic list for the subject.
Now you got the best of both worlds: independence for the observers and no
whuzzy-whazzy things on the subject.
Hope it makes sense to you!