Extend DZTableView的可扩展性探讨
既然我们要实现一个类似于UITableView一样非常通用的组件，也就要求DZTableView的可扩展性就要好一点。这包括：
属性的可配置型
功能上的扩展性，方便子类化
为了展示这个，特意做了右滑删除，还有下拉新建cell的功能。因为本文的主要目的是通过自己构建一个TableView来解释IOS UI编程。所以就不详细展开讨论。看一下代码大概就能明白了。
什么是可扩展性
我们要理解可扩展性这个东西，最好的一个方法就是给他下个定义。因为我一直坚信一句老话：you can say it， you know it。只有当你能够准确定义一个东西并且描述它的时候，你才能够真正说你理解了它。于是我们查了一些资料来找关于可扩展性的定义。
Wiki上说：可扩放性(Scalability)是指问题规模和处理器数目之间的函数关系（Wiki）。这个怎么看也觉得和我们想要讨论的问题，有点不太搭边。
百度百科上说：设计良好的代码允许更多的功能在必要时可以被插入到适当的位置中。这样做的目的的是为了应对未来可能需要进行的修改，而造成代码被过度工程化地开发。
可扩展性可以通过软件框架来实现：动态加载的插件、顶端有抽象接口的认真设计的类层次结构、有用的回调函数构造以及功能很有逻辑并且可塑性很强的代码结构。
可扩展性是软件设计的原则之一，它以添加新功能或修改完善现有功能来考虑软件的未来成长。可扩展性是软件拓展系统的能力。
简单地说，可扩展性就是关于如何处理更大规模的业务。比如，Web应用程序就是允许更多的人使用你的服务。如果你不能弄清楚如何提高性能的同时向外扩展，没关系。只要你能处理更大规模的用户，即使是存在多个单点故障也没有问题。组合的可扩展性要求要满足用户不断发展的要求，还要满足因技术发展需要而实现的扩展和升级的需求。 百度百科。
这个解释貌似开始靠点谱了，但是有种大杂烩的感觉。像是还有些什么东西不能够说出来。
在苦苦寻找后，最后发现没能够发现比较合适的资料来解释可扩展性这个东西。那么就只能够说说我自己的看法了。
可扩展性是一种设计概念，代表了我们对未来的一种预想，我们希望在现有的架构或者设计基础上，当未来某些方面发生噶边的时候，我们能够以最小的改动来适应这种变化。我们的改动越小，并且对这种变化的适应性越好，我们就会说这个设计的可扩展性是非常好的。简单来说，就是让当前设计去适应未来不确定的变化。
很多时候，让设计有可扩展性是和设计者本身有着非常直接的联系。举个例子来说，我们在UI编程的时候，经常会遇到很多hardcode的代码，把很多控件的坐标用死数字写死。我们对这样的代码嗤之以鼻，因为他们适应不了任何变化。一旦屏幕大小发生改变，甚至是父视图的布局发生改变，就会让整个界面混乱。因为，那些用死数字写死的坐标的控件，真的是死的。无论周围条件发生怎样的改变，他们都无动于衷，呆若木鸡。当我们去问做出这样设计的工程师的时候，他们会非常简单的反问你：需求不就说要展示成这个样子吗？也就是说，他们没有任何对未来的预期。在他们眼中，需求就是最终的模样，之后不会发生任何改变。
而与之形成对比的是，在UI编程的时候，有很多人即使在像IOS这种使用绝对布局模型的框架下编程的时候，他们也尽可能把相对布局的观念运用在编程实践。比如一个界面要布局三个控件，他们不是将三个控件的坐标写死，而是尽可能的找到这三个控件布局之间的关系。尽可能的通过描述这种关系来进行布局。比如他们发现着三个控件是居中对齐的，那么他们就会用代码去描述这种居中对齐的关系。他们这样做带来的好处是，当父视图布局或者其他条件发生改变的时候。整个界面会自动调整布局来适应这种变化。当你去问做出这样的设计决策的工程师，为什么要这样做的时候。他们会说：他妈的产品和设计的需求天天变，你现在写代码不考虑这种变化，将来你就得花更多的时间去改代码。
Last updated