2019-03-19我现在做的项目就很好的做了模块化设计，将一些常用功能抽出构建成了单独模块banner（横幅广告）、network（网络连接）、window（界面相关）、validator（响应式校验），还有一个通用基础模块，封装了一些常用工具和MVP系统架构。MVP架构和泛型一起使用，好的不要不要，哈哈哈。最厉害的是，我们的封装模块Android端和iOS端类、接口、方法一模一样，文档注释非常清晰，方便两端开发者沟通交流，更方便快速定位错误，只要一端出了问题，另一端可以快速检查测试，查找是否错误重现。 2 70
2019-03-20SOLID 原则全称：
1. Single responsibility principle
2. Open–closed principle
3. Liskov substitution principle
4. Interface segregation principle
5. Dependency inversion principle展开 18
2019-03-27对于架构我感觉这几篇很有营养
https://casatwy.com/iosying-yong-jia-gou-tan-kai-pian.html
iOS应用架构谈 开篇
iOS应用架构谈 view层的组织和调用方案
iOS应用架构谈 网络层设计方案
iOS应用架构谈 本地持久化方案及动态部署
iOS应用架构谈 组件化方案展开 13
2019-03-19老师，这里面讲到了架构方面的知识，有什么入门的资料可以推荐一下吗作者回复: 入门我推荐阮一峰老师的《软件架构入门》http://www.ruanyifeng.com/blog/2016/09/software-architecture.html
11
2019-03-21希望能在每篇文章的最后推荐一些相关的资料阅读，这样能更好地帮助理解内容 8
2019-03-19协议化的方式有两个好处，一是可以明确知道组件提供了哪些服务，二是组件一旦修改了接口会立刻引发编译错误，而CTMediator会推迟到运行时。作者回复: 是的，CTMediator会在运行时进行管控。其实在中间者那一层加上记录，还能够进行运行时代码覆盖率统计
8
2019-03-19组件化架构的目的主要是解耦各个具体业务模块的耦合，而在业务模块的内部也还是需要用到像MVC、MVP、MVVM这些设计模式。 大神，我的理解是没错吧作者回复: 是的
7
2019-03-19CT的扩展值得一试 7
2019-03-20大家好，我先说下我的疑问：
关于组件化的实现方案有协议或者中间人两种：
1.协议解耦：Runtime+Protocol
2.中间人解耦：Runtime+TargetAction
我用协议来解耦的时候:
1.我有一个管理类是作为调度层，这样子就可以方便统一调用
2.我的 Protocol 头文件，Model 都已经沉淀到底层基础框架了，整个 App 模块默认引用了
这里用协议来解耦，也是有一个管理类统一调度的，这种情况是不是跟中间人调用差不多了？
跟 CTMediator 相差的就是使用 protocol 还是 TargetAction 的区别？
在这种场景下，我觉得两种方案优劣是差不多的。展开 6
2019-03-19之前在两个公司都用过CTMediator,个人感觉也是最好的解耦方式,虽然有硬编码的问题,但是层次结构非常清楚,十分利于维护.但是目前感觉还是router或者协议化用的比较多,router就不提了,缺点比较明显.协议化除了后面需要严格控制接口输出之外,会造成维护上的困难,另外协议如果不进行严格的判断,也容易造成崩溃问题,也需要额外的开发成本去判断. 6
2019-03-19希望越来越多的demo提供给大家学习呀，感谢！ 5
2019-03-24CTMediator其实是有几个缺点的:
1.如果因为组件找不到而产生一些error,这里虽然不会崩溃,但是调用方其实并不知道,虽然可以对CT进行一些扩展让调用方通过回调知道,这其实也有利于一些UT的编写.
2.大量的通过字符串进行调度,实际上很硬核,后期的维护由于没有IDE能帮你做检查,其实复杂了不少.
3.CT其实是命名域上的解耦,但我认为项目还是应该更仔细认真的去设计组件和组件间的依赖,毕竟比如你这个功能实际上比如是依赖a和b两个模块,你只导入了b,虽然能够运行,但是实际上功能是不完善的,没有什么意义
关于戴老师说的组件只是把能通用的部分才进行组件化还是很赞同的,还有拆分的思路,和人员的搭配,目前也是这么做的,现在的swift项目,想的是就利用cocoapods加协议进行了大量的业务依赖设计,如果你需要导入这个业务模块,他会将相应的业务模块也进行导入,这样无论是类型检测还是相关业务的导入都比较方便.
我认为CT这样的做法还是比较偷懒的.但是CT其实也能学到不少,自己仿照着写了个,主要是作为一个利用runtime消息安全发送机制.另外casa老师的将内部和外部调用区分开也很值得学习.展开 4
2019-03-20我之前参与过的项目架构，本质都是MVC。要么根据Tabbar的功能模块，分到不同的文件夹里，然后每个文件夹对应一个功能组件，第三方与也分到一个单独的文件夹，但本质上还是MVC。要么业务与业务分开的项目，其架构模式也就是各个业务负责各自的业务功能解决，每周开会确认各个业务间所需要的配合，但还是MVC。根本牵扯不到模块力度的划分、团队的合作方式就是当面或者微信聊、唯一可以谈的分层也就是对网络请求、数据库的处理、ViewController的底层封装，然后各自如何使用全看自己。。只要Bugly没有收集到崩溃、测试与产品没有页面卡顿与BUG修复等需求、美工没有页面布局的调整，就算是合格完成任务了。。。 4
2019-03-19目前也是采用了casatwy的CTMediator组件化方案，项目采用了基础组件+功能组件+业务组件进行架构分层，根据实际业务需求合理选择设计模式，合理遵守六大原则，不要拔出萝卜带出泥 4
2019-04-16个人感觉 CTMediator 框架其实还是硬编码方式的，只是通过类别包装了一下，将硬编码调用这块转嫁到库者手中。当然对外是没有这个硬编码的，对内的话，该有的问题仍然存在。 3- 2019-03-20我们目前使用的是 url scheme + router ，服务器可以直接返回 url 做跳转。url 使用plist 预先配置好。大家给提点意见。 3
- 2019-03-19协议化也可以引入统一调度层管理，维护category和protocol的区别，而且有编译检查 3
2019-03-19大神，我问下目前使用WKWebview的cookie丢失问题能处理吗？ 3
2019-03-19现在负责的是一个很小的项目，用的还是普通的MVC模式，是否也需要改变架构，就是说，在小型项目中（没有变成大项目的可能性），使用中间者架构会不会更麻烦了作者回复: 小型项目其实是可以用中间者架构的，也是为了做大做准备
3
2019-03-19这篇讲到了痛点，但感觉还不够解渴，待我细细品味demo，期待铭神的后续😍 3