Interfaces define the ways objects interact with each other. Properly designing interfaces not only help conceptualize a system, but aid in testing and maintainability of our systems.<\/p>\n\n\n\n\n\n\n\n
This article is going to go beyond the concept of just using the principle of least privilege. We’re learning about this in the context of good design<\/strong> so you can write maintainable <\/strong>and testable<\/strong> code. The examples in this article are going to be in C# because I believe the syntax is optimal for explaining these concepts, but the concepts themselves transcend languages and apply to all OOP designs.<\/p>\n\n\n\n For now, put aside the idea of There are two entities: the sink and you. The sink provides a lot of functionality, but most of it is hidden from you. For example, you don’t need to know how the sink magically summons the water it spits out of the faucet; you don’t need to know how the sink is heating that water; and you definitely don’t need to know how the sink drains the water after it’s washed over your hands and dishes.<\/p>\n\n\n\n All you need to know as a user of the sink is how to turn the water on and off, and which dial gives you what kind of water. You, the calling entity, don’t know the inner workings of the sink, the subject entity. To put this back into a programming point of view, the sink interface’s functional signature would take in the hot and cold dials as arguments and return water.<\/p>\n\n\n\n Imagine if you had to know everything about plumbing just to wash your hands. Not only is this unrealistic, but it makes changing things nearly impossible. If the city implemented a new draining system, you’d have to relearn how that works before you can soak your dishes.<\/p>\n\n\n\n Likewise, this is exactly what happens when you have objects that are too tightly coupled. The calling object that knows too much about its subject is like the plumber washing their hands. The That last sentence is basically the main concept behind designing good interfaces: public interfaces should rarely, if ever, change.<\/p>\n\n\n\n Like I said at the beginning of this article, our examples will use the C# programming language. I think the syntax for objects and their interfaces is the best one to illustrate the necessary examples.<\/p>\n\n\n\n We’re going to make a very simple command line RPG style fighting simulator. We’re going to have a What do we have here? This abstract class defines the base class for all enemies. Each enemy will have a name, hit points that represent how much damage it can take, strength which will control its attack damage, defense which controls how it takes damage, and a boolean variable called We also have a few methods. Besides the constructor, we have Let’s make our We haven’t made any Let’s make a couple of concrete enemy classes. First, we’ll make NOTE:<\/em><\/strong> If the <\/em> Here, we’ve overridden the base class’s abstract methods Why, if we have First of all, calculating the damage within the same method in which we apply the damage would violate the Single Responsibility Principle<\/strong> of S<\/strong>OLID Object Oriented Design. We want each method to have a single responsibility, and the Secondly, Speaking of, let’s make our second Notice here that the Now, let’s see some actual use of these methods:<\/p>\n\n\n\n Run this and you should get something similar to the following output:<\/p>\n\n\n\n Erik attacks Imp Erik attacks Armor Imp Now consider we wanted to add even a third type of enemy, one that counterattacks. The code would mostly look the same, the new enemy would still have a What if we wanted to add deflection capabilities to our In theory, this new feature should not require any<\/em><\/strong> changes to our public interfaces. In fact, it doesn’t:<\/p>\n\n\n\n Nothing needed to change in order for this new feature to be added because we had a good separation of our public and private methods.<\/p>\n\n\n\n It’s kind of funny to have spent all this time talking about interfaces and not once using the keyword What is it about Attackable. That’s definitely not a real word, but it segues well into deciding when to use an abstract class vs when to use interfaces. Enemies are attackable. In Zelda, bushes are also attackable. So if we wanted to implement something similar in our game, like a tree our Conceptually, no. We could, of course do it this way, but making it work would look super shady. Likewise, any functionality we’d want to add to our sentient enemies would also get added to our non-sentient trees. In this case, trees and enemies don’t exactly share traits, but they do share roles. Specifically, they share the “attackable” role, which is what we’re going to name our interface. We’re going to name our interface Now, head over to the What has this done for us? Haven’t we really just added some constraints on ourselves, forcing us to always write these three methods for any class implementing this interface?<\/p>\n\n\n\n Well, yes. And trust me, I get it. It does look like a bit of unnecessary self-restraint, but try to look at it from a bigger picture. Imagine you’re developing this game and you decided you wanted to add Even better, imagine you are in a large company with multiple teams working on the game. Another team has been tasked with implementing trees that our Finally, it gives us a little something we might neglect. It helps us understand the system better. Think about Likewise, for any class implementing the We’ve learned that public interfaces should rarely change, and private ones are the real workhorses of classes. You might think then that the private methods of a class are the ones that need to be tested the most, but the opposite is true.<\/p>\n\n\n\n Private methods cannot be implemented by other classes, and the nuggets of functionality they provide are really just in support of their public methods. Therefore, thoroughly testing a class’s public<\/strong> interface essentially tests its private methods as well.<\/p>\n\n\n\n Similarly, as we’ve already learned, public interfaces should not change much. That means that testing of them should also not change very frequently, except when new functionality is added that changes the object’s behavior. For example, our So not only does the proper design of interfaces help us conceptualize our systems better, it also helps cut down on maintenance costs while our tests still give us the same level of confidence they always have.<\/p>\n\n\n\ninterface<\/code> as a programming language construct; right now we’re going to use it in its regular sense. An “interface” is the point in which two entities meet and interact. For example, your kitchen sink’s interface is the hot and cold handles plus the faucet.<\/p>\n\n\n\npublic<\/code> interface of an object needs to be simple, and needs to change as infrequently as possible.<\/p>\n\n\n\nLet’s Do an Example<\/h2>\n\n\n\n
Hero<\/code> that attacks different types of Enemies<\/code>. Let’s start by writing an abstract Enemy<\/code> class:<\/p>\n\n\n\nnamespace PubPriExample2\n{\n public abstract class Enemy\n {\n public string name { get; set; }\n public int hitPoints { get; set; }\n public int strength { get; set; }\n public int defense { get; set; }\n public bool alive { get; set; }\n\n public Enemy(string enemyName, int hp, int str, int def)\n {\n name = enemyName;\n hitPoints = hp;\n strength = str;\n defense = def;\n alive = true;\n }\n\n public abstract void takeDamage(int attackDamage);\n public abstract bool isAlive();\n public abstract void die();\n }\n}<\/code><\/pre>\n\n\n\nalive<\/code> that will be set to false when the hit points fall below zero.<\/p>\n\n\n\ntakeDamage<\/code>, isAlive<\/code>, and die<\/code>. These are methods that every enemy must have because it is the only thing we’ll do with enemies in this game. All enemies will be attacked, will be alive or dead, and do something when they die.<\/p>\n\n\n\nHero<\/code> class. Most of this class will look like it should be extending the Enemy<\/code> class, but we’re not going to do that. If this were to evolve as a full on RPG, Hero<\/code> would probably also evolve into an abstract class used by multiple customizable heroes. For now, this class will just help us interact with the Enemy<\/code> classes.<\/p>\n\n\n\nusing System;\n\nnamespace PubPriExample2\n{\n class Hero\n {\n public string name { get; set; }\n public int hitPoints { get; set; }\n public int strength { get; set; }\n public int defense { get; set; }\n\n public Hero(string heroName, int hp, int str, int def)\n {\n name = heroName;\n hitPoints = hp;\n strength = str;\n defense = def;\n }\n\n public void attack(Enemy enemy)\n {\n Console.WriteLine(name + \" attacks \" + enemy.name);\n enemy.takeDamage(strength);\n }\n }\n\n}<\/code><\/pre>\n\n\n\ntakeDamage<\/code> type methods for this class because to illustrate the points I’m trying to make, they are not necessary. The one thing I do want you to note here is that is that attack<\/code> takes in an Enemy<\/code> object, and uses the enemy’s takeDamage<\/code> method to interact with it. Hence, the takeDamage<\/code> method is Hero<\/code>‘s interface to Enemy<\/code>.<\/p>\n\n\n\nRegularEnemy<\/code>:<\/p>\n\n\n\nusing System;\n\nnamespace PubPriExample2\n{\n class RegularEnemy : Enemy\n {\n public RegularEnemy(string enemyName, int hp, int str, int def) : base(enemyName, hp, str, def)\n {\n }\n\n public override void takeDamage(int heroStrength)\n {\n int damage = calculateDamage(heroStrength);\n hitPoints -= damage;\n Console.WriteLine(name + \" takes \" + damage + \" points of damage\");\n if (isAlive()) die();\n }\n\n public override bool isAlive() => hitPoints > 0;\n\n public override void die()\n {\n alive = false;\n Console.WriteLine(name + \" has died!\");\n }\n\n private int calculateDamage(int attackStrength)\n {\n int damage = attackStrength - defense;\n if (damage > 0)\n {\n return damage;\n }\n else\n {\n return 0;\n }\n }\n\n }\n}\n<\/code><\/pre>\n\n\n\n=><\/em><\/code> syntax is throwing you off, don’t worry, it’s just some C# syntactic sugar. <\/em>public override bool isAlive() => hitPoints > 0;<\/em><\/code> is exactly the same as<\/em><\/p>\n\n\n\npublic override bool isAlive()\n{\n return hitPoints > 0;\n}<\/code><\/pre>\n\n\n\ntakeDamage<\/code>, isAlive<\/code>, and die<\/code>. The one we’re going to pay attention to is the takeDamage<\/code> method because, remember, it is the public interface at this moment.<\/p>\n\n\n\ntakeDamage<\/code>, do we also have calculateDamage<\/code>? Why can’t we put the logic for calculatign the damage in the takeDamage<\/code> method? We could, but this is part of what we’re learning.<\/p>\n\n\n\ntakeDamage<\/code> method’s responsibility is applying damage, not calculating it.<\/p>\n\n\n\ntakeDamage<\/code> is the interface that the Hero<\/code> class is going to use to interact with Enemy<\/code>, so we want it to be relatively uniform across all Enemy<\/code> sub types. We will make other enemies that can also be attacked, but will take damage in different ways. calculateDamage<\/code> is therefore the private method that will do the sub-type-specific operations to figure out how much our hero has damaged the enemy.<\/p>\n\n\n\nEnemy<\/code> class, the ArmoredEnemy<\/code>:<\/p>\n\n\n\nusing System;\n\nnamespace PubPriExample2\n{\n class ArmoredEnemy : Enemy\n {\n public ArmoredEnemy(string enemyName, int hp, int str, int def) : base(enemyName, hp, str, def)\n {\n }\n\n public override void takeDamage(int heroStrength)\n {\n int damage = calculateDamage(heroStrength);\n hitPoints -= damage;\n Console.WriteLine(name + \" takes \" + damage + \" points of damage\");\n if (!isAlive()) die();\n }\n\n public override bool isAlive() => hitPoints < 0;\n\n public override void die()\n {\n alive = false;\n Console.WriteLine(name + \" has died; the armor shatters\");\n }\n\n private int calculateDamage(int attackStrength)\n {\n \/\/ Enemy has 20% change of deflecting the attack\n Random random = new Random();\n int deflect = random.Next(1, 6);\n if (deflect == 1)\n {\n deflectAttack();\n return 0;\n }\n else if ((attackStrength - defense) > 0)\n {\n return (attackStrength - defense);\n }\n else\n {\n return 0;\n }\n }\n\n private void deflectAttack()\n {\n Console.WriteLine(name + \" deflects the attack!\");\n }\n }\n}<\/code><\/pre>\n\n\n\nArmoredEnemy<\/code> takes damage a different way. The enemy’s armor may deflect our hero’s attack, and thus the calculateDamage<\/code> method essentially rolls the dice to find out if the attack was deflected or not.<\/p>\n\n\n\nusing System;\n\nnamespace PubPriExample2\n{\n class Program\n {\n static void Main(string[] args)\n {\n Hero hero = new Hero(\"Erik\", 100, 10, 5);\n RegularEnemy imp = new RegularEnemy(\"Imp\", 50, 3, 2);\n ArmoredEnemy armorImp = new ArmoredEnemy(\"Armor Imp\", 30, 4, 4);\n\n while (imp.alive)\n {\n hero.attack(imp);\n }\n\n while (armorImp.alive)\n {\n hero.attack(armorImp);\n }\n\n Console.ReadLine();\n }\n\n }\n}<\/code><\/pre>\n\n\n\n
Imp takes 8 points of damage
Erik attacks Imp
Imp takes 8 points of damage
Erik attacks Imp
…truncated
Imp takes 8 points of damage
Imp has died!
Erik attacks Armor Imp
Armor Imp deflects the attack!
Armor Imp takes 0 points of damage
… truncated<\/p>
Armor Imp deflects the attack! Armor Imp takes 0 points of damage Erik attacks Armor Imp Armor Imp takes 6 points of damage …truncated
Erik attacks Armor Imp
Armor Imp takes 6 points of damage
Armor Imp has died; the armor shatters<\/p><\/blockquote>\n\n\n\ntakeDamage<\/code> method, but there would also be a private method for implementing the counterattack. The interface for the enemy wouldn’t be any different, the hero can still only attack<\/code>, but the implementation of that interface would be different, which would mean it should be hidden inside a private class of the new sub type.<\/p>\n\n\n\nWhen Things Change<\/h3>\n\n\n\n
RegularEnemy<\/code> class? Just because an enemy isn’t armored doesn’t mean it can’t deflect an attack, right? Right. So we want to add deflection capabilities to RegularEnemy<\/code> but we want these enemies to have a 5% chance of deflecting rather than 20%.<\/p>\n\n\n\nprivate int calculateDamage(int attackStrength)\n {\n \/\/ Enemy has 5% change of deflecting the attack\n Random random = new Random();\n int deflect = random.Next(1, 21);\n if (deflect == 1)\n {\n deflectAttack();\n return 0;\n }\n else if ((attackStrength - defense) > 0)\n {\n return (attackStrength - defense);\n }\n else\n {\n return 0;\n }\n }\n\n private void deflectAttack()\n {\n Console.WriteLine(name + \" deflects the attack!\");\n }<\/code><\/pre>\n\n\n\nInterfaces Representing Roles<\/h2>\n\n\n\n
interface<\/code> huh? Let’s go ahead and do that, but let’s think it through first.<\/p>\n\n\n\nEnemy<\/code> types that unify them? They all have stats and a name. They can also all be attacked, but in the context of a video game is that really a common trait? For example, consider a game like Zelda, where our hero Link can not only attack bad guys with his sword, but also grass and bushes. The grass and bushes don’t need stats like hit points and strength, but they’re still attackable<\/em><\/strong>.<\/p>\n\n\n\nHero<\/code> could chop down with a sword, do we want the tree to extend the Enemy<\/code> abstract class?<\/p>\n\n\n\nIAttackable<\/code> because that’s how you name interfaces in C#, sorry :shrug:<\/p>\n\n\n\nnamespace PubPriExample2\n{\n interface IAttackable\n {\n void takeDamage(int attackDamage);\n bool isAlive();\n void die();\n }\n}<\/code><\/pre>\n\n\n\nEnemy<\/code> abstract class to implement this interface:<\/p>\n\n\n\nnamespace PubPriExample2\n{\n public abstract class Enemy : IAttackable\n {\n \/\/ Truncated<\/code><\/pre>\n\n\n\nattackable<\/code> trees a few months after you finished the last Enemy<\/code> sub type. Will you remember which methods you’ve been using for these objects? In this case, probably yes because it’s such a small project right now, but imagine the project grows to a couple thousand lines of code.<\/p>\n\n\n\nHero<\/code> can cut down. Luckily, they already have this interface and know exactly how similar functionality has been added to the game before. It lets everything that is attackable<\/code> in the game have the same interface.<\/p>\n\n\n\nRegularEnemy<\/code> and ArmoredEnemy<\/code> and how they both extend the Enemy<\/code> class. Any time we look at a class, regardless of its name, if we see that it extends Enemy<\/code>, we know that this is something the player will fight with.<\/p>\n\n\n\nAttackable<\/code> interface, we will know it takes damage from the Hero<\/code>. This example might make this benefit seem inconsequential, but in large systems with business processes less easy to conceptualize, this benefit can go a long way. The programmer’s main job is managing complexity, and things like proper naming and good interface design help us do that.<\/p>\n\n\n\nA Note on Testability<\/h2>\n\n\n\n
ArmoredEnemy<\/code> class implemented two private methods when taking damage. Testing the public takeDamage<\/code> tests both methods satisfactorily. If we added even a third private method to the takeDamage<\/code> method, we may need to change a few expected values here and there in our tests, but ultimately, test maintenance should be very low.<\/p>\n\n\n\nSummary<\/h2>\n\n\n\n