Pfthb

I've been programming for a couple of years now. Interfaces have always seemed to have been difficult topic for me to wrap my head around. Is it a good practice to abstract as much functionality as possible into interfaces?

I have never fully understood the benefit of them. I always thought that "why not just write the methods normally". They are just methods. And then I started learning about dependency injection and how it really simplifies code to have the the constructor be the main point of contact to the outside world for the class.

But then, recently, I started thinking about interfaces again and how they can be thrown around like Types, not just a cute way to tag methods.

So in my first real experimentation with interface use in Java, I made this example, and what I would like to know is:

For Java developers who know the power of interfaces, does this little snippet of code I wrote illustrate a good pattern or good line of thinking? Basically is this good code so far? I would just like to know if I'm on the right path. I have a second interview tomorrow for a job and would like to bring up this realization during the interview, if and only if I am on the right path.

Here is the code:

interface Fightable
void kick(Fightable enemy);
void punch(Fightable enemy);
void takeDamage(Fightable enemy, String typeOfStrike);
void strikeEnemy(Fightable enemy, String typeOfStrike);


interface CanEat
void chew();
void swallow();


interface MotherShip
int motherShipBoost = 50;
String getColony();
void sendHelp(int location);
String buildMoreShips(int amount);
void flyToNewSystem(String newSystem);
int beamDownRandomly();


interface Animatable
void animateChew(CanEat eater);
void animateSwallow(CanEat eater);
void animateMove(Moveable mover);
void animateRevive(CanEat eater);
void animateStrike(Fightable striker, Fightable receiver, String typeOfStrike);


interface Moveable
void setNewLocation(int newLocation);
int getLocation();
void move();


public class GameCharacter implements Fightable, CanEat, Moveable

private int health;
private String name;
private int location;
private String stamina;
private String origin;
private String colony;
private Animatable animator;
private MotherShip motherShip;
private boolean isRecruited;

public GameCharacter(MotherShip motherShip, String name, Animatable animator)
 this.motherShip = motherShip;
 this.animator = animator;
 this.name = name;
 this.location=this.motherShip.beamDownRandomly();
 this.colony = this.motherShip.getColony();



@Override
public void kick(Fightable enemy) 
 strikeEnemy(enemy, "KICK");





@Override
public void punch(Fightable enemy) 
 strikeEnemy(enemy, "PUNCH");


@Override
public void takeDamage(Fightable enemy, String typeOfHit) 
 this.health = this.health - 3;
 animator.animateStrike(enemy, this, typeOfHit);
 if(this.health < 10)
 motherShip.sendHelp(this.location);
 


@Override
public void strikeEnemy(Fightable enemy, String typeOfStrike) 
 enemy.takeDamage(this, typeOfStrike);
 animator.animateStrike(this, enemy, typeOfStrike);


@Override
public void chew() 
 animator.animateChew(this);



@Override
public void swallow() 
 animator.animateSwallow(this);
 health = health + 10;
 animator.animateRevive(this);


@Override
public void setNewLocation(int newLocation) 
 this.location = newLocation;


@Override
public int getLocation() 
 return this.location;


@Override
public void move() 
 animator.animateMove(this);

Does it look like I have the right idea?

Thank you for any feedback

-T

At first, interface exists to implement all of the non-default methods described in it. That can be easily replaced by abstract class. However, in order to sanitize in an easier way, interfaces have been implemented.

As soon it seems logical and an easier for you to use interface, there is no such thing as too many interfaces. However, as soon you or your co-worker get headache to get the picture, it is too much.

Use interfaces as an extra way to ease sanitizing and structuring processes.

Moreover, java doesn't support multiple inheritance in case of class. So, by using interface, you can have multiple inheritance as you did in your example.

Really good job and good luck for your interview!

I'll try my best to agnostically answer your question as best.

1.

Is it a good practice to abstract as much functionality as possible into interfaces?
Let's begin with the basics
a) Remember interfaces are nothing more than "contracts", a promise that an actor that implements an interface basically promises to honor and delivery on the contracts terms and conditions.
b) Interfaces act as excellent design tools in code, essentially allowing the producer and actors to focus on the high level of their interactions without worrying about implementation details.

In CS basics layman's terms an interface promises conformity, essentially 3 things.
1. a promise that a said functionality/operation/function/method is available
2. that this functionality accepts a said agreed input
3. that (if implemented) this functionality will yield said results.

So when a piece of service (class/soap message etc) offers the intent of implementing an interface it publicly agrees to those 3 terms of the "contract" and any deviation from them is a violation of the contract.

2.

Yes, you are absolutely correct, interfaces really show off their power when it comes to Ioc (Inversion of control) in SOLID design principles that allows an IoC container to resolve (provide) and serve a suitable actor (implementation) that honors a contract, often at run time therefore freeing the system developer to not worry about implementation details.

But perhaps the benefits of Ioc will often only be realized when implementing a service locator pattern therefore, "how does a developer or team benefit from using interfaces as a design tool?" becomes an important question.

Single developer
As an example I'm busy writing a new software system and during the day, I applied my mind on the kind of functionality I'd like to offer my users, perhaps be able to manage their todo list in a general sense, which entails the ability to "create" new todo items, "clear-check" existing items and "remove" items from their todo collection. Now there are several ways of implementing each one of these features and become I'm lazy, I'd rather spend the next week delivering on just one of those features but I might forget my initial thoughts and end up implementing features of my own based on my influences as time goes on, to discipline myself and stick to what I initially thought out, I chose to rather draft a contract of this functionality upfront without actually implementing it which will allow me to simulate these features than actually implementing them. So by using interfaces, I have laid down the foundation of what I need to achieve in the next weeks and I can go back to it every other day and complete my features without breaking my promise...which bring us to the next topic which I won't delve too much on now of Open Close principles (the O in SOLID) that basically says my designs are closed to external changes but open for internal changes and perhaps event open to expansion (addition). so I can add new features onto my todo service without breaking my exiting contracts and I can change their implementation behavior but cannot change the shape of existing features.

In a team
I work with Lindile and Selebalo in implementing a virtual card system and because the work is too much, We decide that I will focus on the core banking system (balance ledger) and Lindile will focus on the deposits of the VC while Selebalo focuses on the deposits of the VC. During our initial design session, we design from inside out starting with the core banking and describe which operations will be available for updating a customer's account and after a few hours of discussions we decide that the core banking system will offer two functionalities, one for adding money into an account, called "credit" that accepts an amount and "debit" that deducts or reduces the customers account that also accepts an amount. But because the core has to deal with a lot of other things (customer credit profiles, AML, etc) besides debits and credits it might take a while until I can say the guys can integrate and test their codes so we decide on a contract of core banking that has

public interface ICoreBankingServices

Balance Debit(decimal amount,Currency c);
Balance Credit(decimal amount, Currency c);

Now Lindile and Selebalo can work on the assumption that I will honor the contract and choose to mock or simulate results from Debit and Credit until we are all ready to integrate and test and therefore there is no development dependency of my features for them to work and that's a positive thing.

I hope these examples paints some of the basic benefits of using interfaces a design tools and dependency decoupling mechanisms.

I am no Java expect but if the game character has to fight, eat and move, you are on the right track. You just need to keep a lookout on the level of decoupling that you do (same as normalization) at the expense of increase complexity but there are no guidelines to that and as long as things don't get too complicated, you can describe things in many interfaces as logically possible...just don't apply the same thinking when it comes to multiple implementation inheritance but this is a personal opinion :)

You will have to ultimately have to pay the taxes and learn a bit more about design patterns and what they are trying to solve or simplify in order to grow your understanding on designing better systems.