Android WTF: Java Interfaces By Example

What is an Interface?

Before I explain things on my own terms, I would like to start by introducing you to the technical definition, because it will eventually become important to understand. If you aren’t aware of half the things in it, then skip it and don’t worry at all!

Example 1: How to implement a bad Solution

Our current task is to figure out some way for Buttons to communicate with Activities. Since doing this for real would be a monumental waste of our time, I’ll provide you with some pseudo-code examples which contain only relevant implementation details. We’ll start by solving the problem with a quick solution that ‘works’ (at least hypothetically), but also sucks. The important thing is why it sucks; as we’ll see later.

Example 2: Changing Requirements

A few hours before the official release of Android, our project manager decides that it would be a great time to add a few items to our launch check-list, because keeping clients happy is more important than letting engineers deliver a solid and tested product (amirite lol?).

  • We must figure out a way for multiple Views (Buttons, ImageButton, Pickers, etc.) to talk to whatever class contains them.
  • This solution must also work with multiple classes, as we now have Fragments which can also contain/handle Views.
  • Some signs of Tightly-Coupled code: Excessive Explicit Dependencies, changing code in one class/unit breaks other classes/units, excessive specialized classes which do similar things.
  • Some signs of Loosely-Coupled code: Dependencies are made explicit/abstract depending on likelihood of changing requriements and what the situation calls for, you can change specific classes/units of code without breaking other classes/units, classes are only as specialized as they need to be and emphasis is put on reducing complexity and repetitive code (this trespasses in the realm of Cohesion, but I’ll save that for another post).
  • We no longer have any explicit dependencies in our Button class. This means that our Button is set up to talk to any kind of class, as long as it implements the interface. This is a great example of “loose-coupling” in action.
  • We can also reuse this interface with multiple kinds of Views, as the interface doesn’t have any dependencies to begin with.

Example 3: I guess Interfaces are pretty useful sometimes…

To finish off this Sprint, we need to make a Fragment which talks to a View the same way in which an Activity can. But we’ll make this more complex by creating a different kind of View as well; an ImageButton:

  • Our old solution kind of worked at first, but started to suck really bad once our requirements changed. We don’t always need flexible solutions, but we should try to understand when we might need them.
  • Our new solution can now handle changing requirements quite easily (as we just did). We could cook up all kinds of Views and Managing Classes, but they just need to respect the Contract/Interface in order for things to function properly.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ryan Michael Kay

Ryan Michael Kay

Self-taught software developer & student of computer science.