处理iOS游戏和应用程序中的层次结构破坏效果

大约一年半前我开始作为iOS开发人员工作,我在软件架构和组织方面遇到了一些麻烦.我使用Apple推荐的模型 – 视图 – 控制器范例,我的代码通常是非常分层的：如果屏幕有(例如)HUD,控制面板和显示区域,我有一个主控制器用于屏幕和子用于HUD,控制面板和显示区域的控制器.子控制器通常不知道它们的相邻控制器并且使用主控制器中的方法来与它们交互.

但是,特别是在游戏中,我经常会遇到层次结构破坏的问题,这些问题无法用这个模型优雅地解决.例如,假设我在控制面板区域有一枚硬币,我想要动画飞到HUD.我可以将原始硬币设置为新位置,这需要像animateCoinToPosition这样的方法：在控制面板子控制器中,以及主控制器中的getPositionForFinalCoinPositionInHUD方法;或者,我可以隐藏原始硬币并在主控制器或HUD控制器中创建一个复制硬币,这需要一个委托方法,如animateCoinToHUDFromStartingPosition：.我不喜欢在我的控制器中使用这些奇怪的特定方法,因为它们只存在以解决一个问题,并且另外暴露层次结构.我理想的解决方案是使用一个名为animateCoinToHUD的方法,但这需要展平整个层次结构并将三个控制器合并为一个,这显然是不值得的. (或者让子控制器访问他们的兄弟姐妹 – 但这基本上会产生相同的效果.子控制器会相互依赖,创建一个凌乱的蜘蛛网控制器而不是主控制器,三个主要是独立的子控制器控制器).

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

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

解决方法

所以,我认为你可能会想到“从不上升”这个层次结构.

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

然后,子控制器具有id< parent_protocol>父母;实例变量及其初始化方法将其中一个作为参数.根据你的描述,你已经有了这样的东西,或者至少足以实现“子控制器通常不知道他们的相邻控制器并使用主控制器中的方法与它们进行交互”如你所说.

因此,从设计的角度来看,这个想法是硬币拾取发生在显示面板中,它所知道的是它的父对象有一个pickupCoin：方法,它将做任何适合拾取的硬币.显示面板不知道它进入HUD,或者其他什么,只是拾取的硬币由父控制器的pickupCoin：方法处理.

这里的OOP设计理念是父语言的所有知识都封装在协议定义中.这使得儿童和儿童父级更松散耦合,以便您可以交换任何实现该协议的父级,孩子们仍然可以正常工作.

你可以使用更宽松的耦合(全球发布的通知说),但在你描述的情况下,我认为我所概述的东西可能更合适&可能性能更高.

这有帮助吗？