There may be no "I" in "team", but there sure is an "I" in "SOLID", and that's what this episode is all about: The Interface Segregation Principle.

I remember, long ago, a nemesis of mine on comp.object used to accuse me of being a racist because I used the word "segregation" in this principle. He also took note that I called a particular design pattern "TaskMaster". Ah, Elliott, I sometimes miss your thorn in my flesh.

In this episode we're going to talk about the problem of too much knowledge. We'll show the strange backwards dependency that happens when classes know too much, and the problem that backwards dependency causes.

I'll tell you the story about how the Interface Segregation Principle came into being. It's a story about a company that had a big build-time problem. I'll show you the bizarre solution we discovered to fix that problem, and tell you why soot was so important to that discovery.

We'll talk about fat classes—classes that have too many methods, and too many dependents. We'll discuss the problems they cause, and how to resolve those problems.

We'll watch a young novice under the tutelage of her master as she struggles through the ATM case study and investigates why too much knowledge harms system structure.

Then, we'll investigate the physical structure of interface segregation, and once again assert the importance of the boundary between the application and main.

Finally, we'll talk about the principle behind the principle, and why this principle which, on the surface of it, seems to be about static typing, is actually not about static typing at all.

So pack the kids in the car, strap the bikes on the roof rack, and cram the tent in the trunk, because we're about to drive into the rugged territory of the Interface Segregation Principle.