语言逻辑边界和新手友好

下面的结论是对比我和arath的两个项目组得出的一个初步结论

  开发语言的逻辑边界越明显，新手在用这种语言做项目时，越不容易失去控制。

最近我和arath都有个类似的项目，就是需要写一个比较高性能的服务器程序。为此我们讨论了很多次。arath的项目用C，我的项目用C++.

   其中有一次，arath提到了项目中的基础设计有些被改乱了。排除了各种人为因素之外，C代码明显比C++代码更加容易随意编写，而不易检查。C并不存在某种物理或者逻辑上的设计边界，C++多了个class的概念。且抛开是否因为OO，明显的C++可以用class来做出最简单设计边界。

   新手，模仿性强且极易把代码写飞，能够很快的离开原本设计。C++ Class 划定了一个基本模块，可以让新手有模仿之处。但是C++ Class的边界存在让其多了一个参考坐标，使其不易跑飞。
   C++ Class 一般都是一个h,一个cpp配对，当需要在A类中添加代码，只能在A.h和A.cpp中添加。如果某块代码归类归错，也是极易查找和调整的。C相对没有这样明显的逻辑和物理边界。如果没有对设计上有个清晰了解和没有抵抗随意编写代码的诱惑，时间长了，最终代码可想而知。

   编写C++代码会比编写C代码更容易遇到各种问题，但是好在循序渐进。class，基本类库，框架，线程，DLL等等这些都是边界，这类边界的存在，新手可以一步一步的前进，每遇到一个边界，就需要停下来摸索和学习。class和class的交互，如何调用基本类库，如何使用框架，线程间怎么通讯，如何编写和调用DLL。
 
    C#,JAVA则明显比C++对于新手更加友好。强类型，不能多继承，单文件代码，这些规则比C++更加让新手更加容易理解和模仿。Ruby的Class边界极易打破，而且还可以写在不同的文件中。还有Mixin功能。就这点而言，新手项目不应采用Ruby。

   
  

  

评论

24 楼 ddd 2006-10-14  

那么你也可以A功能的代码可以分散在某个文件的几个函数中。

23 楼 jack 2006-10-14  

ddd 写道

不要生气，似乎我还不太清楚你要表达的意思，自然语言本来就是这样容易造成混淆和二义。

如果指定某个class只能写入A功能的代码
我的理解是你的意思是指某个class的某个成员函数只能写入A功能的代码。
你的真正意思是A功能的代码可以分散在这个class的几个成员函数中？

是，没错，就是这个意思。

22 楼 ddd 2006-10-14  

不要生气，似乎我还不太清楚你要表达的意思，自然语言本来就是这样容易造成混淆和二义。

如果指定某个class只能写入A功能的代码
我的理解是你的意思是指某个class的某个成员函数只能写入A功能的代码。
你的真正意思是A功能的代码可以分散在这个class的几个成员函数中？

21 楼 jack 2006-10-14  

ddd 写道

如果由人指定，那么也可以让这个人指定某个函数只能写入A功能的代码。

带项目这样带，你这样还让不让人活。你自己想像下，这样会是什么样的场景？说个不好听的，你这样多少是有些抬杠了。

20 楼 ddd 2006-10-14  

如果由人指定，那么也可以让这个人指定某个函数只能写入A功能的代码。

19 楼 jack 2006-10-14  

ddd 写道

》如果指定某个class只能写入A功能的代码
在你看来应该如何指定？是带新手的人指定，还是其他手段？

带新手的人指定，所以语言本身需要各种边界存在，否则这种指定意义不大。没有边界，代码还是会写飞的。如果你有过带人的经验，就了解我所指了。特别是全部都由新人构成的项目组。

18 楼 ddd 2006-10-14  

》如果指定某个class只能写入A功能的代码
在你看来应该如何指定？是带新手的人指定，还是其他手段？

17 楼 jack 2006-10-14  

ddd 写道

我是反驳“封装这种事情，不应该由开发人员来掌控，就应该放在语言级别上。”的，你提到哪里去了？

C++中封装还得开发人员来掌控

呵呵 ，你上面说的太含糊了。

这里我只是希望有种语言封装能够在语言层次上做的很好，C++的class就是一种逻辑上的封装，而且我并非只指C++的封装做的很好，只是提出“逻辑边界越强，越容易带新手做项目”这样一个说法而已。这个也是对比两个项目组的不同表现初步得出的。
  这里提到class，并非从OO角度来理解这个概念。class实际上就是一种代码封装不是吗？在项目中，如果指定某个class只能写入A功能的代码，那么对于新手就会很明确的知道代码写在这里，而不是写在那里。这样的项目可控制性就会强很多。
    从项目整体来考虑这个语言逻辑边界对于项目的影响。这个是我的本意。
  

16 楼 ddd 2006-10-14  

我是反驳“封装这种事情，不应该由开发人员来掌控，就应该放在语言级别上。”的，你提到哪里去了？

C++中封装还得开发人员来掌控

15 楼 jack 2006-10-14  

ddd 写道

C++在新手那里也就是struct，哪来的边界。

C++的较为底层边界有2个，一个是C++ class,一个C++ class的文件组成方式，就是代码物理结构。实际编程中，有种说法不知道你听过没，就是 物理重用。意思就是把某个项目的某几个文件直接复制另外一个项目中，这几个文件不做任何代码上更改。这样的重用就是因为有边界存在而存在的。只要不试图强行打破这个已经存在的边界。做项目时会收益不少。

至于struct，除了当struct用，不会太多其他的用法，虽然struct可以代替class。

14 楼 ddd 2006-10-14  

C++在新手那里也就是struct，哪来的边界。

13 楼 jack 2006-10-14  

ddd 写道

绝对的封装C也能做到，不过大多数人不掌握而已（还有一种是认为自己可以驾驭无边界，用C嘛，就是用它的灵活），导致很多人恐怕都不知道这个东西。
比如FILE*的用法，你知道FILE是什么东西么？

封装这种事情，不应该由开发人员来掌控，就应该放在语言级别上。大部分人只是在使用技术而已，而非技术玩家

12 楼 ddd 2006-10-14  

绝对的封装C也能做到，不过大多数人不掌握而已（还有一种是认为自己可以驾驭无边界，用C嘛，就是用它的灵活），导致很多人恐怕都不知道这个东西。
比如FILE*的用法，你知道FILE是什么东西么？

11 楼 LucasLee 2006-10-13  

jack 写道

Lucas Lee 写道

这个话听着好熟悉。我以前就这么干的，统一一个开发方法、模式、骨架，然后搞几个人按照相同的模子填...
代码一致性当然好啦，维护起来也比较清晰(我没有说非常容易)

不过我后来发现这些相似的、有重复嫌疑的部分更应该让机器去做。
所以越统一，越有固定模版，就越应该、越可能更进一步
---元数据编程，只要给出不同的部分的定义，其他的用一套代码来做，而不是按一样的架子重复。

BTW，我已经走过了这一步。而且知道很多公司也走到了。大家一起来，：）

这样的事情要量力而行的，虽然理论上行的通，自己未必能够行的通。我向来反对过度追求这些。做项目是以实现项目为第一目标。至于这种提升，提升再提升的事情，还是让强人们去做吧。

量力而为也是聪明之举...

10 楼 jack 2006-10-13  

Lucas Lee 写道

这个话听着好熟悉。我以前就这么干的，统一一个开发方法、模式、骨架，然后搞几个人按照相同的模子填...
代码一致性当然好啦，维护起来也比较清晰(我没有说非常容易)

不过我后来发现这些相似的、有重复嫌疑的部分更应该让机器去做。
所以越统一，越有固定模版，就越应该、越可能更进一步
---元数据编程，只要给出不同的部分的定义，其他的用一套代码来做，而不是按一样的架子重复。

BTW，我已经走过了这一步。而且知道很多公司也走到了。大家一起来，：）

这样的事情要量力而行的，虽然理论上行的通，自己未必能够行的通。我向来反对过度追求这些。做项目是以实现项目为第一目标。至于这种提升，提升再提升的事情，还是让强人们去做吧。

9 楼 LucasLee 2006-10-13  

jack 写道

存在边界，另外有个好处就是可以构建很不那么容易被破坏的准框架代码。对于某些架构类似，实际操作效果又完全不同的模块，就可以先做一个例子。然后提供一个空的准框架，新手们只要模仿例子往里面填入代码。这样的架子可以快速让新手熟悉比较大模块架构，又把注意力集中在需要处理的事情上.

这个话听着好熟悉。我以前就这么干的，统一一个开发方法、模式、骨架，然后搞几个人按照相同的模子填...
代码一致性当然好啦，维护起来也比较清晰(我没有说非常容易)

不过我后来发现这些相似的、有重复嫌疑的部分更应该让机器去做。
所以越统一，越有固定模版，就越应该、越可能更进一步
---元数据编程，只要给出不同的部分的定义，其他的用一套代码来做，而不是按一样的架子重复。

BTW，我已经走过了这一步。而且知道很多公司也走到了。大家一起来，：）

8 楼 Arath 2006-10-13  

恩，当然这种边界限制是有很大作用的，配合一定的指导和管理对新手很有好处

7 楼 jack 2006-10-13  

Arath 写道

边界的掌握我喜欢人为的，这样对整体程序的控制、扩展、修改和性能会有不少好处.但是也十分惧怕这样的工程，因为同一个项目中不是所有的人都能控制好.
Class、namespace、module虽然从客观上强制，可以使项目合作变得更加有序，但实际上遇到不同的人还是可以把它打破.举个很简单的例子，MFC的document/view规划中，doc处理数据，view处理现实，算是一种不错方法，可是很多人照样不是在doc就是在view中处理所有的问题，而另一个基本不怎么用（汗，我的第一个MFC程序也是如此^.^）
所以对于边界我觉得完全在于程序员自己，而各种语法上的限制只是简单限制作用.

存在边界，另外有个好处就是可以构建很不那么容易被破坏的准框架代码。对于某些架构类似，实际操作效果又完全不同的模块，就可以先做一个例子。然后提供一个空的准框架，新手们只要模仿例子往里面填入代码。这样的架子可以快速让新手熟悉比较大模块架构，又把注意力集中在需要处理的事情上.

6 楼 Arath 2006-10-13  

边界的掌握我喜欢人为的，这样对整体程序的控制、扩展、修改和性能会有不少好处.但是也十分惧怕这样的工程，因为同一个项目中不是所有的人都能控制好.
Class、namespace、module虽然从客观上强制，可以使项目合作变得更加有序，但实际上遇到不同的人还是可以把它打破.举个很简单的例子，MFC的document/view规划中，doc处理数据，view处理现实，算是一种不错方法，可是很多人照样不是在doc就是在view中处理所有的问题，而另一个基本不怎么用（汗，我的第一个MFC程序也是如此^.^）
所以对于边界我觉得完全在于程序员自己，而各种语法上的限制只是简单限制作用.

5 楼 jack 2006-10-13  

模块边界是很重要，不过存在并容易打破，就又是另外一种麻烦了。
比如C#的namespace和ruby的class.