context
现在公司的项目中,有两个界面表现几乎完全一样的控制器.如图:
但是两者的行为是部分有差别的,当时编码过程中,遵循了极限编程
的原则,尽快的写出可以实现功能的代码. 重构和使用模式的工作放在以后进行 . 以防止过度设计
带来的问题.
写好一个界面之后,直接复制代码,修改了部分.这在什么时候来看,都是编写的最快方式,但是却不是好的设计和可维护方案.
所以现在要开始进行重构了.
记录自己的进步
现在公司的项目中,有两个界面表现几乎完全一样的控制器.如图:
但是两者的行为是部分有差别的,当时编码过程中,遵循了极限编程
的原则,尽快的写出可以实现功能的代码. 重构和使用模式的工作放在以后进行 . 以防止过度设计
带来的问题.
写好一个界面之后,直接复制代码,修改了部分.这在什么时候来看,都是编写的最快方式,但是却不是好的设计和可维护方案.
所以现在要开始进行重构了.
这是一个给培训的同学写的Demo,概括起来的几个特点是:
这是没有修改的网页的地址 ,可以看到,顶部和底部有网页原来的两个条,需要隐藏,来实现如下的效果:
每个从事软件开发的人 , 都会强调设计模式的重要性.
软件模式的伟大之处 ,在于它们传递了了许多有用的思想 . 那么我们在学习了大量的设计模式之后,就理当成为一个优秀的软件设计和开发者 ,对吧 ? 模式帮助我们开发灵活的框架 ,帮助我们构建健壮 , 拓展性强的软件系统 . 但是现在的现状是 ,非常熟知设计模式的开发者 ,在工作中, 经常会犯过度设计的错误 .
所谓的过度设计 ,就是”杀鸡用了牛刀” .有些程序员这么做, 是因为它们认为自己正确地估计了软件系统的未来需求 . 他们急于这种未来的需求,应用各种设计模式 , 让软件系统能够更加灵活, 可拓展 . 但是能做到这种未卜先知的人又有几个呢 ? 如果估计错误 ,就要对繁冗的代码进行调整 .相应地 ,开发新功能和解决缺陷的时间就被减少了 .
说到对软件设计模式的偏执 , 这个还是非常容易理解的 . 小时候 ,我们得了一件新玩具 ,总是特别希望在小伙伴面前好好显摆显摆 .
相对于过度设计 , 设计不足要常见的多 (过度设计起码需要你掌握一些设计模式) . 设计不足是指开发的软件设计不良 . 其产生的原因有如下几个:
随着时间的推移 , 设计不足的软件将变成昂贵的,难以维护甚至无法维护的大麻烦.
一般省略函数参数的修饰符 ,我们并没有指定它是什么类型
1 | func incrementor(variable: Int) ->Int{ |
默认是 let ,比如下面的是错误代码 , 因为 let 不可变
1 | func incrementor(variable: Int) ->Int{ |
仔细看错误提示:Mark parameter with 'var' to make it mutable
需要显式写 var
1 | func incrementor(var variable: Int) ->Int{ |
函数参数是值传递,就是说,不会改变外部参数的值,比如:
1 | var number = 7 |
newNumber是 8 , number 还是 7 .
如果想要修改,那么就应该加上 inout修饰参数
1 | func incrementor(inout variable: Int) ->Int{ |
现在是引用传递, 那么 ,我们在传递的时候,应该传递的是引用(地址)而不是参数.用法如下:
1 | let newNumber = incrementor(&number) |
一般的,这样的函数,是不用返回值的.因为已经直接修改了参数1
2
3func incrementor(inout variable: Int){
++variable
}
函数的参数修饰是有传递限制的,就是说对于跨越层级的调用,需要保证同一参数的修饰符是统一的,比如我们基于上一个方法进行拓展,实现 +N 的方法.
1 | func makeIncrementor(addNumber: Int) ->((inout Int)->()){ |
外层 makeIncrementor 的返回里也需要在参数的类型前面明确指出修饰词,让它和内部的定义一致,否则编译不通过.
用户目录下的 .xvimrc 如果没有,新建一个即可
touch .xvimrc
imap zz <Esc>
映射 zz 为 Esc 的功能set ic
set ignore case 搜索的时候,忽略大小写