Design for Reuse?

I've been reading "Microsoft .NET: Architecting Applications for the Enterprise" by Dino Esposito and Andrea Salterello the last few days, and really enjoying it. It's not a detailed coding book, but discusses patterns and approaches, and is bringing me up to speed on some of the areas of development I haven't yet explored, or have explored but need a refresher on. I actually found myself sitting on the couch on Saturday afternoon while the kids were asleep, reading it because it applies directly to what I am doing this week.

One of the points it made (I should have highlighted it, because I can't find the page now), is that you put interfaces on classes not for reusability, but for replacability. That's a whole paradigm change from what I use to do, but have now adopted with TDD and Dependency Injection.

I used to spend hours trying to factor out what I thought would be common code, and got stuck just trying to figure out how loggers would work (in days before log4net) or data access for a certain class. To me, back then, the money was in designing for future needs.

Now I realize that most of those common modules have already been written, and it saves me a lot more time and money to design each class I write with an interface and to be able to swap it out using dependency injection. I can try and guess for years what my next implementation of a business process might look like, and I will fail 99% of the time. Build what you know now, put it behind an interface, and swap out the old for the new.

It seems pretty elementary now, but even a year and a half ago, I didn't get it. It's like a huge weight has been lifted off my shoulders, and I am no longer stuck in future requirements purgatory!