为什么不应该把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，不过现在其实写的人不多。

当年我跟刘总争论过这个问题。我的主张是scroll view，且主张auto layout。

首先要说，使用table view确实是一个方案，是不影响实现单页的，只是我认为如果实现的方案是经过精心设计的，scroll view会更加好。

使用scroll view时，上面的1.2.3.其实不是问题。假设你不使用auto layout，在实现把b隐藏掉的需求的时候，一样也是修改b的height就好了（A.height＝a.height+b.height），不需要走delegate的途径。刘总说的那种情况，只存在于所有的rect都是写死的固定数值的情况，我想应该没人会去写死它。

如果走delegate的途径，那么可想而知在那个heightForRowAtIndexPath里面会有茫茫多的if else（因为要判断是哪个cell，每个cell的内容和高度都不一样），这个代码看上去是非常丑陋的，而且是跟V纯相关的东西，结果在C里面。而且就算区分了每一个indexpath，针对固定的一个indexpath也不可能写死高度，高度是一定要去计算的，因为详情描述这样的view的高度是根据内容的多少来决定的。

于是我们得到一个结论：单页view及子view的高度肯定得自己去算。

我认为与其放在controller里面让controller去算高度，不如放在view里面，让view自己去算高度，然后贴在scroll view上，这样子controller更瘦，逻辑也更清晰（大部分人能够区分什么时候代码写在M里面，什么时候代码写在C里面，但是很少人能区分什么时候代码写在V里面，什么时候代码写在C里面）。

而且，这样一来，view的可重用性非常强，基本上拿到A这个view，直接贴到别的地方去就好了，而且它自己知道该有多大，这就是可移植性。如果写成cell的话，得额外多做很多事情（首先你得去找到那个C，把计算尺寸的代码给copy过来）。维护成本其实比tableview更低，如果要添加一个view，table view的话要改很多地方，scroll view直接贴上去就好了，自己会算高度（这个功能是你自己写的，但其实一点都不复杂），删除一个view也是一样的道理，连view的内存都不用分配，直接从代码里拿掉就好。

最后一点，你会发现其实auto layout这门技术已经帮我们做了计算的事情了，而且我们也支持6.0了，那就用auto layout呗，担心什么？怕有bug不会解？如果将来出大屏iPhone，CGRect模式就很悲剧了，那才是真正要担心的地方。安居客PAD基本是全部auto layout的（后面接手PAD的人特么不愿意学autolayout，有部分代码是CGRect的，心头痛啊我擦）。

总而言之，如果不去精心设计这个scrollview，动态计算尺寸的话，table view更加好。如果精心设计这个scroll view，无论从可移植性还是可维护性上，都比table view要好很多。至于“我们尽量用框架提供的方法”这样的话，我认为是要分场合的，如果框架提供的方法适用这个场合，那当然用框架的，如果框架提供的方法部分适用，那还是别削足适履了。

我觉得“与其放在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而已。这种情况下用框架提供的方法比较适合。
刘总头像好帅。。。

路过 围观下