Foo: IFoo is an Anti-Pattern
Monday, October 14, 2013
This simple code, used in so many examples, has always bothered me.
class Foo : IFoo
The idea is that we have abstracted an interface so we can be solid and our IoC container will even make this easier. We must be on the right path. Right?
Wrong.
One goal of dependency inversion is that we can swap out implementations. Take this example.
class Authentication : IAuthentication
We're basically declaring that we haven't thought about this very much and we're just typing away, brain off. What would another implementation even be called?
class Authentication2 : IAuthentication //???????????
We can do better.
class Oauth2Authentication : IAuthentication
Immediately, we get the idea that other implementations might be:
class ActiveDirectoryAuthentication : IAuthentication
class LdapAuthentication : IAuthentication
class SamlAuthentication: IAuthentication
Foo: IFoo is a give up.
If you see a mistake in the post *or* you want to make a comment, please submit an edit.
You can also contact me and I'll post the comment.
Can we go further? Can't we just say that class Oauth2Authentication is the interface? I mean, why do I have to care if it implements IAuthenticate? Do I care if it implements that "interface" or do I care if it has or doesn't a method called Authenticate?
You've brought up two future posts. :-)
I would say the interface is the Authenticate method. I hinted at this at the end of https://kijanawoodard.com/viola...