iOS项目中，苹果公司给我们的建议是采用mvc的设计模式，mvc分别对应的是model层，controller层以及view层。一般从项目上的建议来说，model层存储的是view层要呈现的数据或者视图，但是model层和view层不能去直接通信，而是利用controller层来进行model层和view层的控制。
但是这样的想法虽然是把视图view，数据model以及控制中心controller分割开，但是在一个项目中，view层仅仅处理视图，model层存储数据，这俩个层级所能处理的东西就相当有限，所以大部分是由controller层来控制，这样如果对于项目整体理解和分割不够清晰，就会造成controller层的臃肿。
controller层的臃肿问题，比如说：我一般在项目中是把对于后台的请求，以及view层封装的视图的整体布局放在了controller层里面，但是这样，如果在其中一个controller层里所要处理的请求以及整体布局的逻辑相当多的时候，就会造成这个controller层代码混乱，结构不清晰，以及后期维护成本高（问题A）。
大多数的mvc的controller层臃肿的问题可以用另外一种mvvm的设计模式，但是如果用这个模式进行重构的话，成本高，我且不在这里谈论这个模式。
另外一种就是我要说的方式，这种方法仅仅是我在看书的时候总结的一个方式，仅仅存在于理论上，并没有去实践。
另外一种方式就是：以问题A为需要解决的问题，在问题A里那个所要处理的controller层，在这里我把它称为 混乱的c层。以这个混乱的c层为一个主要的枝干，然后把这个c层里面包含的一些功能，比如说 混乱的c层 里面包含功能a，功能b，功能c….，把这个功能点作为分支出去的次要枝干，混乱的c层 这个主要的枝干就用普通的主类来实现就行，而以功能点代表的次要的枝干就用分类（category）来进行实现。
用分类来进行实现有几个好处就是，不用对整个大的项目进行整改或者调整，在c层臃肿并不那么严重或者项目较小的情况下，采用这个方式不需要过多的去增加或者修改代码，仅仅是把一些功能点换了一个地方。正是由于换了一个地方，换了一个独属于这个功能点的地方，我们对于这个功能的维护就会相当清晰以及把每一个c层的逻辑结构分割独立出来。这样不仅重构成本低，对于后期维护的成本也会大幅度的降低。
以上仅仅是我理论的想法，在项目中的一些实践和要处理的事项以及细节部分以现在的我可能无法考虑完整，所以大家有好的建议和想法可以和我一起讨论。
例子相关在后期我会在实际项目中补上。
