getter 和 setter 是糟糕的设计吗?看到了矛盾的建议 [英] Are getters and setters poor design? Contradictory advice seen

查看:27
本文介绍了getter 和 setter 是糟糕的设计吗?看到了矛盾的建议的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在开发一款具有多种不同模式的 Java 简单游戏.我扩展了一个主要的 Game 类,将主要逻辑放在其他类中.尽管如此,主要的游戏类仍然相当庞大.

I'm currently working on a simple game in Java with several different modes. I've extended a main Game class to put the main logic within the other classes. Despite this, the main game class is still pretty hefty.

快速浏览我的代码后,与游戏逻辑真正需要的其余部分相比,其中大部分是 Getter 和 Setter (60%).

After taking a quick look at my code the majority of it was Getters and Setters (60%) compared to the rest that is truly needed for the logic of the game.

一些 Google 搜索声称 Getter 和 Setter 是邪恶的,而其他人则声称它们对于良好的面向对象实践和出色的程序是必不可少的.

A couple of Google searches have claimed that Getters and Setters are evil, whilst others have claimed that they are necessary for good OO practice and great programs.

那我该怎么办?应该是哪个?我应该为我的私有变量更改我的 Getter 和 Setter,还是应该坚持使用它们?

So what should I do? Which should it be? Should I be changing my Getters and Setters for my private variables, or should I stick with them?

推荐答案

还有一种观点认为,在大多数情况下,使用 setter 仍然会破坏封装,因为它允许您设置无意义的值.举一个非常明显的例子,如果你在游戏中有一个只会上升的分数计数器,而不是

There is also the point of view that most of the time, using setters still breaks encapsulation by allowing you to set values that are meaningless. As a very obvious example, if you have a score counter on the game that only ever goes up, instead of

// 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/setter 与公共字段通常会掩盖更大的问题,即对象以亲密的方式操纵彼此的内部状态,因此耦合过于紧密.

This is perhaps a bit of a facile example. What I'm trying to say is that discussing getter/setters vs public fields often obscures bigger problems with objects manipulating each others' internal state in an intimate manner and hence being too closely coupled.

这个想法是让方法可以直接做你想做的事情.一个例子是如何设置敌人的活着"状态.您可能想拥有一个 setAlive(boolean alive) 方法.相反,您应该:

The idea is to make methods that directly do things you want to do. An example would be how to set enemies' "alive" status. You might be tempted to have a setAlive(boolean alive) method. Instead you should have:

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

这样做的原因是,如果您更改实现,即事物不再具有活动"布尔值而是命中点"值,则可以在不破坏之前编写的两种方法的约定的情况下进行更改:

The reason for this is that if you change the implementation that things no longer have an "alive" boolean but rather a "hit points" value, you can change that around without breaking the contract of the two methods you wrote earlier:

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; }

这篇关于getter 和 setter 是糟糕的设计吗?看到了矛盾的建议的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆