@JavaLand

ranting-homer2_1.gifWhy does everything (say Foo) need to have an interface … IFoo … can you come up with three possible implementations you need over the next 3 months in a minute?

If you can’t… then you don’t need the interface. Interface is a contract … only has intrinsic value if you have/need multiple implementations of a contract. If you do not have that use case… you do not need to create clutter by mechanically creating an interface … YAGNI. This is all over the Java landscape:

SimpleFoo implements IFoo… That’s it … no other implementation. What’s the point of IFoo?

Let’s say you can think of multiple implementations … before your first implementation… do you know for certain what the contract is going to look like?

This is rarely the case … it’s much better to rely on the Extract interface refactoring … build what you need first … use TDD if possible so you know that your code is easy to interact with … then introduce an Interface if/when you need a second implementation. By defining IFoo first you are unnecessarily locking yourself into a contract which you might not be able to honor.

A spurious IFoo is very `enterprisey` and all its let’s you do is bask in the glow of an accidentally complex `enterprise` app

I feel much better now 🙂 Better out than in- Shrek

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to @JavaLand

  1. Kailash says:

    Having interface is more of about having contract.
    When working in multi layer architecture where a particular service is suppose to expose only certain set of apis (not all public) to the layer above it and meant to expose more public apis to the layer in which it is. Here this particular service (though single implementation) needs to be interfaced.

  2. bsandhu says:

    Typically the layers belong to the same system/sub-system. In the scenario you sighted, why not simply use the package level permission – which handles this use case exclusively?
    In case they are not in the same system/micro service etc. – the game change because you are effectively looking at an external system.

    The point is that the contract mechanism is overused thoughtlessly and creates cognitive overhead.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s