1.第一个设计原则：对经常需要变化的代码，进行函数抽离
今天学到的第一个设计原则是 把代码中经常变化的部分利用函数的形式进行抽离，和不需要经常更改的代码进行隔离，有好一点的封装意识， 也是OO思想中封装的体现
2.针对接口编程
什么时候应该使用父类，什么时候 需要使用接口———这是我懵逼的地方
目前的理解是如果确定是什么“东西”的时候 我会考虑用继承 而只是有这个一个行为，但是没有具体确定行为实现的时候我会选择使用接口 不知道这么理解是否正确 还需要多写些代码 去理解其中的对与错
目前应用的场景如下(不知道合适不合适 ，需要后续检验)
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
UITableViewCell <LJDealDetailCellInterface>*cell = [tableView dequeueReusableCellWithIdentifier:[self cellIdentifierForIndexPath:indexPath]];
cell.selectionStyle = UITableViewCellSelectionStyleNone;
[cell setModel:_dataSource[indexPath.row]];
return cell;
}
我在我开发的模块下的将不同样式的cell进行灌数据的行为(setModel)进行抽离,形成了一个接口，具体接口定义如下：
@protocol LJDealDetailCellInterface <NSObject>
@required
- (void)setModel:(id)model;
@end
设计出发点：考虑到我的每一个cell样式都不怎么相同，进而个人感觉没有抽离公共父类的必要，但是进行数据赋值的行为都是要做的，因此抽出一个接口，让具体cell去实现，目前感觉是比较恰当的，而且我将所有的参数都封装model中保证形成一个通用的接口，即使样式不同的cell，由于设计的时候采用(id)类型，尽最大可能保证通用性，看了别的一些代码，对比以前其他人写的如下：
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
UITableViewCell *cell = nil;
if (indexPath.section == _infoSection) {
[infoCell setCellData:self.detailResponseModel];
cell = infoCell;
} else if(indexPath.section == _extInfoSection){
[instructioncCell setCellData:[NSString stringWithFormat:@"%@", self.detailResponseModel.communityName]];
}
return cell;
}
其中将多余代码进行删除，保留部分体现问题的代码,上述代码主要是根据具体row的找到对应的cell，进行具体的model赋值，我在我自己的vc类进行实现的时候，写了一个datasource数组进行有序存储model 因此没有判断的操作， 同时利用接口的函数 进行赋值，相对来说起码在代码量上会少不少
3.多用组合，少用继承
这个认为还需要多具体业务场景，组合通常考虑的是有一个或者若干个行为的，多个动作的组成。继承直接代表了是一个。例如男人、女人都是人，也就是父类是人。但是所有的动物都有“吃” 这个行为，仅仅是将吃放在“人”这个类中就不合适了，应该抽出来 做一个接口，所有动物都可以 有这个行为 。
网友评论