处理iOS游戏和应用程序中的分层破坏效应

大约一年半前，我开始作为一名iOS开发人员工作，我在软件架构和组织方面遇到了一些问题。我使用苹果公司推荐的模型视图控制器范例，我的代码通常是非常分层的：如果屏幕（例如）有一个HUD、一个控制面板和一个显示区域，我有一个用于屏幕的主控制器和用于HUD、控制面板和显示区域的子控制器。子控制器通常不知道其相邻控制器，并使用主控制器中的方法与它们交互

然而，特别是在游戏中，我经常遇到打破等级的问题，这些问题无法用这个模型优雅地解决。例如，假设我在控制面板区域中有一枚硬币，我想为飞行到HUD设置动画。我可以将原始硬币设置为新位置的动画，这需要像animateCointPosition这样的方法：在控制面板子控制器中，以及像GetPositionForFinalInputPositionHUD这样的方法在主控制器中；或者，我可以隐藏原始硬币并在主控制器或HUD控制器中创建一个复制硬币，这将需要一个委托方法，如animateContoHudFromStartingPosition:。我不喜欢在我的控制器中有这种奇怪的特定方法，因为它们的存在只是为了解决一个问题，而且还公开了层次结构。我的理想解决方案是使用一个名为animateCoinToHUD的方法，但这需要将整个层次结构展平，并将三个控制器合并为一个，这显然是不值得的。（或者让子控制器访问它们的兄弟控制器——但这基本上具有相同的效果。子控制器将彼此具有依赖性，从而创建一个凌乱的蜘蛛网控制器，而不是一个主控制器和三个主要独立的子控制器。）

而且情况往往变得更糟。如果我想在移动硬币时显示全屏动画或粒子效果，该怎么办？如果我的硬币比一个简单的精灵复杂得多，有很多子视图和细节，以至于使用animateContoHudFromStartingPosition:创建一个复制硬币效率低下，该怎么办？如果硬币飞到HUD，然后又回到控制面板，该怎么办？我是否将币形视图“借给”主控制器，然后在动画完成后将其取回，并在临时变量中保留原始位置/z顺序/等，以便可以恢复它们？还有一件事：从逻辑上讲，涉及多个子控制器的代码属于主控制器，但如果这些交互是常见的，那么主控制器将增长到数千行——我在许多项目中都看到过这种情况，而不仅仅是我自己的项目

---

是否有一种一致的方法来处理这些破坏层次结构的效果和操作，这些效果和操作不需要重复的代码或资产，不需要膨胀我的控制器，并且允许我在子控制器之间优雅地共享对象？还是我使用了完全错误的方法？

所以，我想你可能认为“永远不要向上”的层次结构有点过于字面化了

我认为这个想法是，你不知道具体的父对象是什么，但是你可以定义一个协议，并且知道无论你的父对象是什么，它都会响应所说的协议。理想情况下，您可以在代码中进行测试，以确认它是否响应该协议。然后使用协议以通用方式发送消息，将硬币对象传递给父对象，并让父对象在屏幕外和HUD中设置动画

子控制器然后有一个

id父控制器实例变量及其初始化方法将其中一个作为参数。根据您的描述，您已经准备好了类似的东西，或者至少足够实现您所说的“子控制器通常不知道其相邻的控制器，并且使用主控制器中的方法与它们交互”

因此，从设计的角度来看，硬币拾取发生在显示面板中，它所知道的是它的父对象有一个
pickupCoin:
方法，可以对拾取的硬币执行任何适当的操作。显示面板不知道它会进入HUD或其他什么，只知道拾取的硬币会被父控制器的
pickupCoin:
方法处理

这里的OOP设计理念是，父级的所有知识都封装在协议定义中。这使得子级和父级的耦合更加松散，因此您可以在实现该协议的任何父级中进行交换，子级仍然可以正常工作

您可以使用更松散的耦合（全球发布的通知说），但在您描述的情况下，我认为类似于我概述的东西可能更合适&可能更有效

这有帮助吗？
这就是为什么我们需要一个白板：）在过去几天里，我已经把你的问题读了好几遍，但实际上没有掌握一些东西。特别是您的“根”视图控制器在所有这一切中扮演什么角色？听起来你也在试图让它不了解层次结构，还是我错了？不——根据苹果的指导方针，父控制器可以直接访问其所有子控制器，但反之亦然。子控制器通常通过委托了解其父控制器，委托提供了父控制器必须实现的少量方法。子控制器只能通过父控制器与其同级控制器交互。