这节课我们来试试开发一个简单的命令行小游戏,来完整的体验一次所谓的“开发过程”。
游戏设定是这样的:
这是一种棋盘类游戏,我们来猜测敌人战舰的位置,只要命中数发就可以击沉它们。
我们给这些战舰贴点标签……比如各种网站吧?所以,这就成了一个攻击网站的程序……捂脸。
游戏目标
我们要玩家以最少的次数攻击网站,把它击垮。然后我们根据玩家的猜测次数来进行评分。
大致设计
我们画一个7*7[……]
这节课我们来试试开发一个简单的命令行小游戏,来完整的体验一次所谓的“开发过程”。
这是一种棋盘类游戏,我们来猜测敌人战舰的位置,只要命中数发就可以击沉它们。
我们给这些战舰贴点标签……比如各种网站吧?所以,这就成了一个攻击网站的程序……捂脸。
我们要玩家以最少的次数攻击网站,把它击垮。然后我们根据玩家的猜测次数来进行评分。
我们画一个7*7[……]
我们在上课之前,一起来回顾一下以前曾提过的“SoC”的概念,我们说这个叫做“Separation of Concerns”,我把它翻译为责任分离——即不同的部分专注于自己的那一部分。或者说一个对象完成一个目标。
这样做的目标既让代码更加模块化易于维护,也让系统运行效率更高。所以说,我们要让对象之间的通信变得更加规范才行。
你去看看你在写代码时候用到的那些框架,哪个给你直接展示了[……]
我们使用 var 来声明一个变量,就好像从柜子里拿出了一个试管放在了实验台上;
我们给变量规定了一个类型,就好像在试管上贴上了标签;
那么放入的试剂就必须是标签上标记了的——否则可能导致中毒或者爆炸。
同样的,如果我们试图给一个储存器放入一个错误的数据类型,那么编译器就会报错——没错总有办法能够骗过编译器——反正我不会教你这个方法,那样就会导致程序崩溃啦。[……]
上一节课我们第一次领略了 OOP 的风采,于模棱两可的类和对象究竟是什么东西呢?这节课我们用一个简单的小栗子来向你介绍。
我们说类和对象的关系是设计图和产品的关系,就拿我们的房子来说,一栋楼肯定会有对应的设计图,但设计图绝不会只能对应一栋楼,至少一个小区肯定会用一套设计图不是吗?我们的“类”就是这个“设计图”。我们用这个设计图设计了对象的属性、功能等等的一系列内容,然后通过实例化来产[……]
考虑到有的同学没有 iPhone,但学习 Swift 语言大家至少都会有 OS X 操作系统,我们的代码演示都会在 OS X 下完成,使用 CLI 界面。这样虽然又显得古老了,但相信我去掉 GUI 会让你省心不少——因为那又是另一回事了。
我们来看看,用 OOP 进行开发到底会是个什么样子?
考虑到我们现在并没有很高的开发水平,那么我们把所有的功能实[……]
我们都知道在 Java 中声明一个抽象的类或者方法要使用 abstract 关键字,可是很遗憾熟悉的东西总会逝去,在 Swift 中已经没有了这个标签。
那么,我们究竟要如何来声明一个抽象的类呢?
这一点倒是让人很熟悉对吧?吧构造器私有了那这个类肯定就不能被初始化了,自然就不能创建对象实例……不过……哪有那么多但是,反正能用就行了!
[crayon-67b77[……]