swift组件化是不是最终还是绕不开runtime？

[Will-ZJ]

楼主额提供了这种kvc的方式，但还是没绕过runtime，swift是一门静态类型的语言，是否根本不适合runtime来组件化从发展的角度来看，比如楼主通过显示@objc 让vc的属性参与运行时，万一苹果下个版本或者下下个又或者某一个版本优化完后不支持了，这个组件化不是得推倒重来吗？另外这种方式对于组件传递数据的管理并不理想啊，如果两个模块不同的人来开发，大家需要定好哪些属性以及属性具体名字（这点从某种意思上也是耦合，虽然编译层面代码没有耦合），这其实跟tagert-action 的方式大同小异，都是runtime的方式，参数都是NSDictionary的方式打包传递，少不了硬编码和无法通过ide进行参数的校验和提醒，请问您当初设计这种方式的考量是？

[zjinhu]

楼主额提供了这种kvc的方式，但还是没绕过runtime，swift是一门静态类型的语言，是否根本不适合runtime来组件化从发展的角度来看，比如楼主通过显示@objc 让vc的属性参与运行时，万一苹果下个版本或者下下个又或者某一个版本优化完后不支持了，这个组件化不是得推倒重来吗？另外这种方式对于组件传递数据的管理并不理想啊，如果两个模块不同的人来开发，大家需要定好哪些属性以及属性具体名字（这点从某种意思上也是耦合，虽然编译层面代码没有耦合），这其实跟tagert-action 的方式大同小异，都是runtime的方式，参数都是NSDictionary的方式打包传递，少不了硬编码和无法通过ide进行参数的校验和提醒，请问您当初设计这种方式的考量是？

1. 目前已经尽量最少的使用runtime了，只有反射类以及反射方法必须要用，目前没有更加swifty的方式。

2. @objc标记是为了KVC赋值。

3. runtime只要还有OC存在iOS系统就得集成，只不过系统版本不同可能集成的runtime版本不同罢了。

4.你说的这个多个人员的问题。用别人写的库不需要看人家写的接口入口么？这个仓库算是tagert-action，如果是协议方式的话那代码量更多，每处都要写协议啊，不照样也得关心各种属性方法名么。tagert-action 和 protocol的区别就是一个字符串反射一个处处留协议，各有千秋吧。

5.参数传递的问题，的确没有提醒，你有更好的办法没？

[Will-ZJ]

@jackiehu 我目前刚刚接触这个组件化，到处取经，没有好的方法，看了很多博客上关于组件化的认知，基本上都是纵向分不同的层次，横向分不同的组件，rooter或者mediator基本都是服务于横向解耦（业务层跳转），不同层级之间基本都是上层引用下层的单向依赖方式，比如业务层组件对网络层组件的依赖，不知道我这个观点对不对，请指教

[zjinhu]

@jackiehu 我目前刚刚接触这个组件化，到处取经，没有好的方法，看了很多博客上关于组件化的认知，基本上都是纵向分不同的层次，横向分不同的组件，rooter或者mediator基本都是服务于横向解耦（业务层跳转），不同层级之间基本都是上层引用下层的单向依赖方式，比如业务层组件对网络层组件的依赖，不知道我这个观点对不对，请指教

对，就是这样，业务组件可以向下依赖基础层工具层组件，不同业务层组件解耦后调度传参通过路由中间件，定义好组件入口协议

[Will-ZJ]

@jackiehu 谢老哥，一开始我误以为是都通过中间件做依赖解除，看了很多博客啥的发现不是这样，理想的情况是谁也不依赖谁，实际情况是通过单向依赖+中间件来实现组件之间解耦，有个问题是如果多个组件都要依赖同一个第三方，podfile怎么设计才能更优或者说podSpec，有没有啥良方？

[zjinhu]

@jackiehu 谢老哥，一开始我误以为是都通过中间件做依赖解除，看了很多博客啥的发现不是这样，理想的情况是谁也不依赖谁，实际情况是通过单向依赖+中间件来实现组件之间解耦，有个问题是如果多个组件都要依赖同一个第三方，podfile怎么设计才能更优或者说podSpec，有没有啥良方？

一般情况下的第三方开源库都可以直接依赖，多层依赖多向都可以，除非是微信，百度地图这种静态库，只能单向单层依赖

[Will-ZJ]

@jackiehu 多谢