Sometimes, you need to seperate an specific kind of object from the behavior it possesses from other objects similiar to it. Here is where interfaces and inheritance comes in.
Say you wanted to develop a video game with, shockingly enough, enemies to fight.
Say this was a first person shooter, like Halo. In that game you have super brave Elite mooks, cowardly Grunts, and normal types like Jackals.
In that case, the first thing you'd want to do is code to an Abstraction. Because there are differences, a super class (we'll just call it enemy) can help consolidate that which all of these characters will share. Such as basic statitics like hit points, defensive ratings, and movement. By coding to an abstraction, you can let your game know that things like this will ALWAYS be present, while allowing subclasses to iron out the details in the DIFFERENCEs.
public abstract class Enemy{
//here you'll have your basic constructor and methods for defining the basics of an "enemy" like how they are hostile to you and your friends
setHP()
setDefense()
setMovementSpeed()
setDeathCry()
}
public class EliteMook extends Enemy{
int HP;
int moveSpeed;
public void setHP(){
HP = 9000;
}
public void setSpeed
moveSpeed = 30;
}
//blah blah more methods and stuff
}
But what about the thing that would really make the different enemies interesting? What about differences in BEHAVIOR? Here is where interfaces come in.
Interfaces are not objects. They're a bundled package of references to methods. Interfaces are like contracts for a concrete class, that can only be implemented by other objects, or extended into further sub-interfaces. So in a way, they are kinda like "equipment" packages for an object to use to
better define its sets of behavior. These packages are formally known as
APIs (Application Programming Interfaces).
So in returning to our example, you'll different AI behavior interfaces such as...
public interface EliteMookBehavior()
public interface NormalMookBehavior()
public interface CowardlyMookBehavior()
And what if there were different types of weapons as well? And say you wanted Elite Mooks to know how to use pistols and rifles, and swords, while the lowest of the low only got dinky pistols? Again, separate the behavior as interfaces.
public interface SwordBehavior()
public interface RifleBehavior()
public interface PistolBehavior()
That way, can keep your pathetic grunts pathetic by equipping them as such:
public class Grunt extends Enemy implements CowardlyMookBehavior, PistolBehavior{
/**Now all you have to do is set stuff like their
HP and movement speed and you're done here */
}
While your mighty Elites remain feeling elite by equipping their behavior as so.
public class EliteMook extends Enemy implements EliteMookBehavior, SwordBehavior, RifleBehavior, PistolBehavior{
/**Now then, all you have to do is set stuff like their
HP and movement speed and you're done here as well */
}
And now that you have them all, you can thus store them all in a single array called Enemy. Such is one of the main usefulness behind polymorphism. That way, the first mook may be Elite, followed by two grunts in one case, while it can be a couple of normies a grunt, and an Elite mook to mow down in another case.
And there you have it. A plain, common sense introduction into abstraction, interfaces, and polymorphism. If you relate well enough videogames at least.
~Code Crunch Corner~
