我们组一部分人做Java，一部分人做C++，有时候换着做，于是我写了一点Java和C++对照学习的东西。
会其中一个，对另外一个就好上手了。主要是以下两篇，涉及到的东西都是基础层面的东西。
http://healerkx.spaces.live.com/blog/cns!9485FFC4816F2CAD!911.entry
http://healerkx.spaces.live.com/blog/cns!9485FFC4816F2CAD!912.entry------------------------------------------------------------------------------------------------------------------------------------------------
还有一些关于敏捷开发的想法：
关于IDP的思考
IDP，倒置依赖原则与API层传统设计原则的对比。
这二者肯定有各自的优点和缺点的，我们不能千篇一律地遵循敏捷开发的原则。于是我就算是抛砖引玉吧，先写点我的想法，希望不是单纯地被砖拍，我希望是用玉来拍我，值。
先说IDP，要求上层给出接口定义，由下层来实现它。由这种方式来构建整个软件的框架。
我们注意书上这样的描述，如果细节变了，策略会受到影响。而IDP应该依赖于抽象。
那么我觉得我们的问题核心就变成了细节是怎么样的。
这里，就得说什么是细节，我个人这样理解细节：
1. 方法的参数列表
方法的参数列表表明了需求是如何的，需求变化的时候，往往可能需要改变参数列表。比如用户Login这个方法，需要username和password，但是如果需要验证码的时候呢？需要其角色或者权限呢？当然了，这些都应该想到的，但是总有想不到的地方。
2. 线程模型相关
线程模型是非常重要的，往往会影响到结构。如果某个方法运行的线程栈需要变化了，那么这个震动是巨大的。比如Socket的Send和Recv，它们的IO模型发生了变化的生活，那简直是不堪设想的，线程模型就可能需要调整了。
再有，API被调用的环境受限了。这个怎么说呢，比较说某些COM组件，一定要运行在套件线程上，环境真的可以提供这样的环境嘛？
比如说一个服务程序，不能与桌面发生交互(具体细节我并不是很确定，我的试验结果是可以创建消息循环的)。而API需要套件线程的支持了。
当然了，这种东西发生变化的时候，就该批斗设计师了。
3. 某些API和其他的API具有一定的耦合性，而这种关系发生了变化。
这些很有可能发生变化了，作为API，它们被调用的情况也发生了变化了。 这些总结未必是很严谨和完整的。
但是可以理解IDP为什么强调需要依赖于抽象了。
接口就完成了这种抽象的工作了。然而问题也就来了，抽象也是一种初期的系统需求设计，而且也是非常的困难的，往往要求设计师具有丰富的经验。
那么之前我们讲到的细节之处，在这个接口设计中，也要体现到，而且也可能发生一些调整，但是这种调整不再依赖于底层模块了。那么这层抽象，它是一个薄层，需要清楚地知道需求，体现在参数列表中，而且也需要清楚接口方法所要求的线程环境，定义出该接口的一些属性，比如说是否为阻塞性的和是否是同步方法。而且这些接口的正交关系希望得到稳定。
然后才能说到用底层去实现它。 其实如何实现这个薄层是个简单的事情，我猜。但是设计出这样的一个薄层并不简单。
在开发的过程中，需要有个简单的API作为这些接口的实现。 考虑协同开发
传统的API层设计中，API并不依赖于上层，开发API的人员可以独立开发API，并可以单独地完成单元测试；而上层依赖于API，在不必思考那层薄层的时候，就可以书写上层的逻辑了，在开发的过程中可以在没有某API真正实现的时候模拟API的行为，完成开发。
但是如果采用IDP原则，则需要把薄层设计出来，考虑非常全面的内容，完成系统的设计，不利于迭代开发。不过在设计完成后，需要做的工作倒是简单了许多，无论是对上层还是下层的开发人员。
这样想来，我觉得IDP是把系统的难度更多地让设计师承担了。 考虑单元测试
API曾经作为一种重要的实现部分，而且API并不依赖于上层，在做单元测试的时候，有着更加明确的测试方案，而现在，API做为接口的实现部分，它讲常常发生改变，以更好地实现接口部分。那么它的测试方案就需要频繁改变，它的单元测试变得复杂了。而且接口层的单元测试也需要底层的配合。而以往的API层，只需要明确API层的正确性就可以了(我这么臆测的)。 那么，说到现在，我以为IDP的接口定义部分的难度和API的易变程度，主要决定了是采用IDP，还是采用传统的API层。
此外，还有IDP带来了更大的复杂度，当这种复杂度是不必要的时候，那么我们完全可以采用API方法。
比如前面说过的Login的方法，我们只要想到Login的时候需要什么信息，和它所在的线程，它的阻塞属性等等就可以了。当我们想到这些的时候，你再以IDP的方式定义出对应的接口，就显得多此一举了。
------------------------------------------------------------------------------------------------------------------------------------------------我blog里面可能就这些和Java相关的东西了，我基本不参与Java的项目的。就把这些共享给各位吧。
会其中一个，对另外一个就好上手了。主要是以下两篇，涉及到的东西都是基础层面的东西。
http://healerkx.spaces.live.com/blog/cns!9485FFC4816F2CAD!911.entry
http://healerkx.spaces.live.com/blog/cns!9485FFC4816F2CAD!912.entry------------------------------------------------------------------------------------------------------------------------------------------------
还有一些关于敏捷开发的想法：
关于IDP的思考
IDP，倒置依赖原则与API层传统设计原则的对比。
这二者肯定有各自的优点和缺点的，我们不能千篇一律地遵循敏捷开发的原则。于是我就算是抛砖引玉吧，先写点我的想法，希望不是单纯地被砖拍，我希望是用玉来拍我，值。
先说IDP，要求上层给出接口定义，由下层来实现它。由这种方式来构建整个软件的框架。
我们注意书上这样的描述，如果细节变了，策略会受到影响。而IDP应该依赖于抽象。
那么我觉得我们的问题核心就变成了细节是怎么样的。
这里，就得说什么是细节，我个人这样理解细节：
1. 方法的参数列表
方法的参数列表表明了需求是如何的，需求变化的时候，往往可能需要改变参数列表。比如用户Login这个方法，需要username和password，但是如果需要验证码的时候呢？需要其角色或者权限呢？当然了，这些都应该想到的，但是总有想不到的地方。
2. 线程模型相关
线程模型是非常重要的，往往会影响到结构。如果某个方法运行的线程栈需要变化了，那么这个震动是巨大的。比如Socket的Send和Recv，它们的IO模型发生了变化的生活，那简直是不堪设想的，线程模型就可能需要调整了。
再有，API被调用的环境受限了。这个怎么说呢，比较说某些COM组件，一定要运行在套件线程上，环境真的可以提供这样的环境嘛？
比如说一个服务程序，不能与桌面发生交互(具体细节我并不是很确定，我的试验结果是可以创建消息循环的)。而API需要套件线程的支持了。
当然了，这种东西发生变化的时候，就该批斗设计师了。
3. 某些API和其他的API具有一定的耦合性，而这种关系发生了变化。
这些很有可能发生变化了，作为API，它们被调用的情况也发生了变化了。 这些总结未必是很严谨和完整的。
但是可以理解IDP为什么强调需要依赖于抽象了。
接口就完成了这种抽象的工作了。然而问题也就来了，抽象也是一种初期的系统需求设计，而且也是非常的困难的，往往要求设计师具有丰富的经验。
那么之前我们讲到的细节之处，在这个接口设计中，也要体现到，而且也可能发生一些调整，但是这种调整不再依赖于底层模块了。那么这层抽象，它是一个薄层，需要清楚地知道需求，体现在参数列表中，而且也需要清楚接口方法所要求的线程环境，定义出该接口的一些属性，比如说是否为阻塞性的和是否是同步方法。而且这些接口的正交关系希望得到稳定。
然后才能说到用底层去实现它。 其实如何实现这个薄层是个简单的事情，我猜。但是设计出这样的一个薄层并不简单。
在开发的过程中，需要有个简单的API作为这些接口的实现。 考虑协同开发
传统的API层设计中，API并不依赖于上层，开发API的人员可以独立开发API，并可以单独地完成单元测试；而上层依赖于API，在不必思考那层薄层的时候，就可以书写上层的逻辑了，在开发的过程中可以在没有某API真正实现的时候模拟API的行为，完成开发。
但是如果采用IDP原则，则需要把薄层设计出来，考虑非常全面的内容，完成系统的设计，不利于迭代开发。不过在设计完成后，需要做的工作倒是简单了许多，无论是对上层还是下层的开发人员。
这样想来，我觉得IDP是把系统的难度更多地让设计师承担了。 考虑单元测试
API曾经作为一种重要的实现部分，而且API并不依赖于上层，在做单元测试的时候，有着更加明确的测试方案，而现在，API做为接口的实现部分，它讲常常发生改变，以更好地实现接口部分。那么它的测试方案就需要频繁改变，它的单元测试变得复杂了。而且接口层的单元测试也需要底层的配合。而以往的API层，只需要明确API层的正确性就可以了(我这么臆测的)。 那么，说到现在，我以为IDP的接口定义部分的难度和API的易变程度，主要决定了是采用IDP，还是采用传统的API层。
此外，还有IDP带来了更大的复杂度，当这种复杂度是不必要的时候，那么我们完全可以采用API方法。
比如前面说过的Login的方法，我们只要想到Login的时候需要什么信息，和它所在的线程，它的阻塞属性等等就可以了。当我们想到这些的时候，你再以IDP的方式定义出对应的接口，就显得多此一举了。
------------------------------------------------------------------------------------------------------------------------------------------------我blog里面可能就这些和Java相关的东西了，我基本不参与Java的项目的。就把这些共享给各位吧。
解决方案 »
免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货