有关iOS设计模式的书也看过两本，大概是根基不牢经历不深，走马观花下来并没有留下什么深刻印象，今天上午经点拨略初探大神境界，瞬间埋怨组长代码复杂的小心思变成了惭愧。随笔记下。
技术背景：
以存储和展示房源信息简略举例说明，
如上表示，在我们开发项目中经常会遇到类似这种统一处理房源信息到系统问题：1、不同业务房源的关键属性不同，输入的key字段不同。2、即使相同的属性，不同业务部门工作人员使用的key字段不同，输入keyz字段有差异，不能同意。3、随着业务的不断扩大，房源分类越来越多，系统需要稳定的扩展。
存储房源信息
由于各类房源信息的属性不同、相同属性属性名不一致的问题，我们首先想到的是用代码实现业务逻辑，对每一种房源信息创建一个表来存储对应房源的信息，创建出多个表存储所有数据。每次储存、查询房源信息时，区别各种房源分类，再到对应的房源信息表中操作：
if([fangType isEqualToString:@"新房"]){
}elseif([fangType isEqualToString:@"二手房"]){
}elseif([fangType isEqualToString:@"装修"]){
}elseif([fangType isEqualToString:@"租房"]){
}
以上这种代码简单实现业务逻辑的方法对于每一个表的增删改查操作逻辑都需要代码实现一次。代码量增加，出现bug的几率自然也会增加，危及系统的稳定性。每次增加或者删除一个共有属性时，有多少表就要操作多少次，不易操作，可维护性差。随着业务的扩展，房源信息类型越来越多，需要建的的数据表越来越多，更不便操作，可扩展性差。未来维护系统的人力物力势必增加。这时候设计模式的重要性突显出来了，看下边的优化方案。
优化方案：
我们试着将以上房源信息类型同其他信息一样当作每一条房源信息的一个属性，把所有的房源信息都放到同一张表中，取出以上几种房源类型共同的属性作为数据库表的主要属性，例如每个房源都有的房源ID、地址address、面积area、加上房源类型fangCategory。将每套房源信息都有的属性作为key存到数据库中，同时将前端输入的所有属性拼接成字符串作为附加属性存入数据库。这样我们就将所有的房源信息统一存到一张表里量，省去了存表之前的if else的判断。
存储简单，去的时候也不复杂，每次查询时根据用户输入的房源类型、主要属性检索出符合条件的数据，读出每条数据的附加属性拼接的字符串，用非重要属性匹配出合适的房源并返回。在读取的时候也是可以避免使用if else判断业务逻辑的语句。
在存取的过程中还有一个问题，不同房源的业务人员存取时输入相同属性的key值不一致，这也会给我们存取带来些麻烦，其实对于这个问题，我们可以制定出一个映射关系，比如当前端输入fangCategory = @"esf"二手房的esfID时，我们在数据库中会存成ID，相反，当fangCategory = @"esf"时读取的ID会按照ID===>esfID返回给前端。像这样我们可以封装出一个映射属性名的类统一相同属性的属性名，来处理key值不一致的问题。
页面渲染问题
返回房源信息给用户，并以图文方式展示给用户，为了让用户一目了然，在图文显示的时候通常每种房源类型的展示类型也不同，如果仅仅是将业务逻辑通过代码展示出来，又将遇到前边讨论到的问题。
优化页面渲染问题
我们试创建一个虚拟类，用来实现要展示的房源信息图文，将房源信息中通用的图片、标题、房源地址等相同格式展示出来的信息在虚拟类中展示。同时声明出根据不同房源类型需要变换展示的部位的展示方法，交给各种房源类型的子类来实现，通过多态实现不同房源类型展示图文绘制的不同。对于页面点击交互也交与子类来实现。这也是在文章之初提到的组长写的复杂代码的能力。
总结
写代码不仅是用代码实现产品的业务逻辑，更重要的是转化成产品所拥有的能力。不只是分类存储各类房源信息、分类展示出不同房源类型的图文，而是具有存储各类房源信息、展示不同分类房源类型图文的能力。
在项目开发中会经常遇到这种要处理很多种数据的问题，如果我们只是按照业务逻辑通过代码简单实现也是可以完成当下的需求，但是随着业务的发展，这个问题会越来越明显，按照业务逻辑实现的代码会变的脆弱不堪，bug不断，不好维护，不易扩展，可阅读性降低。但从另一个角度出发，我们找出数据的共性和特殊性，将相同的逻辑封装成主流程，单独配置特殊流程，这样在以后操作起来会减少工作量，减少代码量，在扩展新业务时只需处理特殊配置，易维护易扩展，可阅读性也大大提高。
初见书上说尽量不要使用if...else...要用逻辑语句代替时，还是很困惑的，通过上午大神的后台逻辑讲解和我对这个例子的分析应用，深刻认识到读设计模式是要有代码量做基础的。
