The interface segregation principle is regarded as the least important of the SOLID principles. I think this is a matter of context. If you’re implementing IGame and don’t need PreviousMoves functionality, you could always just throw a NotImplementedException and not worry about it. Sure, you’ve violated Liskov quite badly by doing so, but not in the contexts that you actually care about. The problems will start to develop as the code morphs and your broken abstractions start to matter. It won’t break you half as fast as not using an abstraction in the first place, but it will matter eventually.
Things get more interesting when we start talking SOA. Now, the requirements of SOA are actually exactly the same in this context as ordinary code, it’s just that interfaces, once published are often set in stone. This makes it much more important to pay attention to the requirements of the client. The “client” is often a business process. So, for instance, take a equities trading system. The way an order looks to a trader is very different from the way it looks to the guy trying to settle it three days later. The guy trying to report these trades for compliance purposes has another view, and the guy trying to value them for his risk analysis has another. Interface segregation says that you shouldn’t be passing around the same interface to all of those people. You might still be thinking these should all be facades onto the same object, and they could be, but it’s not necessarily the case. These could be completely separate systems only connected by a messaging interface. So, I’ll finish up with my own corollary of the Interface Segregation Principle:
Unified Models are neither sensible nor desirable.