Once again, we went to a presentation by - Intentions & Interfaces - Making Patterns Concrete. We would also attend his other presentation, which was immediately after this one, which of course must make us Udi's groupies... :)

Udi is a very dynamic speaker. He gives the impression that he really knows what he's talking about, and not only that, he has done it. For this presentation, I was so caught up in what he was talking about, and how it would solve problems I have to solve RIGHT NOW, I didn't take especially good notes. So, I'd recommend checking out the link to his slides above for the details, but basically, the premise was to build interfaces for all of the different cases where you would need an object, instead of having a large class with a lot of different methods. If you have a customer object, and sometimes you want all of the orders for that customer (but most of the time you don't), you have two methods (or as someone in the room suggested - one method with a boolean - I've done that as well). Obviously, over time, when you take into account all of the scenarios, you can end up with a lot of methods and a very large class.

The bigger problem, of course, is that these methods are only loosely related (they pertain to the same object, but they don't have the same purpose - a clear violation of the single concern principle. By creating interfaces, and then creating classes for those interfaces, you can pull that functionality out into different classes, and seperate the concerns. It also reduces your coupling - the customer class doesn't have to know about the orderdetails class in order to work with its child orders.

Its definitely a lot of common sense stuff in a way, but I probably never would have thought of it that way. I need to throw together my own reference application to fully assimilate what he talked about - I don't think I'm doing it justice in this post. It was good stuff - got me thinking, anyway...