OOP 中 C 风格结构的替换

Question

我是一名主要从事编程电子背景的学生。我越深入，我就越意识到我在这方面有多糟糕。 我正在努力提高面向对象设计的水平。 我读到的一件事是 Getters 和 Setters 的使用。

http://www.javaworld。 com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1 http://tropicalprogrammer.com/?p=23

现在我可以明白他们的观点了在这里，但我仍然无法解决一些简单的问题。这引出了我的问题（最后）。我正在 AS3 中设置一个简单的塔防游戏作为学习练习。我希望敌人遵循路径点，因此我将创建一个路径点数组，并将其作为地图对象的属性。一个路径点是一个具有 x 和 ay 属性的对象（更像是一个结构体）。现在我发现这正是文章所劝阻的不良做法，但我似乎想不出更好的方法来做到这一点。任何有更多经验的人的帮助将不胜感激。

Answer 1

首先概括；虽然你目前希望敌人遵循路径点，但在我看来，你所拥有的是地图的特定实例，决定物体移动的位置。

我们将敌人称为“GameEntity”的实例（可能是 MoveableGameEntity）。

您应该做的是告诉地图管理相关的游戏实体，然后地图可以保留这些对象的列表并根据需要移动它们。

代码片段。

interface  MoveableGameEntity
{
    void positionNotify(Position new_postition);
};

public class Barbarian implements MoveableGameEntity
{
    void positionNotify(Position new_postition)
    {
         // do something
    }
};

// during initialisation.
map.Add(new Enemy("Barbarian 1"));
map.Add(new Enemy("Barbarian 2"));

//during map processing
Position new_position = new Position();
for (MoveableGameEntityList moveable : moveable_game_entity_items)
{
   new_position = get_new_posistion(moveable);
   item.moveTo(new_position);
   moveable.positionNotify( new_position );
}

地图需要有一个方法 get_new_position(MoveableGameEntity ge) 来确定新的位置，并且敌人只会通过positionNotify 方法得知他们的新位置。

MoveableGameEntityList 是一个将游戏实体及其位置联系在一起的对象。这样游戏实体不包含任何位置信息，并且由另一个对象管理。

Answer 2

好吧，接下来是沉重的假设：我认为你对效率的考虑太多了。 OO 编码与效率无关。这是关于优雅的设计。这是为了最大限度地减少外部因素的副作用并保护内部状态。这就是编译器“优化”的原因。您应该主要考虑编码的可维护性和难度。您编写的行数很可能比非 OO 代码多。这不是重点。

尝试将您的“对象”视为可以相互交流的有形物品。此通信是一个协议（包括方法签名）。你们彼此“交谈”的语言。使其简单且明确。永远不要假设任何对象都有能力操纵另一个对象，超出其传达建议或请求（封装）的能力。

不要毫无目的地向所有内容添加 getter 和 setter。你会错过整个要点，并且可能会以另一种风格进行编码。保护内部状态。吸气剂和吸气剂一切上的设置器仅仅意味着，您将获得普遍低效的实现。设置器和设置器吸气剂是看门人。而已。如果它们没有意义，就消除它们。在该做的地方使用它们。永远不要让其他事情扰乱你的内心状态。它会制造混乱。

当编写游戏时，这些做法会失败，但它们不能被放弃。优化您的关键循环和瓶颈。保留您的原始代码以供参考和使用作为优化代码的镜像模型。采取您需要的捷径，仅此而已。优化必须始终放在最后......即使面对明显低效但经过深思熟虑的设计。

我曾与许多前 Java 程序员一起工作过 put setter 和 put setter。不必要地对属性（每个属性）进行 getters。这只是他们的习惯。十个案例中有九个没有获益，但他们坚持这种模式。影响始终可以忽略不计（每分钟 5 万用户……当然，不使用 Java……但仍然如此）。 getter 和 getter 的总影响setter 在高级设计中是最少的。较低级别，如视频编解码器或 OpenGL，它巨大。

您可以选择不假思索地采用它们，或者考虑到适用性来实施它们。你会发现许多教授告诉你你“错了”，因为你忽略了他们。牢记您对课程作业的期望。 :)

Answer 3

我不希望将其视为坏习惯与好习惯，而是范式的转变。不幸的是，这并不像按下开关那么简单。当你对看待事物的不同方式越来越有经验时，这种情况就会逐渐发生。

我能给你的最好建议就是开始编码。很多。

Answer 4

有点不相关，但如果你想进入 OO 设计，我有 2 本书给你，易于理解且易于理解。抓牢。

Head First：OOAD

首先：设计模式