oop - OOP 组织问题的最佳解决方案

Question

我有一个关于特定 OOP 问题的组织的简单问题。

假设我有一个地形类，里面充满了瓷砖。 Tile 类有多个派生类，即 Door。 Door 类有一个名为 open() 的方法，用于打开门，还有一个名为 close() 的方法，用于关闭门。这是非常有意义的，直到这两种方法都需要在打开和/或关闭之前检查某些内容。如何在门不知道其父对象的情况下检查对象？

一个简单的解决方案是在调用 open() 之前检查路上是否有东西，但如果需要检查不同形状的不同类型的门，则会在更高级别上造成困惑。

这似乎有一个简单的答案，但我似乎也经常遇到这个问题。

Answer 1

一个答案是，门应该知道如何自行打开和关闭，并知道它们是否被阻挡。如果 Door 是一个类，则状态(is_open、is_blocked)和行为(open_the_door、close_the_door ) 应该驻留在 Door 类中。封装是面向对象范式的基本原则。

但现实世界的答案通常更加微妙。您能否提供一些有关该应用程序的背景及其需要完成的任务？有一些干净、简单的解决方案非常适合玩具应用程序，但更大的应用程序将需要更复杂的东西。

如何处理门is_blocked存在一些设计问题。没有一种正确的设计，但有好的设计和坏的设计。将好想法与坏想法区分开来不仅仅取决于设计原则，还取决于问题的背景。

如果我必须猜测的话，我猜您的应用程序是一个游戏。也许图 block 代表游戏板或 map 的区域。您已经发现许多不同的对象可能必须进行交互，如果它们都直接相互引用，那将会很困惑。

• 游戏通常有一个称为“游戏”或“棋盘”或“ map ”的主对象。让主对象保存 Tile 层次结构中的事物集合(瓷砖、门等)。

• 让主对象还包含可以阻挡门或以其他方式与瓷砖和门交互的事物的集合。

• 现在在 Tile 类上创建一个名为 update() 的方法，该方法接受一个对象作为参数。

• 并为 Door 类创建一个名为“blocked”的 bool 属性。Door 的更新方法可能会执行如下操作:

  Door::update(BlockingObject object) {
   if(object.location == this.location)
        blocked = true 
   }

• door 父类(super class)上的方法可能不执行任何操作。像这样:

  Tile::update(BlockingObject obj) {
       //tiles cannot be blocked
  }

• 现在，在游戏循环内，包括一个将所有门设置为 blocked = false 的步骤。

• 创建一些循环会要求所有图 block 检查它们是否被阻止。它在伪代码中可能看起来像这样:

  For each tile {
       For each blocking object {
            tile.update(object)
       }
  }

• 这是一个朴素但直接的设计，符合 OO 范式。

• 该设计使图 block /门和物体有机会每回合交互一次，而不强制它们相互引用。

• 该设计对于几百个图 block 和对象来说效果很好，但对于数千个图 block 来说它会变得非常慢。

这个设计好吗？

答案取决于应用程序的需求。