GO,or not to GO

organicswan 发布于1年前 阅读14432次
0 条评论

GO,or not to GO

全世界有上千种程序开发语言,其实自己要发明一种语言也不是很难的事情。但问题是,为什么需要新语言,尤其是通用软件开发语言?

一般来说,语言是一种工具,当工具不够用的时候自然会有更新工具甚至换一种工具的需求。按照 TIOBE 开发语言排名来看,前20种语言已经占据了超过 75% 的开发量,这些语言在绝大部分场合都是够用了。

然而,作为技术界走在前面的 Google 可不是这么想的。鉴于现有的语言们都有这样那样的问题,因此它在2007年推出了一种新的通用语言:Go 。

GO,or not to GO

自从1967年 Simula 语言第一次引入了面向对象程序设计的雏形以来,OOP(Object-Oriented Programming)就占据了软件开发思想的主导地位。当然这需要归功于 C++ 及其的衍生语言们 Java、C# 等。以至于现在说起 OOP,可能大家第一印象就是 C++、Java 中的 class。

但 Google 觉得完全不是这么回事,从 C++ 开始就走错了路,语法越来越复杂、学习门槛越来越高、维护越来越困难,反观 C 语言本身,虽然在语言层面不支持 OOP,但经久不衰,在 TIOBE 开发语言排名上,C 的使用量几乎是 C++ 的2 倍还多,究其原因,在于 C 已经足够强大且足够简单。

传统的桌面软件开发如今被移动开发、互联网开发追赶,大规模和高性能的软件开发的需求越来越明确,C++ 和它的继任者们总有这样那样的力所不逮。因此新的语言,比如 Go,就应运而生。

GO,or not to GO

1、你有什么特别的,Go?

在深入 Go 之前,先让我们看一下两段功能上基本一致的代码。

C++ 的版本:

GO,or not to GO

Go 的版本:

GO,or not to GO

有什么不一样?好像没什么不一样吧?等一等,为什么 Go 没有 class?是的,Go 并没有 class,实际上,不仅没有 class,所有和 class 相关的,比如构造函数、虚拟函数都是没有的。

OOP 对我只代表消息、局部持有和保护、状态处理的隐藏,以及对所有事物尽可能的延后绑定。

——Alan Kay

注:Alan Kay:Alan Curtis Kay,是美国计算机科学家,在面向对象编程和窗口式图形用户界面方面做出了先驱性贡献,他是 Smalltalk 的最初设计者。2003年获得图灵奖。

Go 忠实地实践了 Alan 的理想,而没有使用 C++ 们所引入的概念,包括继承和多态等。原始的概念让我们可以从另外一个角度来审视复杂系统的设计,同时来欣赏这些概念所带来的简洁性。

从 OOP 的角度上来说,类并不是必须的概念,这只是一种被刻意特化的类型,赋予了承载 OOP 的重任,但对于其它的一些语言来说,典型的比如 C 语言,即使没有这些机制,一样可以实现 OOP。

2、没有class,没有 this

在 Go 的这个例子里,类型 Connection 就是一个结构,和其它在 C 和 C++中被称为结构的东西是一样的。而 Connect() 这样的方法表示向 Connection 对象发送的一个消息。

GO,or not to GO

请再等一下,发送消息?这个说法有些耳熟——实际上,另外一个语言采用了相同的概念,那就是近年来日渐流行的 Objective-C。不同的是,Objective-C 采用的是运行时动态消息传递,而 Go 采用了静态消息传递。并且,Go 做得更加彻底,在 Go 中方法可以向任意类型(除了指针以外)发送消息,接收消息的对象在 C++ 中称为 this 指针,在 Objective-C 中称为self,而在 Go 中则可以用任意的变量表示——在这个例子中,就是 conn——并且需要显式声明,且也不一定需要是指针。

为什么不使用 this?问题应该是,为什么是使用 this?本质上 Go 不认为这个方法属于这个对象,this 也好,self 也好,都在强化这个概念,因此在 Go 中不建议这样使用。

3、只有组合,没有继承

在 HttpConnection 这个结构里看到了那个奇怪的 Connection 声明了吗?严格说起来这是一个匿名结构成员,在 HttpConnection 这个对象中组合了一个  Connection 对象。你可以组合任意多的对象,但在这个例子中,但它承担起了和其它语言中基类的作用。

C++ 中类内存布局规定,基类必须处于派生类内存布局的前部,但在 Go 中,开发者可以自己定义什么地方出现这个基类的实例。并且由于需要显式引用这个对象的实例,因此当组合了多个对象时,就和多重继承非常相似了。

继承有什么不好?在代码依赖关系中,继承是一种非常强的依赖关系,一旦代码写成,在不修改源代码的情况下几乎不可能改变。对于设计来说,只有一次机会来判断这样的设计是否正确,一旦设计不准确,那么再无修改的可能。然而做出这样的判断,是一件很困难的事情。

在传统的 OOP 教材中往往会有一个例子类似于这样:

猫是一种动物,猫会喵喵叫,黑猫是一种猫,它是黑色的,但它也会喵喵叫。所以猫应当从动物继承,而黑猫应当从猫继承。

GO,or not to GO

正确吗?未必。

如果有一种黑猫是呜呜叫的话,就会继承自黑猫,并改写“叫”这个方法。然而,如果是有一种白猫也是呜呜叫的呢?或者一种短尾的猫也是呜呜叫的呢?虽然多态性能够改变一些行为,但就从重用的角度上看,这不是合理的设计。

如果把“叫”作为一个可以组合的功能,那么在任何一种猫重用呜呜叫和喵喵叫,那么都是在运行时的一个赋值而已。

4、特殊的接口

接口是什么?其它语言中接口主要作为不同组件之间的契约存在,并且是强制的。接口作为一种类型,需要显式地声明某个类实现了这个接口。

还是以猫的例子:猫会叫,因此叫这个动作作为一个接口被猫这个对象实现了,然而猫也会爬,所以它还需要实现一个爬的接口。然而这种做法一点也不自然,并不是因为实现了爬这个接口,猫才是猫,难道不应该是先有了猫,才归纳出有爬这个动作吗?传统的接口概念就是这样一个本末倒置的状态,一旦对象的特性太复杂了,为了合理分解接口,这个任务会变得异常困难。

既然是契约,那么 Go 另辟蹊径,在 Go 中,接口只是方法的集合,一个对象实现了一个接口的所有方法,就说,这个对象实现了这个接口,而不需要继承、关联这个接口类型,实际上,对象在实现的时候甚至都不需要知道这个接口是否存在。

如果存在下面的接口:

type IConnectable interafce {

\tConnect(address string)

}

因为 HttpConnection 和 Connection 对象都实现了 Connect(address string)这个方法,因此这两个对象已经实现了 IConnectable 这个接口,甚至我们在实现那两个对象时,还没有定义这个接口!

下面这样的赋值就是合法的:

var conn IConnectable = new(HttpConnection)

5、其它特性

从 OOP 的角度上说,Go 采用了更为传统和淳朴的概念,相比于现在流行的  C++风格的 OOP 概念,Go 的概念更加简洁,更加灵活。

除了 OOP 的概念之外,作为一个现代语言,Go 突出的另外一个特性是它并发机制:goroutine 和 chan。相比于其它主流语言,它的并发机制异常简单和高效,相当于 C++ 数千行代码的并发机制在 Go 中只需要几句话即可实现,线程间通讯、缓存、超时,各类机制一应俱全,这可以在另外的文章中介绍。

GO,or not to GO

“To be or not to be ,that's a question."

——William Shakespeare

“To GO or not to GO, that's a question.”

——Google

注:

  • http://www.tiobe.com/tiobe-index//,一个著名的开发语言排名的统计网站

  • 2016年8月,Go 正式迈入前20名的开发语言队伍

本文作者:徐翎 Andrew(点融黑帮),任职点融网客户端开发总监,组建了移动和网站的开发团队,开发了点融网各款客户端软件。曾就职于微软等公司,参与过包括Hotmail 和Windows 在内的大型跨国际软件开发项目的研发。

本文由@点融黑帮(ID:DianrongMafia)原创发布于36Kr,未经许可,禁止转载。

查看原文:GO,or not to GO

需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。