吸气剂和定型剂设计不佳吗？ 看到矛盾的建议

 

这个问题在这里已经有了答案：

  • 为什么使用getter和setter / accessors？ [已完成] 38个答案

    • 还有一种观点认为，大多数时候，使用setter仍然允许你设置无意义的值来打破封装。 作为一个非常明显的例子，如果你的游戏中只有一个分数计数器，而不是 

    // Game
private int score;
public void setScore(int score) { this.score = score; }
public int getScore() { return score; }
// Usage
game.setScore(game.getScore() + ENEMY_DESTROYED_SCORE);

    它应该是 

    // Game
private int score;
public int getScore() { return score; }
public void addScore(int delta) { score += delta; }
// Usage
game.addScore(ENEMY_DESTROYED_SCORE);

    这可能是一个简单的例子。 我想说的是，讨论getter / setters与公共领域往往会掩盖更大的问题，即物体以亲密的方式操纵彼此的内部状态，因此过于紧密地耦合。

    这个想法是让方法直接做你想做的事情。 一个例子就是如何设置敌人的“活着”状态。 你可能想要有一个setAlive（boolean alive）方法。 相反，你应该有： 

    private boolean alive = true;
public boolean isAlive() { return alive; }
public void kill() { alive = false; }

    原因是如果你改变了实现不再有“活着”布尔值而是“生命值”的值，你可以改变这种情况而不会破坏你之前编写的两种方法的契约： 

    private int hp; // Set in constructor.
public boolean isAlive() { return hp > 0; } // Same method signature.
public void kill() { hp = 0; } // Same method signature.
public void damage(int damage) { hp -= damage; }
  • 非常邪恶：公共领域。
  • 有些不好：吸气剂和吸附剂不需要的地方。
  • 好：Getters和setter只在真正需要的地方 - 使类型暴露出使用其状态的“更大”行为，而不仅仅将类型视为由其他类型操作的状态存储库。

    • 这真的取决于情况 - 有时你真的只是想要一个愚蠢的数据对象。

    你已经有了很多很好的答案，所以我只给我两分钱。 吸气剂和吸附剂是非常非常邪恶的。 他们基本上让你假装隐藏你的对象的内部，当你所做的大部分时间都被抛弃在冗余代码中，这些代码不会隐藏内部状态。 对于一个简单的POJO，没有理由不能用obj.name =“Tom”替换getName（）和setName（）。

    如果方法调用仅仅取代赋值，那么通过首选方法调用获得的所有内容都是代码膨胀。 不幸的是，该语言已经在JavaBeans规范中规定了使用getter和setter，所以Java程序员被迫使用它们，即使这样做没有任何意义。

    幸运的是，Eclipse（以及其他可能的IDE）可以让你自动生成它们。 对于一个有趣的项目，我曾经在XSLT中为它们构建了一个代码生成器。 但是如果我在Java中摆脱了一件事情，那就是过分依赖getter和setter。

    链接地址: http://www.djcxy.com/p/53943.html

    上一篇: Are getters and setters poor design? Contradictory advice seen

    下一篇: Inheritance vs. Aggregation