?
偶然今天看到了《松本行弘的程序世界》一书,作者对静态类型和动态类型的优缺点做了详细的解释:
静态类型的优点:
? ? ? ? 1, IDE聪明的提示,因为静态类型的语言的类型是确定的,所以编辑器可以知道当前的变量有哪些属性和方法。
? ? ? ? 2, 编译的时候能够发现类型不匹配的错误,而动态语言至多只能发现语法错误。
? ? ? ? 3, 我们在开发过程中明确了某些变量在程序中扮演了什么角色,这是开发可靠性高的程序所必须的。
静态类型的确定:
? ? ? ? 1, 因为要定义数据类型,程序的规模也变得很大,编程应该考虑程序的本质,而不是把精力集中于一个个数据类型的定义。
? ? ? ? 2, ?缺乏灵活性,因为一个变量,只能赋值某种类型的对象。明显当程序需要扩展的时候,这会成为枷锁,当然可以通过继承和接口实现,这会陷入另一个深渊,你总会去纠结复杂的继承关系。
?
动态类型的优点:
? ? ? ? 1, 相反于静态类型,编程完全集中于程序的设计的本质,代码的简洁度也会提高,开发效率可能会数倍的提高。
? ? ? ? 2, 因为程序的规模降低, 程序的可理解性也会提高。(静态类型的拥护者可能会认为,少了类型信息,程序变的不可读了。我是觉得读程序应该集中在程序的本质上)
动态类型的缺点:
? ? ? ? 1, 程序执行速度慢,因为动态类型的语言,类型检查是在运行期做的。(随着计算机性能的提高,执行速度不是什么严重的问题了,关键是生产力提高了)
? ? ? ? 2, 不执行就检测不出错误。(这是我说的动态类型的安全问题)
?
这是松本大师对于类型的理解。
类型安全问题:?
?
public class Hello { public static void main(String[] args) { String a = "1"; test(1); } static int test(String s) { return 1; } }?
这段java代码在编译时肯定不能通过的。而在python中:
a = lambda x: x.startswith("abc")
a(1)
这段代码只有在运行时候才能报错。这应该就是类型安全问题吧!
作者基于动态类型的灵活性举了一种编程方式的示例:duck typing,就是说编程的时候,不要关心一个对象属于什么类型,而要关心这个对象有什么行为。
看一个示例:
?
#!/usr/bin/env ruby module Duck def bark puts "bark" end def run puts "run" end end class ADuck include Duck #ruby的混入,可以用来实现多重继承,类似于java利用接口实现多重继承功能 end class BDuck include Duck end def duckrun(d) d.run end a = ADuck.new b = BDuck.new duckrun(a) duckrun(b)?
这种编程方式是不是也可以称为面向接口编程,当然可以利用java的抽象类或者接口实现。
我们再看一个示例:
?
class ADuck def run puts "run a" end end class BDuck def run puts "run b" end end class CDuck end def duckrun(d) if not d.respond_to?("run") raise TypeError, "not a duck" end d.run end a = ADuck.new b = BDuck.new c = CDuck.new duckrun(a) duckrun(b) duckrun(c)?
这次没了module,没了继承,唯一要做的就是检查对象是否有该方法(还可已在运行时为对象增加行为),避免了令人费解的继承问题。程序也拥有了更好的扩展性。
就这么多了。。。