语言逻辑边界和新手友好

下面的结论是对比我和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。

   
  

  

你说的边界的概念不就是封装？
逻辑上是模块、类，物理上是独立的一个或多个文件。

有道理

对 就是这个意思。
在做设计的时候，划分的模块，模块和模块之间有个明显的边界存在。设计人员和熟悉这个设计的开发人员，一般不会去主动越界，而新手们则不一定。
一条“看的见”的边界，对新手们而言，意义重大。

是啊。模块边界是非常重要的特性。

一门语言，我首先关注的就是 module, package, namespace 这些概念的支持。

一些看法。

java, python 的 package 机制算是做的最好的，能够和文件目录对应起来。管理文件比较容易。import 都可以到达 static method 级别。

c#, ruby 的 namespace, module 也不错，而且 namespace 之间有从属关系。这是 package 不具备的特性。

如果这两者综合起来，就比较完美了。

pacakge 之间有从属关系，同时对应文件目录。import 达到可能允许的最小级别， static method, innerClass, 等。

service.interface
service.impl
business.interface
business.impl

不仅这4个package之间不能有交叉引用，service 和 business 之间也不能有交叉引用。

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

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

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

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

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

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

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