动态类型静态类型的优缺点--《松本行弘的程序世界》

偶然今天看到了《松本行弘的程序世界》一书，作者对静态类型和动态类型的优缺点做了详细的解释：

静态类型的优点：

        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，没了继承，唯一要做的就是检查对象是否有该方法(还可已在运行时为对象增加行为)，避免了令人费解的继承问题。程序也拥有了更好的扩展性。