In software development, repeating similar code across multiple classes can lead to significant issues. Consider a game that has multiple character types, such as Player, Monster, and NPC,each requiring common attributes like health and methods like takeDamage(). Without applying any reuse principles, your code might look like this:
public class Player {
private int health;
public void takeDamage(int amount) {
health -= amount;
}
}
public class Monster {
private int health;
public void takeDamage(int amount) {
health -= amount;
}
}
public class NPC {
private int health;
public void takeDamage(int amount) {
health -= amount;
}
}
Notice how the takeDamage() method and health field are identical in each class. Duplicating code this way is risky because:
The DRY principle (Don’t Repeat Yourself) advises avoiding this duplication by identifying and abstracting common behaviors into a single, shared implementation.
// Parent class with shared functionality
public class GameEntity {
protected int health;
public void takeDamage(int amount) {
health -= amount;
}
}
// Subclasses inherit common behavior and add specifics
public class Player extends GameEntity {
private int experiencePoints;
public void gainExperience(int amount) {
experiencePoints += amount;
}
}
public class Monster extends GameEntity {
private boolean isAggressive;
public void setAggressive(boolean aggressive) {
isAggressive = aggressive;
}
}
Note8.2.1.
While these examples show identical code duplication, inheritance is most appropriate when the duplicated elements represent a genuine specialization relationship. When shared behavior might evolve differently across classes or when the "is-a" relationship doesn’t hold, consider alternatives like interfaces or composition.
For example, while a Monster genuinely is a GameEntity, a Game is not a Player it contains or manages players. Consider this example of inappropriate inheritance:
// Inappropriate inheritance example
public class Game extends Player {
private List<Monster> monsters;
// Game methods...
}
This design is problematic because a Game is not a specialized type of Player, yet it would inherit player-specific attributes like health and experience that don’t make sense for a game. Additionally, changes to the Player class would unexpectedly affect the Game class. A better approach would use composition: Game would contain instances of Player, Monster, and other game elements.
