Java 有神奇的变量不好吗？

假设我有一个变量或对象，我想通过测试类从一个类传递到另一个类。假设我有一个测试班，一个厨师班和一个服务员班

在测试类中这样做不好：

chef.makeFood();
waiter.deliverFood(chef.getFood())

同样，我是否应该这样做：

chef.makeFood();
Food f = chef.getFood();
waiter.deliverFood(f);

---

在这个例子上很难一概而论

在这个简单的示例中，chef可能没有理由保留对“makeFood（）”的引用，因此应该直接返回它。（然后可以删除getFood（））

但是还有很多其他的场景，保持一个内部状态是正确的，比如StringBuilder——或者更复杂的“builder”，然后返回结果

调试时，局部变量通常在那里结束。。。。这并不重要

有神奇的变量不好吗

这取决于你所说的“魔法”是什么意思。如果“魔法”对你来说意味着“做了一些难以理解或解释的事情”，那么它是不好的

在测试类中这样做不好：

chef.makeFood();
waiter.deliverFood(chef.getFood())

我看不出该代码本身有任何错误，即使这些类不是在正常（非测试）代码中使用的。（但您没有向我们展示的设计/代码中有一个问题…）

同样，我是否应该这样做：

chef.makeFood();
Food f = chef.getFood();
waiter.deliverFood(f);

可以这样做，也可以不这样做。这取决于您是否认为这会使代码更具可读性。（就个人而言，我不想在这里使用局部变量，但这只是我的观点。）

---

另一方面，我同意@DaveNewton关于“厨师”对象在“makeFood”中持有食物的评论。这当然是违反直觉的，有点“神奇”。。。如果这是一个深思熟虑的设计选择

更简单、更好的设计是：

Food f = chef.makeFood();
waiter.deliverFood(f);

并从

Chef

类中完全删除

getFood（）

方法和关联的状态变量

设计拙劣/造型拙劣的原因有很多：

• 从直观的意义上讲，这意味着厨师对象必须“站在旁边拿着盘子”，直到服务员接过盘子

• 从类建模的角度来看，您有一个状态变量，它对于实现厨师的行为是不必要的

• 从实用编程的角度来看，这意味着：
  • 当你在12个月后看代码时，代码将很难理解，并且

  • Chef API很难在多线程厨房模拟中使用

---

（如果这就是你所说的“魔法变量”，那么它是不好的……见上文。）

这不是魔法变量或任何类似的东西，而是：

chef.makeFood();
waiter.deliverFood(chef.getFood())

第一个需要更少的行数，如果您不需要对新创建的食物对象的引用，可以说可能会更好，但是许多人可能会认为，即使您不需要引用，下面的代码也更具可读性和清晰性：

chef.makeFood();
Food f = chef.getFood();
waiter.deliverFood(f);

---

一般来说，您应该始终尝试使用可读性更强的代码，因为您永远不知道谁将在以后维护这些代码。

没有区别。我不会称之为“神奇变量”。任何一个都足够可读。这是我要遵循的标准。我投票给第一名，因为它看起来不那么笨重，但也许那只是我。从现在起2个月或2年后，哪一个对你未来的自我来说更容易？第二个例子不是一个“神奇变量”，而是一个局部变量什么是“神奇变量”？我更为不安的是，厨师的内部状态似乎保持着食物——这是一种神奇，而且我是反直觉的。@DaveNewton:

chef.makeFood（order）；食物f=厨师长。获取食物（）；侍者。递送食品（f）

。或者负责人一手拿着一堆先进先出的食物，另一手做更多的食物。