Interface segregation principle

It is better to have a lot of single purpose-specific interfaces than one general purpose interface. Our APIs should not accept references to structures that it does not need, and conversely, our client implementations should not depend on code that it does not use.

We'll see this soon in our Viva La Duck code example in the form of separate EatBehavior and StrokeBehavior interfaces.

When we strictly apply  the integration segregation principle we end up with interfaces with a single method. Such objects represent data with behavior, but it can also be modeled as behavior with data, which is what closures are in FP.

This is another area where it would be nice if Go supported Generics. Why create boiler plate code to handle slices of Int types, Customers, or AvailableWomen when a single enumeration of T would work (with less code)?