为什么不应该把cell给替换成view

gistfile1.txt

-----------------
C                |
                 |
------------     |
A          |     |
     a     |     |
           |     |
     b     |
------------     |
B          |
           |     |
     c     |
           |     |
           |
------------     |

-----------------

上图为刘总的想法，如果这么做
1. 设想如果产品说要在b下插入一个view，这样你得先改变A的height，再改变B的y，再改变C的height。
2. 设想如果产品说要把b隐藏掉，你得先把A的height改了，再改变B的y，再改变C的height。
3. 如果要隐藏a，你得先改变b的y，A的height，再改变B height C height

如果保持现在的做法上述问题都没有(只要在代理设height就搞定了)，有个特别值得一提的好处是：
如果产品要把b隐藏掉，我只需要在delegate里把height设成0。
产品说又要b了，我们再把height设回去ok了。


这样做其实还有更大的好处在于，如果我们尽量用框架提供的方法，后人的维护将相当简单，因为那些代理方法他们本来就知道是干什么的。

还有一种科学的做法是Autolayout，不过现在其实写的人不多。

我觉得“与其放在controller里面让controller去算高度，不如放在view里面，让view自己去算高度” 说得非常好。
不过我觉得我们的C其实是**VC**，VC里放view的logic也不算奇怪。但是如果像房源单页这种内容比较多的页面，“让view自己去算高度”就非常合适，否则可能传说中的**Massive View Controller**。
我现在的情况是一个非常简单的页面，在这种情况下，用框架提供的方法比较适合。

学到了！非常感谢！解答了我一直的一个疑问～～～～～～
gist居然不可以传美女图。。。

casa 我想你应该理解错了，我没要求他用tableview, 是他一定要用tableview，就像你说的“如果走delegate的途径，那么可想而知在那个heightForRowAtIndexPath里面会有茫茫多的if else（因为要判断是哪个cell，每个cell的内容和高度都不一样），这个代码看上去是非常丑陋的，而且是跟V纯相关的东西，结果在C里面。而且就算区分了每一个indexpath，针对固定的一个indexpath也不可能写死高度，高度是一定要去计算的，因为详情描述这样的view的高度是根据内容的多少来决定的。”所以要求重构掉。

我认为我这个页面很简单，只有几个cell而已。这种情况下用框架提供的方法比较适合。
刘总头像好帅。。。

路过 围观下