Bigger isn’t better

The idea behind Interface segregation principle is that big isn’t always better. Sometimes a small, perfectly formed interface offering only one or two methods is better than a large interface that forces anyone creating a derived type to implement lots of methods, even if they’ll only ever want to use a small subset of that functionality.

Sorry folks, no witty analogy this time, instead we’ll look at a bad example of interface design.

When Microsoft built their ASP.NET platform for building websites they wanted to make it easy for software developers to setup common website features like registering user accounts, allowing users to log in, allowing users to reset their passwords etc so they built all this functionality into their framework so that you didn’t have to do much work to achieve that functionality on your websites.

However, they also wanted web developers to be able to do things differently if they needed to. For example, you may have an existing users database and you might need to use that instead of the default membership provider Microsoft gave you so they gave developers the ability to create their own membership providers.

The membership provider an abstract class consisted of twenty nine abstract properties and methods that developers would need to provide an implementation for in order to use the built in membership tools.

You may not have needed a lot of those features such as locking a user out, allowing a user to reset their password etc, but you still had to provide all the abstract functionality. It would have been much better if each feature had its own interface and you could pick and choose the features your own membership service would be providing.

public interface IAmGod
{
void DoAllTheThings();
bool IsItRaining(Location where);
void KillThem(Person toKill);
void KillThemAll(IEnumerable toKill);
Baby MakeBaby(Egg egg, Sperm sperm);
bool IsHellToPay();
Miracle RandomMiracle();
IEnumerable MakeToast(IEnumerable bread);
}

//WTF - I only wanted to make a Toaster

public class Toaster : IAmGod
{
public void DoAllTheThings()
{
throw new WhyTheHellAreYouMakingMeImplementMethodsIDontNeedException();
}

public bool IsItRaining(Location where)
{
throw new WhyTheHellAreYouMakingMeImplementMethodsIDontNeedException();
}

public void KillThem(Person toKill)
{
throw new IDontWantToGoToPrisonException();
}
public void KillThemAll(IEnumerable toKill)
{
throw new IDontWantToGoToPrisonException();
}

public Baby MakeBaby(Egg egg, Sperm sperm)
{
throw MissingTurkeyBasterException();
}
public bool IsHellToPay()
{
 return true;
}

public Miracle RandomMiracle()
{
throw new WhyTheHellAreYouMakingMeImplementMethodsIDontNeedException();
}

public IEnumerable MakeToast(IEnumerable bread)
{
  //At last we can create the one method our Toaster needs
  var roundOfToast = new List();
  bread.ForEach(slice => roundOfToast.Add(new Toast(slice));
  return roundOfToast;
}


}

The final post in this series covers the Dependency Inversion Principle.