Question
Answer and Explanation
The assertion that Getters and Setters are "evil" is a provocative statement, but it highlights potential pitfalls in object-oriented programming. It's more accurate to say that overuse or misuse of Getters and Setters can lead to problems.
Here's why they sometimes get a bad reputation:
1. Breaking Encapsulation:
- The primary purpose of encapsulation is to hide the internal state of an object and expose controlled access through methods. If you simply provide Getters and Setters for every field, you're effectively making the fields public, defeating the purpose of encapsulation. This exposes the internal representation of your object, which can make it harder to change the implementation later without breaking dependent code.
2. Anemic Domain Model:
- An Anemic Domain Model is a design pattern where domain objects are essentially data holders with little or no behavior. The logic resides in separate service classes, often leading to a procedural-style code structure rather than a truly object-oriented one. Over-reliance on Getters and Setters often contributes to this pattern.
3. Hiding Side Effects:
- Getters and Setters suggest simple access or modification of a field. However, they can hide more complex logic or side effects. If a Getter or Setter performs non-obvious operations, it can make the code harder to understand and debug. The Principle of Least Astonishment suggests that code should behave in a way that is predictable and expected.
4. Increased Coupling:
- Excessive use of Getters and Setters can increase coupling between classes. When one object directly accesses the internal state of another through Getters and Setters, it becomes dependent on that specific structure. If the internal structure changes, the dependent object also needs to be modified.
5. Violation of "Tell, Don't Ask":
- The "Tell, Don't Ask" principle encourages objects to tell other objects what to do rather than asking them for their internal state and then making decisions based on that state. Using Getters to retrieve data and then performing logic outside the object violates this principle. It's often better to move the logic into the object itself.
6. Example (JavaScript):
class Person {
constructor(name, age) {
this._name = name;
this._age = age;
}
get name() {
return this._name;
}
set name(newName) {
this._name = newName;
}
celebrateBirthday() {
this._age++;
console.log(`Happy Birthday! ${this._name} is now ${this._age} years old.`);
}
}
let person = new Person("Alice", 30);
person.celebrateBirthday(); // Good: The Person object handles its own age.
// Less ideal:
// console.log(person.name); //Accessing the attribute directly would be worse, but still, consider if we need this.
When are Getters and Setters Appropriate?
- They can be useful when you need to control access to a field, perform validation, or trigger side effects. For example, a Setter might validate the input before assigning it to the field, or it might update a cache. You might also use Getters and Setters when interacting with certain frameworks or libraries that expect them.
Alternatives to Getters and Setters:
- Command Query Responsibility Segregation (CQRS): Separate read and write operations into different interfaces. - Immutable Objects: Create objects whose state cannot be modified after creation. - Value Objects: Represent simple values (like dates, currency) with their own behavior. - Behavior-Rich Objects: Encapsulate data and behavior tightly within objects.
In Summary, Getters and Setters are not inherently evil, but their overuse can lead to code that is less object-oriented, harder to maintain, and more prone to errors. Consider alternatives that promote better encapsulation and more behavior-rich objects to create more robust and maintainable systems. Always ask yourself: "Is accessing this data directly really necessary, or should this object be doing something with it instead?"