替代OOP中的C风格结构

我是一名主要进行程序设计的电子背景的学生。我越了解它，我越发现自己有多糟糕。我想在OO设计上变得更好。我一直在阅读的一件事是使用Getters和Setters。替代OOP中的C风格结构

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

现在我可以看到这一点，他们正在这里，但我仍然无法看到走周围的一些简单的问题。这使我想起了我的问题（最后）。我正在AS3中设置一个简单的塔防游戏作为学习练习。我希望敌人遵循方向点，所以我要制作一系列方向点，并使之成为地图对象的属性。一个方法是成为一个具有x和y属性的对象（更像是一个结构体）。现在我可以看到，这正是这些文章令人沮丧的坏习惯，但我似乎无法想到一个更好的方法来做到这一点。任何一些有更多经验的人的帮助将非常感谢。

来源

2010-02-28 Dan Walmsley

我不知道AS3的第一件事，而是一个智者曾经告诉我，打破习惯几乎是不可能的，而是一个应该简单地试图获得一个新的习惯代替它。 – Ken 2010-02-28 05:05:50

是的，这是我的目标，我只是需要一些指向正确的方向来获得这些良好的习惯。 – 2010-02-28 05:30:18

我建议你编辑你的问题标题更具体。你想知道如何在OOP中使用结构，而不是关于打破习惯的一般建议。 – Stiggler 2010-02-28 19:21:41

首先推广;虽然你现在想要敌人跟随航点，但在我看来，你所拥有的是地图的特定实例，以确定某物在哪里移动。

让我们称敌人为“GameEntity”（可能为MoveableGameEntity）的一个实例。

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

代码片段。

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），这将决定新posisiton和敌人也只能通过positionNotify方法被告知他们的新posistion。

MoveableGameEntityList是一个将游戏实体和它的位置绑定在一起的对象。这种方式游戏实体不包含任何位置信息，这是由另一个对象管理。

来源

2010-02-28 12:44:49

我不希望看到这是坏习惯与好习惯，而是范式的转变。不幸的是，这并不像翻转开关那么简单。随着你以不同的方式看待事物的经验越来越丰富，这种情况就会逐渐发生。

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

来源

2010-02-28 05:48:37 polygenelubricants

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

试着将你的“对象”看作与对方交流的有形物品。该通信是一种协议（包括方法签名）。你相互“说话”的语言。简单明了。永远不要假定任何物体都有能力操纵另一个物体超出其传达建议或请求（封装）的能力。

不要仅仅将getter和setter添加到没有目的的所有东西。你会错过整个观点，而且可能会以另一种风格进行编码。保护内部状态。 Getters &安装人员一切只是意味着，你将会普遍效率低下。安装者&获得者是守门员。而已。消除他们，如果他们没有意义。在他们所在的地方使用它们永远不要让别的东西与你的内部状态一起拧。它会造成混乱。

写作游戏时，这些做法会下降，但不会被放弃。优化您的关键环路&阻塞点。保留您的原始代码&作为优化代码的镜像模型。拿走你需要的快捷键，仅此而已。即使面对明显效率低下，但考虑周全的设计，优化也总是会持续下去。

许多我曾经使用过的前Java代码编写器不必要地将属性设置为&属性（每个属性）。这只是他们习惯的。在10个案例中有9个没有好处，但他们坚持这种模式。影响总是微不足道（每分钟5万用户...当然，不使用Java ......但仍然）。在高层次设计中，getter & setter的总体影响是最小的。较低的水平，如在视频编解码器或OpenGL，它是巨大的。

您可以选择无需思考就采用它们，或者在考虑适用性的情况下实施它们。你将找到许多教授告诉你，你是“错”，因为你省略了他们。记住你的课程期望。 :)

来源

2010-02-28 06:52:18 pestilence669

感谢您的建议，它确实清楚了一些事情。但是在我的例子中，是否有更好的方法来创建点对象的方式，使其不仅仅是两个基元的持有者还是这是一个可接受的设计？ – 2010-02-28 08:35:51

这是可以接受的（在很多圈子里都适用）。每当我使用简单的坐标时，我有时只使用内置数组（使用元组的坏习惯）。如果有意义的话，你可以将智力放入你的点对象中，但我不会建议你强制它。 – pestilence669 2010-02-28 21:40:33

有点无关，但如果你想进入OO设计，我有2个好书给你，容易理解&把握。

Head First: OOAD

Head First: Design Patterns

来源

2010-02-28 12:49:31 Jens