Java和C#细微差别导致迥异的解决思路
【IT168分析评论】当你从一种编程语言转到另外一种语言，你有没有发觉你自己考虑问题开始发生变化？
我用Java开发已经有八年了，我才是转到C#。C#语言借用了许多Java的优点，但是它也有自己的一些特色。许多C#中最有有价值的也被Java所采用。比如说最先在C#出现的attributes、generics、auto-boxing – which，这些都被添加在JDK 1.5 版本中。
尽管这些优点特征在不同的语言中来回采用，但是每一种语言仍然有它自己的独特之处。每种语言的一些方面将从来不会被其它的语言所采用，因为要引入它们的话，你就要改变语言就基本的概念，这会使得你先前的工作失效。
因此，我使用C#的时候，我会很小心的。在我使用Java之前，我还有七年的C++经验，并且我还记得当时转变的情景。岁让Java和C++非常相似，但是相同点会带来假象。表面上语言的一个小小不同，会在我思考，设计，测试应用程序时带来很大的不同。
Java给我带来了一些新的事物，如无用存储单元收集，类型反射，和非常有重大意义的异常处理。开始的时候，我是些写Java程序就像一个C++程序员。花了我一些时间来适应新的语句变化。通过理Java语言中新的，最基本的概念，我才能最终能让这门语言发挥它的最大威力。
因此，我学习C#的时候非常谨慎。尽管C#和Java非常相似。我不是说Java处理事情的方式不好才转变到C#上的。我同时了解其它开发者目前开发任务，来洞察采用这种语言处理事物最为有效的方式。
现在我在C#开发方面有一些经验了，但是我仍旧用Java做一些兼职的工作。因此我能很清楚的看到两种语言在细微的差别如何影响到我的设计理念。
C#事件和代理
这是C#最大的过人之处。我几乎无处不用观察者模式（Observer Pattern）。Observer Pattern允许你自动生成一个对象的事件，并且自动监听这个对象。在Java里，这个工作需要Java开发者做很多的工作。你需要创建一个接口，能够捕捉到你所有的事件，手动实现这些方法，在监听器中添加或者删除。
甚至实现事件监听器的方法也是很丑陋的。你需要创建事件接口的实现。匿名的内部类能帮上一点忙，但是他们会将代码零散。
java.util.Observable，简单尝试将这种设计方式封装成一个类。在JJK1.0就已经做了，但是这件事情没有多大的用处，仅仅是理论例子。
简言之，能够让C#的Observer Pattern模式应用在Java中是无法阻挡的。大多数Java开发者，没有去考虑是否存在这么一种工具，能够想C#那样自动创建事件和监听，这些在Java中都是很难测试和维护的。 对于不熟悉的C#的来说，你可以认为代理就是函数指针，事件就是一个特殊的类属性，它能自动的管理一组代理。所有这些监听接口和内部类在Java写起来很麻烦，如果有了C#中的那种机制，就能减少到一行。
在Java中实现Observer Pattern的复杂度常常使我不愿意去使用它，但是，在C#中我会毫不犹豫的使用。结果是，我在C#中设计代码和在Java中设计代码非常的不相同。我并不是有意设计得不相同的。只是每个语言有自己的自然特性，是我很自然的采取合适的方式来解决特定问题。
virtual方法
在Java中，所有的方法都能被覆写。为了禁止这种覆写的某种方法，你不得不明确的用final关键字声明。C#中正好是相反的。C#中的一个类的方法是不能被覆写的，出给你用virtual关键字明确声明。
和Java相比，这仅仅是一个小的变化吗？决不是的。在C#这种机制下，你想做出很小的行为改变是很困难的。有时甚至让我神经质。
唯一的解释是C#为了追求性能才这么做的。调用一个覆写的方法需要额外的步骤，需要去查找表格，而不是直接的执行。现在，这仍有争论。如果你想让你的应用程序能够在将后扩展的话，使用C#将是错误的。
允许其它的代码来覆写你的类方法能够使得你的类具有可扩展性。虽然一些类使用Template Method设计方式来限制覆写方法，但是大多数的类设计者很少能预测到他们设计的类该不该被覆写，具有多态的行为。这是很难预料的。
大多数的开发者会使用默认的方式来设计类，除非他们能事先知道特使类的用途才采取特殊的措施。因此，采用默认的方式是最为有用和最具扩展的方法。
表面上两种语言细小的不同，却使我考虑问题的思维极大不同。知道C#的类会限制多态（除非你为每一个方法都声明为virtual）的特性，我会被迫采取和开发Java应用程序不同的解决方案。
结论
这两个例子并没有暗示C#好，或是Java好。但是，它们明确的指出在这两语言之间转变的时候，开发者需要采取不同的思考方式，采取不同的解决方案。
我用Java开发已经有八年了，我才是转到C#。C#语言借用了许多Java的优点，但是它也有自己的一些特色。许多C#中最有有价值的也被Java所采用。比如说最先在C#出现的attributes、generics、auto-boxing – which，这些都被添加在JDK 1.5 版本中。
尽管这些优点特征在不同的语言中来回采用，但是每一种语言仍然有它自己的独特之处。每种语言的一些方面将从来不会被其它的语言所采用，因为要引入它们的话，你就要改变语言就基本的概念，这会使得你先前的工作失效。
因此，我使用C#的时候，我会很小心的。在我使用Java之前，我还有七年的C++经验，并且我还记得当时转变的情景。岁让Java和C++非常相似，但是相同点会带来假象。表面上语言的一个小小不同，会在我思考，设计，测试应用程序时带来很大的不同。
Java给我带来了一些新的事物，如无用存储单元收集，类型反射，和非常有重大意义的异常处理。开始的时候，我是些写Java程序就像一个C++程序员。花了我一些时间来适应新的语句变化。通过理Java语言中新的，最基本的概念，我才能最终能让这门语言发挥它的最大威力。
因此，我学习C#的时候非常谨慎。尽管C#和Java非常相似。我不是说Java处理事情的方式不好才转变到C#上的。我同时了解其它开发者目前开发任务，来洞察采用这种语言处理事物最为有效的方式。
现在我在C#开发方面有一些经验了，但是我仍旧用Java做一些兼职的工作。因此我能很清楚的看到两种语言在细微的差别如何影响到我的设计理念。
C#事件和代理
这是C#最大的过人之处。我几乎无处不用观察者模式（Observer Pattern）。Observer Pattern允许你自动生成一个对象的事件，并且自动监听这个对象。在Java里，这个工作需要Java开发者做很多的工作。你需要创建一个接口，能够捕捉到你所有的事件，手动实现这些方法，在监听器中添加或者删除。
甚至实现事件监听器的方法也是很丑陋的。你需要创建事件接口的实现。匿名的内部类能帮上一点忙，但是他们会将代码零散。
java.util.Observable，简单尝试将这种设计方式封装成一个类。在JJK1.0就已经做了，但是这件事情没有多大的用处，仅仅是理论例子。
简言之，能够让C#的Observer Pattern模式应用在Java中是无法阻挡的。大多数Java开发者，没有去考虑是否存在这么一种工具，能够想C#那样自动创建事件和监听，这些在Java中都是很难测试和维护的。 对于不熟悉的C#的来说，你可以认为代理就是函数指针，事件就是一个特殊的类属性，它能自动的管理一组代理。所有这些监听接口和内部类在Java写起来很麻烦，如果有了C#中的那种机制，就能减少到一行。
在Java中实现Observer Pattern的复杂度常常使我不愿意去使用它，但是，在C#中我会毫不犹豫的使用。结果是，我在C#中设计代码和在Java中设计代码非常的不相同。我并不是有意设计得不相同的。只是每个语言有自己的自然特性，是我很自然的采取合适的方式来解决特定问题。
virtual方法
在Java中，所有的方法都能被覆写。为了禁止这种覆写的某种方法，你不得不明确的用final关键字声明。C#中正好是相反的。C#中的一个类的方法是不能被覆写的，出给你用virtual关键字明确声明。
和Java相比，这仅仅是一个小的变化吗？决不是的。在C#这种机制下，你想做出很小的行为改变是很困难的。有时甚至让我神经质。
唯一的解释是C#为了追求性能才这么做的。调用一个覆写的方法需要额外的步骤，需要去查找表格，而不是直接的执行。现在，这仍有争论。如果你想让你的应用程序能够在将后扩展的话，使用C#将是错误的。
允许其它的代码来覆写你的类方法能够使得你的类具有可扩展性。虽然一些类使用Template Method设计方式来限制覆写方法，但是大多数的类设计者很少能预测到他们设计的类该不该被覆写，具有多态的行为。这是很难预料的。
大多数的开发者会使用默认的方式来设计类，除非他们能事先知道特使类的用途才采取特殊的措施。因此，采用默认的方式是最为有用和最具扩展的方法。
表面上两种语言细小的不同，却使我考虑问题的思维极大不同。知道C#的类会限制多态（除非你为每一个方法都声明为virtual）的特性，我会被迫采取和开发Java应用程序不同的解决方案。
结论
这两个例子并没有暗示C#好，或是Java好。但是，它们明确的指出在这两语言之间转变的时候，开发者需要采取不同的思考方式，采取不同的解决方案。
0
相关文章
关注我们
