strangeIOC 实践指南

大概从两三个月前, 在公司的项目和自己的练手项目中, 进行 strangeIOC 的实践。

最初的想法是写出更不耦合的代码,在代码量上升的时候,能进行更方便的添加或者修改功能, 即使是大的更改, 比如游戏核心玩法不变(例如一个三消游戏), 再给它外面添加一个模拟经营的外壳或者PRG的外壳变的容易。

两三个月的真实的实践, 对于 strangeIOC 这个框架悲喜参半, 不过已经很容易的知道各种什么注入错误是什么了。 这篇文章, 主要聊聊我实践过程中觉得它的优点和缺点。

先说缺点,

  1. 上手不是很容易, 并且容易纠结, 特别是你手上有一个几天就实现的 demo 的版本的时候, 当把它迁入到 strangeIOC 框架的时候, 你发现会花点比你之前做 demo 多的多的时间。
  2. 如果你想在 Editor 里面事实看到 model 的数据的情况, model 层必须继承于 Monobehavoir, 但是 MonoBehavior 对单元测试 支持的不是很友好, 意味着你的 model 是继承 Monobehavior 还是 System.Object 都要纠结半天。
  3. 其实作者对于 strangeIOC 还有很多想法, 即添加一些更完善的功能(例如动态绑定?), 但是作者目前已经不专注这一块了, 社区里面也没有人承担起这份工作。
  4. 会多出来很多代码, 要不然定义一堆大同小异的信号来触发, 要不然定义一堆回调, 甚至回调里面调用回调。

然后是优点:

  1. 之前纠结 strangeIOC 是否能真的实现减轻代码负担的作用, 现在看起来 view 层变的友好了, 项目之间不会耦合; 甚至之前的各种协程弄出来的空指针, 它也能有效的避免。 但是 model 层还是很容易的去在原来的函数上添加和修改, 原来打算加入更多的接口之类的让 model 层变的更轻, 但是 model 还是很容易就变成 1k多行。
  2. strangeIOC 会让你知道下一步该干什么, 里面上测试覆盖所有的接口, 这套游戏代码就不是很容易出bug。
  3. 很方便的迁移,即核心逻辑不变, 可以很容易的更改 view 层的表现方式, 并且你知道它不会对你的代码产生灾难性的后果。
  4. 如果什么地方有问题, 顺着信号往下面找就好了, 问题比较容易定位。

总结:

之后还会继续实践, 但是也会偶尔切换到传统的方式上面去。 毕竟最重要的是把游戏做出来对吧。

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s