[APP开发-使用Swift]观念介绍:面向对象的程序设计与协议的程序设计

面向对象编程 还记得我们在“观念介绍:类,对象”介绍过史蒂夫·乔布斯针对OOP的说明: 物体就像人。 他们在生活,呼吸着对自己有做事知识的事物,并在其中拥有记忆,以便他们能够记住事物。 与其在非常低的层次上进行交互,不如在我们这里所做的那样,以非常高的抽象级别与它们进行交互。 〜史蒂夫·乔布斯 让我们以下图视觉化洗衣店的范例: 先假设一个小故事,Z大初来乍到台湾,不会说中文,身上没有台币,人生地不熟,连衣服想送洗都不知如何做,因缘际会,Z大认识了会说中文的A,Z大决定请A先生帮他送洗衣服。当Z大把脏衣服交给A处理后,A知道哪里有洗衣店,也知道如何搭计程车到目的地,身上刚好也有台币现金,任务完成后就把干净的衣服送回给Z大,Z大对送洗衣服这件事完全不了解,也不知道A怎么送洗衣服,他只要知道A处理就可以,这就是所谓的“高度抽象” 。 面向对象的概念就实际上是将送洗衣服的知识与逻辑包装在一起,对Z大来说他不需要知道送洗衣服的细节,他只要将送洗衣服这件事情交由A处理即可。 面向协议的编程 如果Object-Oriented的概念是像A一样是位本身唯一的知识的个体,那么Protocol-Oriented就只能称为是份求才广告或工作契约。 继续我们送洗衣服的故事。Z大对送洗衣服的要求越来越多,例如希望送洗的衣服可以快速送回,或者希望能以更便宜的价格送洗衣物,这些都让没有负担,因此A决定将Z大的要求转化为一份求才广告并附上职务说明贴在网路上,符合条件的人即可应征。第一位应征者B回覆了,他告诉A他知道有一家洗衣店非常便宜,他也知道如何搭计程车可以快速地送回衣物。另一位应征者C回覆说他知道可以搭如何使用Uber洗衣的服务,这可是很多人不知道如何使用的。 这时候A已不曾有人送洗衣服的知识,他只是准备求才广告内容而已,符合条件的B,C,D均可以帮他实现送人洗衣服的工作,当然一个本身会严格要求其他人要遵守他制定的条件。 面向协议的也将送洗衣服这件事情的知识与逻辑包装,只是用的是一种“规范”的概念,Z大不知道送洗衣服如何快速送回,也不知道如何花很多的钱送洗衣服,他只要告诉A,A帮他定义规范,其他人实作内容,Z大就可以获得满意的送洗服务。 如果说OOP让我们可以用物件的方式来思考,我们的确可以让A变成一位无所不包的个体,从而Z大的所有要求,我们都让A可以做到,可是在OOP单一继承的的原则下,很容易将上层的类变成一个上帝类,Z大的要求有所改变或增加,都要透过A,程式码容易变得庞杂且没有弹性。 如果Z大单纯地只需要送洗衣物就好,其他什么都不需要,那我们可以使用OOP设计。但如果Z大针对送洗衣物的要求很多,例如希望时间可以快速,希望控制预算等等,那么就需要考虑使用POP架构作设计,方便对每一个初始化做控制,让程序开发更多弹性。 >>>…

对象比原始对象更好,通常但并非总是如此

在编程范例的一种极端情况下,即使只是传递一个原语会容易得多,但对于每一个该死的小事情,都过分依赖对象。 如果没有充分的理由,也可以包装原始元素(尽管有时这是粗心而不是极端主义的结果​​)。 在另一个极端,我们看到了对象的过度使用,将所有程序逻辑转储到一个基本静态的主类中,没有定义其他对象,仅使用完成工作所需的最少标准库对象。 前者是Java肿的声誉的一部分。 您需要一个对象来完成一项小任务,然后您又知道要导入十个不同的程序包。 后者有时被称为“原始痴迷”,可以使Java程序具有几乎程序上的味道。 在引入对象之前,它甚至可能看起来像是编程课程早期章节的示例。 当然,您和我知道的更好,通常选择中间路线。 但我不怕承认,我偶尔需要远离任何一个极端。 这是我正在研究的实际程序中的一个具体示例:代数整数计算器(源代码和测试可在GitHub上找到)。 这里有一些简单但不熟悉的数学,但是,如果您对基本的高中代数有扎实的掌握,那么您应该可以毫无困难地继续学习。 这个项目源于我的程序,用于绘制虚二次整数环中的质数图。 像这样的图: 这是由RingWindowDisplay类绘制的,该类确实使用单个ImaginaryQuadraticRing对象保存有关特定数字域的一些基本信息,并使用一个或两个ImaginaryQuadraticInteger在给定视图中循环显示数字。 但是很多计算都是使用整数基元完成的,有些计算是使用浮点基元完成的。 这些原语大多数都是局部变量,所以我想很好。 此时, RingWindowDisplay不需要添加和乘以任意虚数二次整数的功能,但是ImaginaryQuadraticInteger确实为此提供了功能。…