从软件工程的角度比较Swift、Go和Julia,我有了这些发现!

嵌入式资讯精选 2022-01-22 09:57

作者 | Erik Engheim

译者 | 弯月

出品 | CSDN(ID:CSDNnews)

从已有代码的扩展和重用方面考虑,这几种语言的类扩展、duck type(鸭子)和多分发孰优孰劣?

面向对象编程(OOP)是组织大型程序的方式之一,但并不是唯一的方式。本文将从代码重用的角度比较Swift、Go和Julia。Swift采用了OOP方式,还支持接口和类扩展。Go尝试从新的角度考虑代码重用问题,在静态类型语言中引入了duck类型。而Julia拒绝使用OOP范式,而是发明了自己的范式:多分发。 

下面,我们就来看看每种方式的优缺点。


Swift协议和类扩展

 

如果你想要传统的面向对象编程,那么很少有主流语言能打败Swift。没错,我的意思是,虽然Java和C#等语言与Swift差不多,但都不如Swift。那么Python如何?Python是一门优秀的面向对象语言。但这种比较不太容易,因为Python是动态类型。而Swift是静态类型,因此与Java或C#比较更容易。

但究竟是什么让Swift 成为了一个强力的面向对象语言?答案是类扩展和协议。下面是最近的一段代码中的例子。我需要在有序数组中支持二分查找。这样就能在O(log N)的时间内找到数组中的某个元素,例如8,同时不需要检查每个元素。下面是Swift代码:

let xs = [2, 4, 8, 10]let i = xs.binarySearch { x in x < 8 }

但Swift中的数组并不支持binarySearch。一些习惯了传统OOP语言的人可能会选择创建数组的子类。但是这会导致混乱的继承结构。继承应当用于表示新概念,而不是用来添加新功能。

但是在Swift中,你可以扩展接口(Swift称之为协议)来添加新方法。Swift的Array类实现了RandomAccessCollection接口,它属于标准库。但我们可以向这个接口添加任何新方法。我们甚至可以提供默认实现:

extension RandomAccessCollection {    funcbinarySearch(predicate: (Iterator.Element) -> Bool) -> Index {        var low =startIndex        var high =endIndex        while low !=high {            let mid =index(low, offsetBy: distance(                   from: low,                     to: high)/2)            ifpredicate(self[mid]) {                low =index(after: mid)            } else {                high= mid            }        }        return low    }}

这意味着Swift中任何实现了RandomAccessCollection接口的集合类型都可以使用binarySearch方法。

你几乎可以扩展任何东西,而不仅仅是接口。你也可以扩展类、枚举和结构。NSRange是一个结构(值语义的类),表示范围。它可以表示诸如文本视图中选中的文本,或字体和颜色均相同的一段字符。我编写了自己的WrittenDoc类,用于容纳可以打标签的文本。我希望创建一个范围,表示从一个标签到下一个标签。因此只需要扩展NSRange结构,给它一个额外的初始化器:

extension NSRange {    init(doc:WrittenDoc, tag: Tag) {       self.init(doc.charIndex(ofTag: tag)..count)    }}

因此,代码可以这样写:

let nextTag : Tag = tags[i+1] let range : NSRange = NSRange(doc: self.writtenDoc, tag: nextTag)

这个特性可以实现许多想都不敢想的事情。例如,在Swift中,一个字符串可以自己在屏幕上描绘自己。听起来这不像是正确的设计,因为这样需要把GUI和图形代码放到核心库中。但是,Swift并不是这样做的。如果只导入Foundation库,描绘功能是无法使用的。

但是,如果还导入了Cocoa库,就会包含一个针对String的类扩展,允许字符串描绘自己。这样,扩展就可以应用到不同的库中。图形相关的代码可以专门放到图形库中,但依然可以扩展基本类型。

这有什么用呢?它能解决访问者模式之类貌似有点别扭的模式。

Go中的duck类型

 

当然,面向对象编程并不是解决问题的唯一方法。Go使用了面向对象编程的元素,但尽可能保持简单。

在Go中,你不需要明确标示出对象实现了接口;只要它包含接口中列出的所有方法,就自动实现了该接口。因此,只要拥有类似Write方法的类都实现了Write接口。

type Writer interface { Write(p[]byte) (n int, err error)}

因此在Go中,你可以从已有的库中发明新接口,它就会自动实现,而不需要专门设计接口。这一点非常像Swift。

但与Swift不同,你不能扩展已有类型。相反,Go的方法是使用自由函数为简单接口添加功能。举个例子:

func main() { filename :="rocket-engine.txt" file, err :=os.Create(filename) if err != nil { fmt.Fprintf(os.Stderr, "Could not create %s because: %v\n",filename, err) os.Exit(1) } deferfile.Close() engine :="RD-180" var thrustfloat64 = 3830 fmt.Fprintf(file,"%s has thrust %0.1f\n", engine, thrust)}

这里可以看到,fmt.Fprintf函数用来向stderr和打开的文件写入格式化后的文本。fmt.Fprintf关心的只是第一个参数有没有遵循Write接口。你还可以在此基础上构建更多功能,从而为所有实现了Write接口的类型创建更复杂的功能。

这种方法的局限性是,你无法为不同的类型创建不同版本的Fprintf。在Swift中这样做是可能的。在Swift中,只需添加一个支持Fprintf的接口扩展,就能提供一个默认的实现,就像Go中的自由函数一样,但是可以为特定的类型提供一个特殊的Fprintf。但Go没有办法解决这个问题,除非使用并不太优雅的类型切换语句。


Julia中的多分发

 

虽然Swift中的面向协议的编程和扩展非常强大,但我仍然要说,Julia的多分发在组织和重用代码方面有更强大的范式。

下面来解释一下它的工作原理。我们假设Go和Swift都有类似于Julia的类型和接口,这样方便我们看到其中的区别。假设Swift和Go都有一个show函数或方法、IO接口和Any接口。

在Julia中对表达式求值,即可获得一个对象,该对象会在REPL(交互式命令行环境)中显示如下:

julia> xs = [3, 4, 8]3-element Vector{Int64}: 3 4 8

在Julia的提示符下,我创建了一个拥有3个元素的数组,存储在变量xs中。按回车键之后,Julia输出了该数组的描述。在Julia中,这是通过调用show方法完成的。当命令行需要显示一个对象时,就会调用其show方法。上例中调用方式大致如下:

show(output, xs)

它有两个参数。output表示控制台,xs是要显示的对象。Julia提供的默认实现大致如下:

function show(io::IO, obj::Any) # implementationcode goes hereend

该实现使用内省来确定类型拥有的字段并输出。因此,如果在Julia中创建自定义类型并初始化,就能得到一个合理的默认显示结果,如下面的构造函数调用:

julia> struct Point x::Int y::Int end
julia> p = Point(3, 4)Point(3, 4)

但是,我可以通过重载show方法来改变Julia中的显示:

import Base: show
function show(io::IO, p::Point) print(io,"<", p.x, ", ", p.y, ">")end 

现在,在REPL中显示p,就会得到不同结果:

julia> p<3, 4>

到这里一切都还好。Swift也可以做到这一切。假设它也支持Any接口,那么可以定义show方法如下:

extension Any { func show(io: IO){ //implementation code goes here }}

然后Point类可以这样写:

extension Point { func show(io: IO){ io.print("<", self.x, ", ", self.y,">") }}

但接下来Swift就力不从心了。假设我们需要通过UDP套接字发送一个Point的文本表示,需要发送一个特殊的表示。在Julia中可以这样写:

function show(io::UDPSocket, p::Point) print(io,"(", p.x, ", ", p.y, ")")end

这样就能通过UDP套接字发送(3, 4)而不是<3,4>。这个例子的确不太恰当,但可以演示为何多分发要更强大。

另一个更明显的例子就是处理不同几何形状的交点。在游戏编程中经常会用到这一功能,来判断不同几何体之间的碰撞情况。几何体可能是正方形、圆形或多边形。Julia可以定义一个方法来处理所有情况:

collide(a::Circle, b::Triangle)collide(a::Square, b::Circle)collide(a::Polygon, b::Square)

实际上这正是Julia中数值提升系统的工作原理。它会找到多个数值类型中的最小公倍数。


多分发的缺点

 

多分发看起来很不错,但它有什么缺点呢?OOP的优点是方法永远属于对象。只要有对象,就能查找其方法。但在Julia中,方法属于函数,而不是对象(准确地说是类型)。

如果很熟悉OOP的话,“方法”这个术语可能会让你感到迷惑。看一下collide的例子,它演示了collide函数的三个不同的方法。方法是函数的具体实现。一个函数可以有多个实现,每个实现都可以有不同的参数个数和类型。

因此,如果有一个Circle,我无法得知它有collide方法,因为方法属于所有的参数。

这也意味着Julia中很难获知一个对象是什么。Julia并不像OOP语言那样,对每个对象及其所有方法有集中的定义。但是可以认为,Julia的思想更函数式一些。你不需要关心对象,只需要关心函数及函数的行为。OOP关注的是名词,而Julia关注的是动词。

参考链接:

https://erik-engheim.scribe.rip/software-engineering-in-swift-go-and-julia-compared-5937bcb63143


1.RISC-V嵌入式开发课程节选版上线!文末还有图书优惠哦!赶快抢!

2.RISC-V能成为八位MCU的选择吗?

3.对嵌入式工程师硬件转软件的几条建议!

4.浅谈智能嵌入式系统的优化设计

5.单片机AD采样常用的十大滤波算法~

6.物联网时代,嵌入式软件测试工具越来越重要~

免责声明:本文系网络转载,版权归原作者所有。如涉及作品版权问题,请与我们联系,我们将根据您提供的版权证明材料确认版权并支付稿酬或者删除内容。