C++博客-小丐的blog-随笔分类-我的读书笔记

关于javascript callback

littlegai — Thu, 09 Oct 2008 04:29:00 GMT

如果注册了客户端回调脚本，则Form中如下字段不为空
Page.Request.Form["__CALLBACKID"]
Page.Request.Form["__CALLBACKPARAM"]

littlegai 2008-10-09 12:29 发表评论

关于HttpApplication

littlegai — Fri, 19 Sep 2008 03:00:00 GMT

修改web.config
Session_End
Application_End
刷新页面
Application_Start
Application_BeginRequest
Application_AuthenticateRequest
Session_Start
再次刷新
Application_BeginRequest
Application_AuthenticateRequest

littlegai 2008-09-19 11:00 发表评论

如果sharepoint 不能卸载

littlegai — Sat, 16 Aug 2008 00:56:00 GMT

执行命令行 Stsadm -o uninstall 然后在控制面板里面卸载即可。

littlegai 2008-08-16 08:56 发表评论

修复Visual Studio

littlegai — Wed, 23 Jul 2008 16:06:00 GMT

有时候在添加Web引用的时候，会告诉你没有安装有关组件，需要重装Visual Studio，主要是因为所安装的扩展包出了问题，这时候可以用
devenv /resetskippkgs
修复

littlegai 2008-07-24 00:06 发表评论

Nebula Tips (1)

littlegai — Sat, 19 Jul 2008 13:27:00 GMT

可以在E:\Program Files\Nebula2 SDK\build\vstudio8目录找到编译的项目。
其中：Nebula2.sln是源代码
tutorials.sln是那些小例子
打开tutorials.sln（我用的是VS2008)，找到你要运行的那个项目（可以在SDK找对应的例子），设置一下包含路径和库(lib)路径，就可以编译了，通常编译过程会很顺利，但是我这里运行的时候，出现了：

nD3D9Shader:failed to load fx file 'h:/games/Nebula2SDK/data/shaders/fixed/shape.fx' with:
memory(34,9):ID3DXEffectCompiler:Error in type checking
memory(55,9):ID3DXEffectCompiler:Error in type checking
memory(67,9):ID3DXEffectCompiler:Error in type checking
ID3DXEffectCompiler:There was an error initializing the compiler
在http://nebuladevice.cubik.org/forum/index.php?topic=41.msg401#msg401可以找到解决办法，其中有效的一条是在nd3d9shader_main.cc
中设置编译标识为
D3DXSHADER_USE_LEGACY_D3DX9_31_DLL
找到方法bool nD3D9Shader::LoadResource()

/**
    Load D3DX effects file.
*/
bool
nD3D9Shader::LoadResource()
{
    n_assert(!this->IsLoaded());
    n_assert(0 == this->effect);

    HRESULT hr;
    IDirect3DDevice9* d3d9Dev = this->refGfxServer->d3d9Device;
    n_assert(d3d9Dev);

    // mangle path name
    nString filename = this->GetFilename();
    nString mangledPath = nFileServer2::Instance()->ManglePath(filename.Get());

    //load fx file
    nFile* file = nFileServer2::Instance()->NewFileObject();

    // open the file
    if (!file->Open(mangledPath.Get(), "r"))
    {
        n_error("nD3D9Shader: could not load shader file '%s'!", mangledPath.Get());
        return false;
    }

    // get size of file
    int fileSize = file->GetSize();

    // allocate data for file and read it
    void* buffer = n_malloc(fileSize);
    n_assert(buffer);
    file->Read(buffer, fileSize);
    file->Close();
    file->Release();

    ID3DXBuffer* errorBuffer = 0;
    #if N_D3D9_DEBUG
        DWORD compileFlags = D3DXSHADER_DEBUG | D3DXSHADER_SKIPOPTIMIZATION;
    #else
        DWORD compileFlags = D3DXSHADER_USE_LEGACY_D3DX9_31_DLL;
    #endif

    // create include file handler
    nString shaderPath(mangledPath.Get());
    nD3D9ShaderInclude includeHandler(shaderPath.ExtractDirName());

    // get global effect pool from gfx server
    ID3DXEffectPool* effectPool = this->refGfxServer->GetEffectPool();
    n_assert(effectPool);

    // create effect
    hr = D3DXCreateEffect(
            d3d9Dev,            // pDevice
            buffer,             // pFileData
            fileSize,           // DataSize
            NULL,               // pDefines
            &includeHandler,    // pInclude
            compileFlags,       // Flags
            effectPool,         // pPool
            &(this->effect),    // ppEffect
            &errorBuffer);      // ppCompilationErrors
    n_free(buffer);

    if (FAILED(hr))
    {
        n_error("nD3D9Shader: failed to load fx file '%s' with:\n\n%s\n",
                mangledPath.Get(),
                errorBuffer ? errorBuffer->GetBufferPointer() : "No D3DX error message.");
        if (errorBuffer)
        {
            errorBuffer->Release();
        }
        return false;
    }
    n_assert(this->effect);

    // success
    this->hasBeenValidated = false;
    this->didNotValidate = false;
    this->SetState(Valid);

    // validate the effect
    this->ValidateEffect();

    return true;
}
注意按照红色的地方进行修改即可，然后就回看到运行结果：

littlegai 2008-07-19 21:27 发表评论

javascript学习

littlegai — Wed, 23 Apr 2008 03:17:00 GMT

1、 Html标签如果环绕javascript代码，则会作用于它的输出

如：

2、不是W3C标准

W3C标准是：

但是有些浏览器不支持type方式声明javascript脚本，所以你最好两个都用，就如下面：

3、有些浏览器在执行脚本的过程中产生输出，但有些不能

Ready start

Running...

Keep running

Stop!

4、大多数浏览器喜欢把它们不支持的标签中的内容直接显示出来，如果你碰到一个浏览器恰好不支持javascript，你应该：

但是如果你所写的是严格的XHTML，注释标记就不大合适了，你最好：

<script type="text/javascript">

<![CDATA[

   ..script here ..

]]>

</script>

5、如果浏览器不支持javascript或者javascript被关闭了，最好写一段noscript，就像这样：

一个很有意思的用法就是，如果浏览器不支持javascript，就让他们跳转到一个错误页面，如下：

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

noscript Redirect Demo







 
6、 
事件响应方面，html是不区分大小写的，onclick,OnClick,onCliCk效果相同，但是在XHTML中，只接受小写。
大多数浏览器支持在地址栏中输入如javascript: alert('hello')的代码来运行javascript。当然，也可以以超链接的形式：Click to invoke

littlegai 2008-04-23 11:17 发表评论

Direct Show 笔记

littlegai — Fri, 22 Feb 2008 14:10:00 GMT

一、 总览：

Graph、Filter、Pin、Simple

Graph：可以理解为媒体处理的流程图。

Filter：可以理解为媒体处理流程图中的一个步骤。

Pin：可以理解为媒体处理各个步骤之间的数据流节点。

Simple：可以理解为各个形态的数据。

Filter的分类：

· source filter:将数据从源（比如媒体文件）引入Graph。

· transform filter：数据流入、改变、流出。

· Renderer filters：把最终结果展现给用户。

· splitter filter：比如把一个媒体流分解为视频和音频。

· mux filter：和splitter filter相反。

1. Graph Manager

主要对处于同一个Graph的Filter(s)进行统一的管理。

比如：

· 各个Filter的状态切换

· 建立同步时钟

· 事件回发

· 创建

为什么要统一管理状态切换？

因为处于同一Graph中的各个Filter的状态切换往往需要遵循严格的先后顺序。所以一般通过发送命令给Graph Manager的方式进行各Filter的状态变更。

为什么要建立同步时钟？

比如声像需要同步。

2. Media Types

结构体AM_MEDIA_TYPE定义了媒体类型。

主要包含如下结构：

· Major type: 由一个GUID来表示。通常包含音视频、未知流、MIDI等等。

· Subtype: 由一个GUID来表示。Major type为视频，则子类型可以包括RGB-24, RGB-32, UYVY

· Format block: 说明图形尺寸、帧率等信息。如果Major type为视频，sub type为RGB-24，则Format block的信息会被自动辨识。

3. Sample和Allocator

需要注意的是，各个filter之间并不直接传送它们各自进行处理的数据的指针。它们通过一个暴露IMemAllocator接口的Com组件来分配内存。填充了数据的内存被封装到Sample里面。各个Filter真正使用的是Sample。Sample通常包含：

· 内存指针

· 时间戳

· 标识

· 媒体类型（可选）

这里当一个Filter使用Sample的时候，它同时掌握这个Sample的引用计数，这样就有效杜绝了资源争用现象的发生。

4. Filter Graph中的硬件

硬件被封装到Filter中，任何与硬件的交互都转化为与Filter的交互。

二、 Graph-Building 组件

Filter Graph Manager.

Capture Graph Builder：设计的初衷是视频捕获,但是可以衍生很多用途。

Filter Mapper and System Device Enumerator：枚举可用的filter.

DVD Graph Builder

Video Control

1. 智能拼接

1) 如果在Graph里面有一个没有输入的Filter，那么Graph在完成自己的时候，就会考虑这个Filter。如果有一个已有的Filter的流出恰好与这个没有输入的Filter的流入相匹配，则将这两个Filter连接。

2) Graph在完成自己的过程中也会查找所有注册过的Filter与当前非终点Filter的流出进行匹配。注册的Filter会有一个权值，作为Graph进行连接尝试的优先级依据。

步骤：

1) 使用IStreamBuilder（如果pin实现了这个接口，但大多数情况没有）。（否则2）

2) 查找被缓存的Filter。（否则3）

3) 查找Graph现有的Filter。（否则4）

4) 查找所有注册了的Filter。

2. 关键方法

IFilterGraph::ConnectDirect:直接连接两个Filter，如不成功，返回失败。

IGraphBuilder::Connect：连接两个Filter，如果可能，直接连接，否则通过中间Filter(s)进行连接。

IGraphBuilder::Render：你自己建立了一系列从源开始的Filter，基于这些Filter(s)完成Graph。

IGraphBuilder::RenderFile：从一个文件开始完成Graph.

IFilterGraph::AddFilter:向Graph中添加一个Filter

通过这些方法，你可以：

1、由Graph Manager建立整个Graph。（通过RenderFile）

2、由Graph Manager建立部分Graph。（比如你想自己写一个AVI文件，当然也可以通过Render来生成预览）

3、完全手动建立整个Graph。（需要自己AddFilter，还需要自己Connect）。

三、 Direct Show 数据流概述

1. 关键接口（方法）

IMediaSample：对Filter之间使用的内存的封装。

IMemAllocator::GetBuffer：从allocator获取Buffer（即ImediaSimple的实现对象）

摘要：

由于Render会按照时间戳来Render数据，所以它会一直占用它的上一级Filter流入的Simple，直到时间戳所标识的时间到达。所以当上一级Filter用完了allocator的Simple池中的Simple时，会阻塞而不处理，进而反向影响到更上一级的Filters，从而使它们变为等待的状态。同时由于时间戳对于Render的时间上的要求，所有上级Render都必须在Simple的时间戳标识的时间到达之前处理完自己对于该Simple的动作。

2. Transport（传送）

· Push Model（推送模型）：上层filter（pin-out）将处理好的数据推送给下层filter(pin-in)。下层filter在需要数据的时候通过IMemInputPin::Receive来获取数据。

· Pull Model（抓取模型）：下层filter(pin-in)在需要数据的时候，通过IAsyncReader异步向上层filter请求数据。（通常用于视频文件的回放）

3. Samples and Allocators

1) 引用计数

上层Filter(pin-out)通过IMemAllocator::GetBuffer向Allocator申请Simple，如果此时没有Simple的引用计数为0，则说明Allocator的Simple池中没有可用的Simple，则GetBuffer的调用会被阻塞。一旦Simple池中出现可用的Simple，则先前阻塞的GetBuffer放行，并获取一个引用计数变为1的Simple。此Simple处理后，传递给下层Filter(pin-in)，下层Filter如果在Receive方法中处理Simple，则它与上层Filter的处理处于同一线程中，Simple的引用计数不会变化，如果下层Filter需要通过创建线程异步使用上层推入的Simple进行处理，则该Simple的引用计数会加1，变为2.之后如果上层Filter的推送线程结束，则Simple的引用计数减1，变为1.

2) 提交和撤销Allocator

IMemAllocator::Commit,在被调用之前，所有的GetBuffer无效，

调用IMemAllocator::Decommit之后，所有的GetBuffer调用无效.

4. Filter 状态变化

Filter状态的变化由Graph Manager进行控制。

所有的状态变化都是自低（Render Filter）向上（Source Filter）进行的。比如暂停的时候，Render Filter会首先暂停，这时候Render之上的Filter中都会存有未能推送的Simple，此时相当于在各个Filter之前都堆积了一些等待处理的数据。沿着Render向上的Filter逐个暂停，直到Source。当状态从暂停变化为开始的时候，Render会首先变化为开始状态，处理在它之前堆积的数据，并释放那些被占用的Simple。然后逐步向上直到Source,Source在能够获取Simple之后，数据继续流入Graph，整个Graph进入开始状态。

littlegai 2008-02-22 22:10 发表评论

重构--重构关系型数据库（1）

littlegai — Fri, 10 Aug 2007 14:47:00 GMT

1、数据库与面向对象编程语言的不同
关系数据库的关注点是数据结构的声明。这样的话一些封装手段就不可用了。没有封装，数据访问就不会被明显的约束。
表是通过外键关联的。这同样不能够被封装。
存在于数据库中的数据是持久化的，并且存活得比程序要长。数据库的结构一旦发生变化，数据就要进行迁徙。

如果系统被多次安装，那么就会有不同的数据库。那么如果数据库结构发生变化，这个变化同样要作用于每一份安装。

不同的用户可以同时访问数据，但是他们可以每人拥有一份程序的拷贝。

类可以继承，但数据不行。
源代码可以在本地进行维护和测试，之后发布到源代码管理服务器中。版本冲突可以被识别到，然后通过一些强有力的工具可以帮助解决这些问题。在大多数项目中，同一个数据库往往为多个开发人员服务。
维护源代码可以使用工具。数据库的结构和数据则只能够由人花更多的精力去维护。
访问数据库所花费的时间比起访问访问内存中对象的时间来要多上好几倍。

关系型数据库中的数据结构是浅层结构，然而当它们变成对象处于面向对象的系统中时，他们的含义变得更加深入，他们的关系变得更加错综复杂。

2程序与数据库打交道时产生的一些问题

当程序与数据库交互时，会产生这样一些问题：

程序与数据库之间的关联往往不是类型安全的（想象JDBC）。编译器无法评估程序与数据库是否结构性兼容。某些映射类和持久层把这些问题拿到了一边，却没有解决它们。类型安全性将会在影射类或持久层中失去，而不是其他的地方。

数据库将会“隐藏”一些对象。这种情况发生在对象被写入数据库或者在读取出来的地方。因此对象可以被程序的两个部分交换使用，而不需要显式得暴露于接口中。

大多数情况下往往采用表和对象一一对应的模式。这往往在强调数据的应用程序中是错误的做法。特别是当需要从数据库读取对象时，可能会需要多个表的极联，或者为了满足数据展示的需要，建立一些视图。结果，当数据库发生变化时，很难找到一个合适的途径来决定那些类也要跟着修改。反过来说，通常无法明确类的那些变化会影响到查询和视图。

还有一些琐碎的问题。数据库中的数据类型与程序语言中的基本数据类型之间的映射会造成一些困难。比如时间戳的尺度，采用浮点数尺度或采用string或变长字符串集合就会有相当大的差别。

在面向对象的系统当中，关联关系的建模是基于概念的（例如，账目和收支有关）。在关系数据库中，一对多关系和多对一关系都是适用的。所以也就无法找到一套确定的方案来实施重构。

因此我们在重构的时候需要着重考虑这样三个地方：

1）有关数据库结构、数据库模型的重构；

2）不同版本的数据库之间的数据迁移；

3）有关数据库访问代码的重构。

3重构关系数据库的数据库结构

在实践中，往往有一定数量的数据库模式平行存在。至少有两个模式：一个为开发者所使用（开发数据库）一个为用户所使用（产品数据库）。

因此开发者总是可以尝试着修改数据库而不去惊扰用户。只有当数据库被彻底的测试完成，并且适合于构建与其上的系统，这样才会将数据库、程序作为一个稳定版本提交给用户。

此外，每一个开发者应当拥有自己的数据库实例，这样他们才能够独立的测试他们对于数据库的一些变动而不会影响到开发团队的其他人员。这些不同版本数据库实例的存在使得数据的迁移变成了一个关键话题。在下面的部分，我们将会讨论这个话题。

“逐步进化”这样一个核心的原理不论在程序重构中还是数据结构的重构中都在重演着：老的结构并不会马上被新的所取代。新旧数据库结构往往会并存一段时间。老的数据库结构会被标记为“过期”以让那些新编写的程序不去访问它。然后已有的程序会被修改，一步又一步的向新数据库过渡。一旦这个过程结束，老的数据结构就算完成了它的使命，他会被终结然后删除。图5-1示出了表“Customer”的变革。一开始的时候，姓和名是作为一个字段存储的，他们合称作“Name”。现在姓和名会被存放在两个字段中，最后Name字段将被取代并被删除。

在中间的状态，表Customer包含冗余字段Name。程序或触发器需要保障它们之间的一致性。

在Java中，你可以把那些过时的程序标记上“已过时”。但是在大多数数据库和其他程序开发语言中没有提供相关的功能。

在关系数据库中，字段、表、视图甚至整个数据库的结构都有可能需要被标记为“过时”，当然，这视具体的重构过程而定。我们往往通过访问层面的限制或提示来体现这些独立的“已过时”标注。比如我们使用O/R mapping工具来生成这些数据的映射类，那么对于这些类或方法我们就可以用“已过时”进行标记了。当然，前提就是你许诺不会通过其他的手段来直接访问数据库。如果确实这样，在你的下一个版本中使用这种方式标记“过时”的数据库结构也就足够了。

如果你无法保证对于数据库的访问只是通过O/R mapping的映射类，那么就和你的开发团队订立协议吧。列一张表，在这个表列举因为重构而过时的那些东西。当然所有的开发者都要同意这个表上列举的重构结果，并且能够去贯彻它。

Ambler在他的网站上收集了很多数据库中会被频繁用到的重构方法。这些重构方法为数据库重构提供了一些依据。

Ambler的重构方法的目的在于为数据库的结构带来改观。因而只是独立的添加一列并不能组成一次重构。独立的添加一列不能够给数据库结构带来任何的改观。

有这样几种形式的重构：重构而提升数据的质量；重构而优化数据的结构；重构而提高数据的性能；重构而整合数据；重构而优化数据库框架。

littlegai 2007-08-10 22:47 发表评论

重构--改善既有代码的设计读书笔记第四章(1)

littlegai — Mon, 06 Aug 2007 13:50:00 GMT

4.2JUnit框架
单元测试
编写单元测试的目的是为了提高身为一个程序员的生产性能。至于让质保部门开心，那只是附带效果而以。单元测试是高度本地化的东西，每个test class只对单一package运作。它能够测试其他packages的接口，除此之外它将假设其他package一切正常。
功能测试
用来保证软件能够正常运作。他们只负责向客户提供质量保证，并不关心程序员的生产力。它们应该由一个喜欢寻找臭虫的个别团队来开发。这个团队应该使用重量级工具和技术来帮助自己开发良好的功能测试。
一般而言，功能测试尽可能把整个系统当作一个黑箱。面对一个GUI待测系统，它们通过GUI来操作那个系统。而对文件更新程序或数据库更新程序，功能测试只观察待定输入所导致的数据变化。
一旦功能测试者或最终用户找到软件中的一个bug，要除掉它至少需要做两件事。当然你必须修改代码，才得以排除错误，但你还应该添加一个单元测试，让它揭发这只臭虫。
4.3添加更多的测试
观察class该做的所有事情，然后针对任何一项功能的任何一种可能失败的情况，进行测试。这不同于某些程序员提倡的“测试所有public函数”。记住，测试应该是一种风险驱动行为，测试的目的是希望找出现在或未来可能出现的错误。所以我不会去测试那些仅仅读或写一个值域的访问函数，因为它们太简单了，不大可能出错。这一点很重要，因为你如果撰写过多测试，结果往往测试量反而不够。测试的要诀是：测试你最担心出错的部分，这样你就能从测试工作中得到最大收益。
考虑可能出错的边界条件，把测试火力集中在那儿。
寻找边界条件，也包括寻找特殊的、可能导致测试失败的情况。对于文件相关测试，空文件是个不错的边界条件。当事情被大家认为应该会出错时，别忘了检查彼时是否有异常如预期般的被抛出。
不要因为“测试无法捕捉所有臭虫”，就不撰写测试代码，因为测试的确可以捕捉大多数臭虫。
对象技术有个微妙处：继承和多态会让测试变得比较困难，因为将有许多组合需要测试。如果你有三个彼此合作的abstract class有三个subclass，那么你总共有九个可供选择的classes，和27种组合。我并不总是试着测试所有可能组合，但我会尽量测试每一个classes，这可以大大减少各种组合所造成的风险。如果这些classes之间彼此有合理的独立性，我很可能不会尝试所有组合。是的，我总有可能遗漏些什么，但我觉得“花合理时间抓出大多数臭虫”要好过“穷尽一生抓出所有臭虫”。
测试代码和产品代码之间有个区别：你可以放心的拷贝、编辑测试代码。

littlegai 2007-08-06 21:50 发表评论

重构--改善既有代码的设计读书笔记第三章(6)

littlegai — Mon, 30 Jul 2007 14:11:00 GMT

3.10Switch Statement
面向对象的一个最明显特征就是：少用switch或case语句。从本质上讲，switch语句的问题在于重复。通常用多态来解决Switch 语句带来的坏味道。switch语句常常根据type code进行选择，你要的是与该type code相关的函数或class。所以你应该使用Extract Method将switch语句提炼到一个独立的函数中，再以Move Method将他搬移到需要多态的那个class里头。此时你必须决定是否使用Replace Type Code with Subclass或Replace Type Code with State/Strategy。一旦这样完成继承结构之后，你就可以Replace Conditional with Polymorphism了。
如果你只是在单一函数中有些选择事例，而你并不想改动它们，那么“多态”就有点杀鸡用牛刀了。这种情况下Replace Parameter with Explicit Method是个不错的选择。如果你的选择条件之一是null,可以试试Introduce Null Object。
3.11Parallel Inheritance Hierarchies(平行继承关系)
在这种情况下，每当你为某个class增加一个subclass，必须也为另外一个class相应增加一个subclass。如果你发现某个继承体系的class名称前缀和另一个继承体系的class名称前缀完全相同，便是闻到了这种坏味道。消除这种重复性的一般策略是：让一个继承体系的实体(instance)指涉(参考、引用、refer to)另一个继承体系的实体。如果再接再厉运用Move Method和Move Field，就可以将指涉端的继承实体消弭。

3.12Lazy Class(冗赘类)
你所创建的每一个class，都得有人去理解它、维护它，这些工作都是要花钱的。如果一个class的所得不值其身价，它就应该消失。项目中经常会出现这样的情况：某个class原本对得起自己的身价，但重构使它身形缩水，不再做那么多工作；或开发者事前规划了某些变化，并添加一个class来对付这些变化，但变化实际上没有发生。如果某些subclass没有做满足够工作，试试Collapse Hierarchy。对于几乎没用的组件，你应该以inline class对付它们。
Collapse Hierarchy(折叠继承体系)
superclass和subclass之间无太大区别。
将它们合为一体。
动机
如果你曾经写过继承体系，你就会知道，继承体系很容易变得过分复杂。所谓重构继承体系，往往是将函数和值域在体系中上下移动。完成这些动作后，你很可能发现某个subclass并未带来该有的价值，因此需要把classes合并(折叠)起来。
作法：
选择你想移除的class：是superclass还是subclass?
使用pull up Field和pull up method或者push down method和push down field，把想要移除的class内的所有行为和数据搬移到另一个class。
每次移动后，编译并测试。
调整“即将被移除的那个class”的所有引用点，令它们改而引用合并（折叠）后留下的class。这个动作将会影响到变量的声明、参数的型别以及构造函数。
移除我们的目标；此时它应该已经成为一个空类。
编译、测试。

3.13Speculative Generality(夸夸其谈未来性)
如果所有的装置都会被用到，那就值得处理这些非必要的事情；如果用不到就不值得。用不上的装置只会挡你的路，所以，把它搬开吧。
如果函数或class的唯一用户是test cases(测试用例)，这就飘出了坏味道。如果你发现这样的函数或class，请把它们连同其test case都删掉。但如果他们的用途是帮助test cases检测正当功能，当然必须刀下留人。
3.14Temporary Field(令人迷惑的暂时值域)
有时你会看到这样的对象：其内某个instance变量仅为某种特定情势而设。这样的代码让人不易理解，因为你通常认为对象在所有时候都需要它的所有变量。在变量未被使用的情况下猜测起当初设置的目的，会让你发疯。
请使用Extract Class给这个可怜的孤儿创造一个家，然后把所有和这个变量相关的代码都放进这个新家。
如果class中有一个复杂算法，需要好几个变量，往往就可能导致这种坏味道。由于实现者不希望传递一长串参数，所以他把这些参数都放进值域中，但是这些值域只在使用该算法的时候才有效，其他情况下只会让人迷惑。这个时候可以用Extract Class把这些变量和其相关的函数提炼到一个独立的class中，提炼后的新对象是一个method object。
3.15Message Chains(过渡耦合的消息链)
用户索求对象，然后向求得的对象继续索求对象。
这时候应该使用Hide Delegate。应该先观察Message Chain最终得到的对象是用来干什么的，看看能否以Extract Method把使用该对象的代码提炼到一个独立函数中，再运用Move Method把这个函数推入Message Chain。
Hide Delegate(隐藏委托关系)

当类图如上所示时，客户端如果想要获得对应Person的Manager，需要如下过程：

Department department = person.Department;
Manager manager = department.Manager;

通过重构，为类Person添加属性Manager，如：

1 public class Person
2     {
3         private Department _department;
4         public Department Department
5         {
6             get
7             {
8                 return _department;
9             }
10             set
11             {
12                 _department = value;
13             }
14         }
15         public Manager Manger
16         {
17             get
18             {
19                 return _department.Manager;
20             }
21         }
22     }

这样客户端可以这样写：
Manager manager = person.Manger;
当然如果person不属于任何一个部门，那么程序就会出错。这里其实可以引入Null Object来解决问题。

3.16Middle Man（中间转手人）
人们可能会过渡运用delegation。你也许会看到某个class所实现的接口有一半的函数都委托给其他class，这样就使过渡运用。这时你应该使用Remove Middle Man，直接和职责对象打交道。如果这样“不干实事”的函数只有少数几个，可以运用inline Method把它们放进调用端。如果这些Middle Man 还有其他的行为，你可以运用Replace Delegation with Inheritance把它们变成实责对象的subclass，这样你既可以扩展原对象的行为，又不必负担那么多的委托动作。
Remove Middle Man
这个重构过程和Hide Delegate刚好相反。
Replace Delegation with Inheritance

这个重构过程就是把关联关系转换为继承关系。
即

转变为

3.17Inappropriate Intimacy
当两个类彼此关系紧密地时候，有可能是他们所包含的方法或值域处在错误的类中而导致，此时应当通过Move Method或Move Field把它们移动到合适的位置。应当看一下两个类之间是否真的需要双向导航关系，如果不是，让它们之间的关系变为单向导航关系。或者通过Extract Class把共同的函数或值域抽取出来，让每一个Class直接去调用被抽取出来的类。另外如果是子类和父类过分耦合，则可以通过将继承转换为关联的手段来降低耦合性。
3.18Alternative Classes with Different Interfaces（异曲同工的类）
如果两个函数做同一件事，却有着不同的签名式，应当运用Rename Method根据它们的用途重新命名。请反复运用Move Method将某些行为移入classes，直到两者的协议一致为止。或许可以使用Extract Superclass来解决问题。
3.19Incomplete Library Class（不完美的程序库类）
当你面对的程序类库不够好( 或者不能满足要求）而你又不能直接改变它时，可以采用Introduce Foreign Method 方法来修改其中一两个函数，或者使用Introduce Local Extension来添加行为。
Introduce Foreign Method (162)
在client class建立一个函数，并以一个server class实体作为第一个参数。书中的例子：

Introduce Local Extension(164)
这种重构方式实际上就是从已封装的类库中继承你认为功能不足的那个类，然后添加你想要实现的功能。当然，有时候你想扩展的那个类碰巧加上了关键字final(java) 或sealed(c#)，这样就没办法了。
3.20Data Class(纯稚的数据类)
所谓Data Class是指：它们拥有一些值域，以及用于访问这些值域的函数，除此之外一无长物。早期的Data Class可能会包含public值域或容器类值域，应当首先将它们封装起来（用属性或特定方法）。尽量可能的把外界操纵这些值域的方法搬移到类里面来，那些不应该被其他classes修改的值域，请运用Remove Setting Method。
Remove Setting Method
即去调设值函数或属性中的set让它变为只读。
3.21Refused Bequest
当子类不愿意继承父类的某些东西时，建议将继承修改为关联。不建议随便修改继承体系。这是一种很淡的坏味道。
3.22Comments(过多的注释)
注释本身并不是坏味道，它可以帮助我们找到代码中的坏味道。
如果你需要注释来解释一块代码做了什么，试试Extract Method；如果method已经提炼出来，但还是需要注释来解释其行为，试试Rename Mehtod；如果你需要注释说明某系系统的需求规格，试试Introduce Assertion。
当你感觉需要撰写注释，请先尝试重构，试着让所有注释都变得多余。
如果你不知道该做什么，这才是注释的良好运用时机。除了用来记述将来的打算之外，注视还可以用来标注你并无十足把握的区域。你可以在注释里写下“为什么做某某事”。这类信息可以帮助将来的修改者，尤其是那些健忘的家伙。
Introduce Assertion
引入断言。
某一段代码需要对程序状态作出某种假设。注意，你可以创建自己的断言，而不仅仅是依赖已有断言。

littlegai 2007-07-30 22:11 发表评论

重构--改善既有代码的设计读书笔记第三章(5)

littlegai — Tue, 17 Jul 2007 13:26:00 GMT

3.5 Divergent Change ( 发散式变化)
针对某一外界变化的所有相应修改，都只应该发生在单一class中，而这个新class内的所有内容都应该反映外界变化。为此，你应该找出因为某特定原因而造成的所有变化，然后运用Extract Class将他们提炼到另一个class中。
3.6Shotgun Surgery(散弹式修改)
如果每遇到某种变化，你都必须在许多不同的classes内作出许多小修改以响应之，你所面临的坏味道就是散弹式修改。
这种情况下，你应该使用Move Method和Move Field把所有需要修改的代码放进同一个class。如果眼下没有合适的class可以安置这些代码，就创造一个。通常你可以运用Inline Class把一系列相关行为放进同一个class。这可能会造成少量发散式变化，但你可以轻易处理它。

InLine Class

场景：你的某个class没有做太多事情(没有承担足够责任)。
将class的所有特性搬移到另一个class中，然后移除原class。
作法
在移动的目的class身上声明所有被移动的class的公共属性和方法。(如果“以一个独立接口表示source class函数”更合适的话，就应该在inlining之前使用Extract Interface)
修改所有source class引用点，改而引用吸收被移动的class的目标class。(将source class声明为private，以斩断package之外的所有引用可能。同时并修改source class的名称，这便可以使编译器帮助你捕获到所有对于source class的dangling reference(虚悬引用点)
编译，测试
运用Move Method和Move Field，将source class的特性全部搬移到目标class。
3.7Feature Envy(依恋情结)
有一种经典的气味是：函数对某个class的兴趣高过对自己所处之host class的兴趣。这种倾慕之情最通常的焦点便是数据。无数次经验里，我们看到某个函数为了计算某值，从另一个对象那儿调用几乎半打的取值函数。疗法显而易见：把这个函数移至另一个地点。你应该使用Move Method，把它移到它该去的地方。有时候函数只有一部分受这种依恋之苦，这时候你应该使用Extract Method把这一部分提炼到独立的函数中，再使用Move Method带它去它的梦中家园。
往往一个函数会用上数个classes特性。那么它究竟该被置于何处呢？我们的原则是：判断哪个class拥有最多“被此函数使用”的数据，然后就把这个函数和那些数据摆在一起。如果先以Extract Method将这个函数分解为数个较小函数并分别放置于不同地点，上述步骤也就比较容易完成了。
3.8Data Clumps(数据泥团)
将“总是绑在一起出现的数据”放进属于它们自己的对象中。首先找出这些数据的值域形式出现点，运用Extract Class将它们提炼到一个独立的对象中。然后运用Introduce Parameter Object 或 Preserve Whole Object为参数过长的成员函数减肥。
一个好的评判数据泥团的办法：删除掉众多数据中的一笔。其他数据如果不再有意义，这就是个明确的信号：你应该为它们产生一个新对象。

3.9Primitive Obsession(基本型别偏执)
对象技术的新手通常不愿意在小任务上运用小对象--像是结合数值和币值的money class、含一个起始值和一个结束值得range class、电话号码或邮政编码(ZIP)等等的特殊strings。你可以运用Replace Data Value with Object将原本单独存在的数值替换为对象。如果欲替换之数值是type code（型别码)，而它不影响行为，你可以运用Replace Type Code with Class将它换掉。如果你有相依于此type code的条件式，可运用Replace Type Code with SubClass或Replace Type Code with State/Strategy 加以处理。
如果你有一组应该总是放在一起的值域，可运用Extract Class。如果你在参数列中看到基本型数据，不妨试试Introduce Parameter Object。如果你发现自己正在从array中挑选数据，可运用Replace Array with Object。
Replace Type Code with Class
在以C为基础的编程语言中，type code(型别码)或枚举值很常见。如果带着一个有意义的符号名，type code的可读性还是不错的。问题在于，符号名终究只是个别名，编译器看见的、进行型别检验的，还是背后那个数值。任何接受type code作为引数(argument)的函数，所期望的实际上是一个数值，无法强制使用符号名。这会大大降低代码的可读性，从而成为臭虫之源。
如果把那样的数值转换为一个class，编译器就可以对这个class进行型别检验。只要为这个class提供factory method，你就可以始终保证只有合法的实体才会被创建出来，而且它们都回被传递给正确的宿主对象。
但是如果枚举被switch所使用，你就不能简单地将它替换为class。因为switch往往只会接受整型数据。所以应该首先对switch运用Replace Conditional with Polymorphism重构，而在这之前，还要进行Replace Type Code with Subclasses或Replace Type Code with State/Strategy把type code处理掉。
作法：
1、为 type code建立一个class。其中包含相应的用于记录type code的值域，并准备一组static变量保存允许被创建的实体，并以一个static函数根据原本的type code 返回合适的实体。
2、修改source class代码，让他使用上述新建的class。
3、编译、测试
4、对于source class中每一个使用type code 的函数，相应建立一个函数，让新函数使用新的class。你需要建立“以新class实体为自变量”的函数，用以替换原先“直接以type code为引数”的函数。你还需要建立一个“返回新class实体”的函数，用以替换原先一直返回type code的函数。建立新函数前，你可以使用Rename Method修改原函数名称，明确指出那些函数仍然使用旧式的type code。
5、逐一修改source class用户，让它们使用新接口。
6、每修改一个用户，编译并测试。
7、删除使用“type code”的接口，并删除保存旧type code的静态变量。
8、编译测试。
Replace Type Code with SubClass
我的理解：

在这里Room类包含一个属性IsMeetingRoom。如果为true，则这个房间就是一个会议室，如果为false，则这个房间就是一个普通的房间。这里true和false可以理解为一个简单的“型别编码”。它可以重构为下面的形式：

更复杂的情况：

这样就需要根据RoomType的实际数量分离出多个子类来。

作法：
使用Self Encapsulate Field方法把type code自我封装起来。如果type code被传递给构造函数，你就需要将构造函数换成factory method.
为type code的每一个数值建立一个相应的subclass。在每个subclass中覆写type code的取值函数(getter)，使其返回相应的type code值。
每建立一个新的subclass,编译并测试。
从superclass中删除掉保存type code的值域。将type code访问函数声明为抽象函数。
编译，测试。
Replace Type Code with State/Strategy
你有一个type code，它会影响class的行为，但你无法使用subclassing。
以state object(专门用来描述状态的对象)取代type code。
之所以无法subclassing是因为Type Code会在对象生命周期过程中发生变化。
如果你打算再完成本项重构之后再以Replace Conditional with Polymorphism(用多态替换条件判断)简化一个算法，那么选择Strategy模式比较合适；如果你打算搬移与状态有关的数据，而且你把新建对象视为一种变迁状态，就应该使用State模式。

Replace Array with Object
你有一个数组(array)，其中的元素各自代表不同的东西。
以对象替换数组，对于数组中的每个元素，以一个值域表示之。
String[] row =new String[3];
row[0]="Liverpool";
row[1]="15";
转换为
Performance row=new Performance();
row.setName("Liverpool");
row.setWins("15");
3.10Switch Statements

如果你只是在单一函数中有些选择事例，而你并不想改动它们，那么“多态”就有点杀鸡用牛刀了。这种情况下Replace Paremeter with Explicit Method是个不错的选择。如果你的选择条件之一是null，可以试试Introduce Null Object
Replace Paremeter with Explicit Method
此方法即是将包含多个switch分支的函数的各个分支独立成不同的函数。比如：
public static Object CreateObject(int typeOfObject)
{
      switch(typeOfObject)
      {
            case 1:return new A();
            case 2:return new B();
            case 3:return new C();
      }
}
转换为：
public static Object Create1()
{
      return new A();
}
public static Object Create2()
{
      return new B();
}
public static Object Create3()
{
      return new C();
}
思考：这样会削弱此函数的运行期特性。
Introduce Null Object
使用这种重构方法的好处就是你不用在向一个对象发送消息的时候去检验这个对象是否存在。因为对象确实存在，只不过有可能对你发送的消息做出“我是空”的回应。
作法
为source class建立一个subclass，使其行为像source class的null版本。在source class和null class中都加上IsNull()函数，前者的IsNull()应该返回false，后者的应该返回true.可以建立一个nullable接口，将isnull函数放在其中，让source class实现这个接口。
另外可以创建一个testing接口，专门用来检验对象是否为null.
编译。
找出所有“索求source obejct却得到一个null”的地方。修改这些地方，使他们改而获得一个null object。
找出所有“讲source object与null做比较的地方”。修改这些地方，使它们调用IsNull()函数。
你可以在不该在出现null value的地方放上一些断言，确保null的确不再出现。这可能对你有所帮助。
这出这样的程序点：如果对象不是null，做A动作，否则做B动作。
对于每一个上述地点，在null class中覆写A动作，使其行为和B动作相同。
使用上述的被覆写动作(A)，然后删除“对象是否等于null”的条件测试。编译并测试。
其他特殊情况
使用本项重构时，你可以有数种不同的null objects，例如你可以说“没有顾客”和“不知名顾客”这两种情况是不同的。果真如此，你可以针对不同的情况建立不同的null class。有时候null objects 也可以携带数据，例如不知名顾客的使用记录等等。
本质上讲，这是一个比Null Object模式更大的模式：Special Case模式。所谓Special case class是某个class的特殊情况，有着特殊的行为。因此表述不知名顾客的UnKnownCustomer 和表示没有顾客的NoCustomer都是Customer的特例。你经常可以在表示数量的class中看到这样的特例类。例如Java浮点数有“正无穷大”、“负无穷大”和“非数量”等特例。special case class的价值是：它们可以降低你的错误处理开销。例如浮点运算决不会抛出异常。如果你对NaN作浮点运算，结果也会是个NaN。这和“null object”的访问函数通常会返回另一个null object是一样的道理。

littlegai 2007-07-17 21:26 发表评论

The C++ Standard Library : A Tutoral and Reference 读书笔记之auto_ptr

littlegai — Thu, 12 Jul 2007 14:46:00 GMT

        这一部分会将要讨论一下auto_ptr.c++标准库提供auto_ptr作为一种智能指针,有了这种智能指针,就可以在异常被抛出的时候避免资源的泄漏.注意,auto_ptr只是智能指针的一种.因为事实上有多种智能指针存在.而auto_ptr只是被用来满足某种情形下的需求的.而对于其他一些情形,auto_ptr无能为力.所以在使用的时候要格外注意.
        auto_ptr的动机
        通常,一个函数会按照下面的流程进行操作:
        1.获取资源.
        2.进行一些操作.
        3.释放之前所获取的资源.
        如果函数所获取的那些资源与本地对象绑定,它们就会在函数结束的时候被自动释放掉.因为本地对象的析构函数会被调用.但是如果资源被显式获取,并且没有与任何对象绑定,它们必须也被显式的释放掉.在使用指针的时候,资源通常是被显式管理的.
        一种典型的像上面这样使用资源的方式就是使用new来创建和用delete来释放.
        但是作释放用的delete操作往往被忽略(特别是函数有返回值的时候).当然,出现异常的时候,也同样会发生这种风险.因为异常有可能马上停止你函数的执行,而不去进行delete释放.结果就是内存泄漏,或者说得宽泛一些,是"资源泄漏".为了避免资源泄漏,通常需要函数能够捕获所有的异常.随之而来的就是,代码变得越来越复杂,冗长.
        伴随着这种情况的发生,一种智能指针auto_ptr出现了.在任何时候,一旦指针本身被销毁,它所指向的数据也会被销毁.此外,因为智能指针是一个本地变量,不管函数到底是因为正常结束,还是因为非正常结束,auto_ptr所指向的数据都会被销毁.
        有了auto_ptr,delete语句和catch语句就变得不那么必要了.auto_ptr和普通指针的使用方式基本相同,即用样用"*"表示它所指向的对象,同样用"->"来访问所指向对象的成员方法.但是有关指针的运算(比如指针的自加)不被支持(这也许是一个优点,因为指针运算也许会造成一些麻烦).
        注意auto_ptr<>不允许你使用指派的方式来声明它所指向的对象,比如:
        下面的操作是不允许的:
        std::auto_ptr ptr2 = new ClassA; //ERROR
        而应该采用显式的构造函数来初始化:
        std::auto_ptr ptr1(new ClassA); //OK
        通过auto_ptr来转换所有权
        auto_ptr在语意上提供了对于所有全的严格约束.这意味着因为如果一个auto_ptr删除了它所指向的对象,那么这个对象将不会被其他任何对象所拥有.两个或以上的auto_ptr绝不能同时拥有一个对象.不幸的是,这种情况是有可能出现的.所以只能有程序员来确保这种情况不会发生.
        那么在这种情况下,auto_ptr的拷贝构造函数如何工作呢?通常它会把一个对象的数据复制给另外一个对象,但是在这里,恰恰是这种行为会导致两个auto_ptr拥有相同对象这种情况的出现.解决方法很简单,但是却得出了一个重要结论:auto_ptr的拷贝构造函数和指派操作促成了auto_ptr对于对象所有权的一次移交.
        看一下下面的代码:
        //initialize an auto_ptr with a new object
        std::auto_ptr ptr1(new ClassA);
        //copy the auto_ptr
        //- transfers ownership from ptr1 to ptr2
        std::auto_ptr ptr2(ptr1);
        第一句中,ptr1拥有new所创建的那个对象.然后第二句把对于对象的所有权从ptr1转移给了ptr2.所以在第二句之后,ptr2拥有new创建的那个对象的所有权,而ptr1则自动失去了对于那个对象的所有权.ClassA只会在ptr2被析构的时候被释放掉.
        同样,对于一次指派操作也是如此.如下所示:
        //initialize an auto_ptr with a new object
        std::auto_ptr ptr1(new ClassA);
        std::auto_ptr ptr2; //create another auto_ptr
        ptr2 = ptr1;        //assign the auto_ptr
                      //- transfers ownership from ptr1 to ptr2
        注意,随着所有权的移交,之前失去对象所有权的那个auto_ptr就变成了一个空指针.
        当然,还可以让这个失去所指的空指针重新指向一个对象,像下面这样:
        std::auto_ptr ptr;               //create an auto_ptr
        ptr = std::auto_ptr(new ClassA); //OK, delete old object and own new
        对于所指向的对象的所有权的变换为我们提供了auto_ptr的一种潜在用法.函数可以使用向其他的函数传递所有权.这包含两种情况.
        1.传入函数的对象不再使用.即在auto_ptr作为参数传递的时候.在这种情况下,被调用的函数得到了传入的auto_ptr所指向的那个对象的所有权.因此,如果函数不再将对象的所有权转移出来,那么对象就会在函数的调用结束之后销毁.
         2.函数要向外传出对象.当auto_ptr被返回的时候,所有权由被调用的函数转移给调用方.
         由于auto_ptr总是牵扯到对象所有权变换的问题,所以在使用的时候一定要注意你是否真的要转换这个所有权.
         你可能打算通过引用传递auto_ptr(s).但是这样做有可能最终你都不清楚所有权的归属了.总之,这不是一个好的决定或设计.
        从auto_ptr的概念出发,你可能会觉得即使是传递常指针的话,对象的归属也会改变.如果这种情况可能发生,那将是非常危险的.因为人们总是不期待一个成为"常量"的东西发生改变.幸运的是,通过一些技术上的处理,这样做是不可能的.如:

1 #include<iostream>
2 using namespace std;
3 int getValue(auto_ptr<int>);
4 int main()
5 {
6     const auto_ptr<int> myAutoPtr=auto_ptr<int>(new int);
7     *myAutoPtr=10;
8     cout<<getValue(myAutoPtr)<<endl;
9
10 }
11 int getValue(auto_ptr<int> ptr)
12 {
13     return 10*(*ptr);
14 }

       上面首先定义了常量的auto_ptr,这就表明,这个auto_ptr不能将自己所指对象的所有权传递给其他对象.因而调用函数getValue的时候如果传递了上面定义的auto_ptr,就会被编译器发现,并作为编译错误反馈回来:
错误： passing ‘const std::auto_ptr’ as ‘this’ argument of ‘std::auto_ptr<_Tp>::operator std::auto_ptr_ref<_Tp1>() [with _Tp1 = int, _Tp = int]’ discards qualifiers
将auto_ptr(s)作为成员变量
当然,如果在类中使用auto_ptr的时候,你同样也可以避免资源泄漏这种问题的发生.如果你使用auto_ptr取代通常的指针的话,你将不再需要对那些对象进行手动的析构处理.同时,auto_ptr也能够有效避免因为初始化异常而导致资源泄漏这种情况的发生.因为析构总是在构造之后,所以如果在构造的时候发生异常,你往往不能够及时释放资源,进而导致资源泄漏情况的发生.
        但是,在享用了auto_ptr带来的诸多好处的同时,你在处理拷贝构造函数和重载赋值操作的时候,要格外注意auto_ptr所有权变换的问题.当然,避免这类问题的最好方法就是使用常量指针.
        有关auto_ptr(s)的滥用
        auto_ptr能够满足一些需要,特别是容易发生资源泄漏的时候,它总能够发挥好的效果.但是在使用它的时候仍然需要注意,不要滥用.在使用的时候,要注意以下几点:
        1.auto_ptr(s)不能够共享对于所指向对象的所有权.
        2auto_ptr(s)不提供对于数组的支持.因为在释放资源的时候,auto_ptr使用的是delete而不是delete[].当然,对于数组而言,STL也有相应的处理办法,比如容器.
        3.auto_ptr(s)不是智能指针的全部.注意它并不能解决一切问题.注意它的应用场景.
        4.auto_ptr(s)不能满足容器中对象的操作要求.

littlegai 2007-07-12 22:46 发表评论

重构--改善既有代码的设计读书笔记第三章(4)

littlegai — Tue, 10 Jul 2007 14:16:00 GMT

现在回到重构--改善既有代码的设计这本书。
3.4Long Parameter List（过长参数列）
如果“向既有对象发出一条请求”就可以取得原本位于参数列上的一份数据，那么你应该激活重构准则Replace Parameter with Method。上述的既有对象可能是函数所属class内的一个值域，也可能是另一个参数。你还可以用 Preserve Whole Object将来自同一对象的一堆数据收藏起来，并以该对象替换它们。如果某些数据缺乏合理的对象归属，可使用Introduce Parameter Object为它们制造出一个“参数对象”。

Replace Parameter with Methods(以函数取代参数)
对象调用某个函数，并将结果作为参数，传递给另外一个函数。而接受该参数的函数也可以（也有能力）调用前一个函数。
动机
如果函数可以通过其它途径（而非参数列）获得参数值，那么它就不应该通过参数取得该值。
缩减参数列的办法之一就是，看看“参数接受端”是否可以通过“与调用端相同的计算”来取得参数携带值。如果调用端通过“其所属对象内部的另一个函数”来计算参数，并在计算过程中“未曾饮用调用端的其它参数”，那么你就应该将这个计算过程转移到被调用端内，从而除去该项参数。如果你所调用的函数隶属另一对象，而该对象拥有一个reference指向调用端所属对象，前面所说的这些也同样适用。
作法
1、如果有必要，将参数的计算过程提炼到一个独立函数中。
2、将函数本体内“对该参数的引用”替换为对“新函数的引用”。
3、每次替换后，修改并测试。
4、全部替换完成后，适用Remove Parameter将该参数去掉。

思考：
确实从实践角度讲，上面这种方法是一种很实用的重构方法。确实是缩减了函数的参数个数，并隐藏了一些中间结果。但是我认为，在应用这个方法的时候，还应当考虑这样两个问题：
1、当中间函数（方法）被隐藏的时候，以这个中间函数的返回值为参数的那个函数名还能够表述自己的用途吗？
2、被修改的那个函数所处的具体语境是什么。因为在面向对象编程的时代，单独去考虑一个函数的情况是很少的。确保这个函数是否处在正确的位置上（如是否处在正确的类中）是必要的。

此间存在一个重要的例外。有时候你明显不希望造成“被调用之对象”与“较大对象”间的某种依存关系。这时候将数据从对象拆解出来单独作为参数，也很合情合理。但是请注意其所引发的代价。如果参数列太长或变化太频繁，你就需要重新考虑自己的依存结构了。

Introduce Parameter Object（引入参数对象）
某些参数总是很自然的同时出现，以一个对象取代这些参数。
你常会看到特定的一组参数总是一起被传递。可能有好几个函数都使用这一组参数，这些函数可能隶属同一个class，也可能隶属不同的classes。这样一组参数就是所谓的Data Clump(数据泥团)。我们可以运用一个对象包装所有这些数据，再以该对象取代它们。
作法：
1、新建一个class，用以表现你想替换的一组参数。将这个class设为不可变的(不可被修改的，immutable)。
2、编译。
3、针对使用该组参数的所有函数，实施Add Parameter，以上述新建class之实体对象作为新添参数，并将此一参数值设为null。
4、对于Data Clump(数据泥团)中的每一项(在此均为参数)，从函数签名式中移除之，并修改调用端和函数本体，令他们都改而通过“新建的参数对象” 取得该值。
5、每除去一个参数，编译并测试。
6、将原先的参数全部除去之后，观察有无适当函数可以运用Move Method搬移到参数对象中。

思考：
现在我有一个函数f，函数定义如下：
public string f(int i,int j,string s)
{
   int newValue=i+j;
   string result=s+":"+newValue.ToString();
   return result;
}
现在我把这三个参数转化为类对象，类名定义为MyParameter

public class MyParameter
    {
        int _i;

        public int I
        {
            get { return _i; }
            set { _i = value; }
        }
        int _j;

        public int J
        {
            get { return _j; }
            set { _j = value; }
        }
        string _s;

        public string S
        {
            get { return _s; }
            set { _s = value; }
        }
        public MyParameter(int i, int j, stirng s)
        {
            _i = i;
            _j = j;
            _s = s;
        }

    }

然后再我的代码中这样写：
f(new MyParameter(3,2,"Result"));

发现什么问题了吗？
1、好像参数并没有减少，只不过是移动到了构造函数中；
2、你从f参数中将会看不出f中到底需要什么东西（如果参数名称体现了参数的用途的话）。
这说明：
1、虽然这是经典的重构方法，但是不能滥用，在使用的时候要谨慎考虑场景是否合适。
2、注意TDA原理，不要刻意产生太多的中间对象。
3、参数不能随便合并或隐去，要特别注意领域模型，要切合领域模型所表述的意图。
我个人认为可以应用的场景：
就是文中所说的DataRange，即适合于被转换为参数对象的参数列具有通用的含义，并且概念层次比较低。

littlegai 2007-07-10 22:16 发表评论

重构--改善既有代码的设计读书笔记第三章(3)

littlegai — Sun, 08 Jul 2007 12:31:00 GMT

其实在看Martin Fowler的重构这本书的很长一段时间里，我一直把它错当成了另外一本书的中文版，那本书的名字就是：John.Wiley.and.Sons.Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully.Jun.2006
以前曾经看过这本书，目前还没有找到中文版。相对于《重构--改善既有代码的设计》的侧重实践来说，上面这本书理论性更强一些。看讲实践的书有个缺点，就是你看了不上手做一做的话，等于白看，而理论呢，你可以记住。所以下面穿插一些《Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully》的理论，有很多通过英文字面意思很难理解，这样我会在网上找些资料，然后抄记在下面：
设计原理
正如代码会“有味”一样，结构也会“有味”，他们通常会由对于设计原理的违反而引起。因此设计原理会为我们提供一些有价值的东西进而帮助我们为设计去去狐臭。在我们从设计中找出违反这些设计原理的地方的同时,我们也有了自己的想法来改善我们的设计。。下表列出了当前流行的设计原理：

1、DRY(Don't Repeat Yourself)：不要写重复的代码。也可以叫做“一次且仅一次(Once and Only Once)”原理。
2、SCP(Speaking Code Principle)：代码应该清楚地表明它自己的意图。代码中出现注释，说明代码不能清楚地表现自己的意图。
3、OCP(Open Closed Principle)：一个设计单元应该向修改开放。这种修改不应该导致调用方无效。继承是一种能够让你达到此目的的方法。子类可以进行一些调整，而超类保持不变。
4、LSP(Liskov Substitution Principle)：个软件实体如果使用的是一个基类的话，那么一定适用于其子类，而且它根本不能察觉出基类对象和子类对象的区别。反过来代换是不成立的
5、DIP(Dependency Inversion Principle)：等级高的概念不应该依赖于等级低的概念（或实现）。对于从属关系来说刚好相反。因为等级高的概念比起等级低的概念来说变动的可能性要小。
6、ISP(Interface Segregation Principle)：接口隔离原理。接口应该尽量的小。他们应该仅包含很少的方法，但是这些被放置在同一个接口中的方法应该是紧密相关的。
7、REP(Reuse/Release Equivalency Principle)：可重用的元素必然是已经被发布的元素。

8、CRP(Common Closure Principle)：包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该报的所有类产生影响。而对其他的包不构成任何影响。
9、ADP（Acyclic（无环的）Dependencies Principle）：包之间的依赖关系应当是无环的。
10、SDP(Stable Dependencies Principle)：一个包应该依赖于至少像它自己那样稳定的包。
11、SAP（Stable Abstractions Principle）：越稳定的包，其抽象程度越高。不稳定的包通常是具体化的包。
12、TDA（Tell,Don't Ask）：不要向一个对象去申请另外一个对象，而应该告诉这个对象应该如何去做。
13、SOC(Separation Of Concerns)：不要在一个类中包含多个关注点。这通常也被叫做“责任单一原理”。
类关系图中的“狐臭”
两个或多个类之间的关系通常包含“使用”和“继承”两种。如果我们想在一个系统中找出“使用”关系，我们应该看一下“静态”关系图。在系统运行时呈现出来的“使用”关系构成了对象之间的动态关系图。
一、无用类

出自Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully
那些不再使用的类会因为具有一些显而易见的无用功能而增加系统的负担。这些负担包括：程序开发者需要花费大量的时间来分辨出一个正确的类，构建系统的时间变得更长，系统变得更加难以理解。
相对于完全无用的类，更多的情况下你会遇到包含部分无用代码的类。这是因为一个类中包含了太多的功能，而在真正使用的时候，那些功能又被抛弃掉了。我们可以在重构的时候依据这些功能把类进行拆分，通过拆分我们会首先得到无用类。然后进一步对它进行处理。
不仅仅单单一个类会成为无用类，有的时候，处在同一个关系图中的类都回成为无用类(s)。
无用类通常因为两种原因而出现：
１、技术上提供覆盖面尽可能广的支持：一个开发者推测一个类可能最终会被用到，即使没有迹象表明现实中有与之对应的需求。
２、重构：通过对系统的修改，以前需要用到的类，现在变得陈旧过期了。
二、树型依赖关系

出自Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully
树型依赖关系图体现了对于系统的一种分解。树中的每一个类都确定的被另外一个类使用。
鉴于在面向对象的应用程序中，功能分解本身通常会被看作是一种“狐臭”，一种树型依赖结构像重复代码一样也应该被看作是一种“狐臭”。在图3-6中，类Protocol除了被类Data Storage使用外，不再被别的地方使用。重用没有发生。
三、静态环状依赖关系

出自Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully
两个类彼此使用对方是最简单的环状依赖关系。环状依赖关系中也可以包含多个类。
环状依赖关系会使环本身变得更加臃肿。环所具有的消极影响包括：
a、不可理解性：这些类不能够被一个又一个的单独理解，因为它们彼此依靠对方来实现功能。又或者是，一个类需要从多个类中选择一个作为理解他们本身的前提。
b、可维护性：环状依赖可能包含严重的并且不可预测的递推关系，进而导致修改包含它的系统变得非常困难。
c、可计划性：对环的修改到底会造成什么影响是很难预期的。估算到底需要多少的工作来完成这个修改会是一件很困难的事。
d、设计的清洁性：因为处在环中的那些类会直接或间接的访问到处在环中的任意一个类，因此，从理论上讲，类中的这种关系太随意了。如果在这个环中又恰好把一个方法放到错误的类中，会导致理解这种设计变得更加困难。
e、重用性：这些类必须同时重用。如果在一个给定的语境中，只有其中的一个类所提供的功能被关注，因为处在环中，这个类不能被简单的剥离并使用。
f、可测试性：这些类必须一起被测试。这增加了测试的要求以及堪错的难度。如果想要独立的测试其中的一个类，就必须使用“伪对象”。
g、异常处理：通常异常会在环中被“堆积”。如果环中的一个方法抛出了异常，他会潜在得影响环中的其他方法。
h、依赖引入问题：每一个处于环中的类同时又依赖于另一个处于环中的类处在环外的依赖关系。
显然，环中的最大长度越大，代码的“狐臭”味就越浓。然而，在有些地方，只包含两个类的环却是一种被推崇的设计方案，被应用于很多设计模式中（如迭代器模式）。
四、显式依赖
面向对象支持封装原理以及信息隐藏原理：内部的实现被隐藏于接口之中。客户端的代码无须知道任何有关于API的实现。另外，接口与实现类之间存在一些“裂痕”。很多开发者相信封装和信息隐藏只会在成员变量被定义为“私有”的时候才会有效。这当然不是事实：在很多系统中都是支持“属性”的，并且属性可以被继承。然而，有这样一个事实，在一个系统中，显式依赖关系却是无法隐藏的。一个具有公共依赖关系的系统在被修改的时候，总会产生这样那样的问题，反之，私有的局部的依赖关系只会有小范围的影响。
TDA(Tell,don't ask)原理指出了一条正确的途径：理想情况下，客户端告诉对象自己打算做什么。既不要通过已有对象获取一个新的对象，更不要用那个新的对象进行一些操作。
下面看一个例子。在这个例子中，“订单”有很多的状态。我们可以简单的以打开的订单和关闭的订单来简单的区分一下。打开的订单就是客户未回款的订单。现在我们要写一些代码，来计算所有打开的订单的总额。
如果我们使用一个方法calculateValueOpenOrders(注意，这个方法是写在调用方的，我们的调用方的类名定为Foo），而方法体如下。可以看出这个方法违反了TDA原理：

public float calculateValueOpenOrders(ListOfOrders orders)
{
    float totalValue = 0.0f;
    for (int i=0; i<orders.getNumber(); i++)
    {
        Order a = orders.getOrder(i);
        if (a.isOpen)
        {
            totalValue += a.getValue();
        }
    }
    return totalValue;
}

原因就是客户端的Foo直接使用Orders来获取其中的一些信息，而不是告诉Orders我要做什么。

出自Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully
现在我们做一下修改，把打开的订单的金额计算移动到订单内部进行。如果订单是打开的，返回本订单的金额，反之，返回0。

public class ListOfOrders
{
    public float calculateValueOpenOrders()
    {
        float totalValue = 0.0f;
        for (int i=0; i<getNumber(); i++)
        {
            Order a = getOrder(i);
            totalValue += a.getOpenValue();
        }
        return totalValue;
    }
}

public class Order
{
    public float getOpenValue()
    {
        if (isOpen())
        {
            return getValue();
        }
        else
        {
            return 0;
        }
    }
}

我们可能会因为所有Order都要返回打开的订单的金额而感觉不爽。如果你打算多次使用TDA原理，你可能通过增加一个方法“addOpenValue”来增加类order的柔性。但是，同时这也意味着类Order会知道另外的一些Order的存在。在这种情况下，我们可能会违反SOC（即单一职责原理）。我们不应该忽略这样一点：在使用一些设计原理的时候，还要兼顾系统的平衡性。在这个例子中，这个方法是否应该加入取决于它是否真的与这个类的“领域模型”所匹配。
新的实现方式不仅仅使代码更加简短，而且还包括如下的优点：
功能有了正确的归属。在大多数情况下，上面第一段代码中的方法calculateValueOpenOrders通常是被放到UI类中或者是一些Helper类中，而这些类通常有一些奇异的名字（比如OpenOrders Calculator）。这对于这个方法来说，不是一个正确的归属。
TDA原理确保类的使用应该局部化，而不要散步到系统的各个角落。因此可以简化一些优化方案的实现。

littlegai 2007-07-08 20:31 发表评论

The C++ Standard Library : A Tutoral and Reference 读书笔记之错误和异常处理

littlegai — Tue, 26 Jun 2007 14:18:00 GMT

;C++标准库风格迥异.它包含了设计和实现风格各不相同的不同来源的软件.错误处理和异常处理是一个典型.标准库中的string类们支持更加细化的错误处理.它们会监测每一处有可能发生问题的地方并会在有错误的时候抛出异常.另外一些,比如STL和valarrays比较安全性而言更加注重效率.所以它们很少监测逻辑错误,并仅仅在运行时错误发生的时候才抛出异常.
有三种标准异常类:
1.语言支持型异常(Exceptions for language support )
比如:
用new创建对象失败的时候,会抛出bad_alloc异常;
dynamic_cast失败会抛出bad_cast异常;
函数抛出不可控异常的时候会抛出bad_exception异常或调用unexpected函数.

#include <iostream>
class E1
{

};
class E2
{
};
void f_throwE1() throw(E1)
{
    throw E1();
}
void f_throwE2() throw(E1)
{
    throw E2();
}
void f_throwE2AsBadException() throw (E1,std::bad_exception)
{
    throw E2();
}
int main()
{
    try
    {

        f_throwE1(); //1:抛出可控异常
        f_throwE2(); //2:抛出不可控异常,执行unexpected函数
        f_throwE2AsBadException(); //3:抛出不可控异常,被认为是bad_exception
    }
    catch(const E1 &e1)
    {
        std::cout<<"E1 error occured"<<std::endl;
    }
    catch(const std::bad_exception &e2)
    {
        std::cout<<"bad_exception occured"<<std::endl;
    }
    catch(const E2 &e2)
   {
       std::cout<<"E2 error occured"<   }
   catch(...)
   {
       std::cout<<"unknown exception occured"<   }
}

上面的程序中,执行1,会产生如下的结果:
E1 error occured
执行2,并没有被作为类型E2的异常所捕获.而是出现了如下提示:
terminate called after throwing an instance of 'E2'
忽略
现在执行3.结果并没有捕获到std::bad_exception异常.而是仍然出现了这样的错误提示:
terminate called after throwing an instance of 'E2'
忽略
同样的的例子,上面是在linux下执行的情况.下面换做vs2003的vc7.执行3,结果是:
unknown exception occured
即也没有捕获到std::bad_exception,但是被更加通用的...所捕获了.这是编译器情况的不同.
2.c++标准库的异常(Exceptions for the C++ standard library)
c++标准库的异常类通常从logic_error类继承.逻辑错误从理论上来说,至少应该被程序所避免,例如通过对于函数参数进行额外的测试.c++提供了诸如invalid_argument,length error,out_of_range,domain_error等异常类.
3.在程序域之外的异常(Exceptions for errors outside the scope of a program)
此类异常通常难于避免.
异常类的头文件
异常的基类和bad_exception类被定义在里;
类bad_alloc在中被声明;
bad_cast和bad_typeid在中被声明;
ios_base::failure在中被声明;
所有其他的类都被定义在中.
异常类的成员
在异常类中除类型信息之外,唯一可以获取的信息来自于函数what():
namespace std {
    class exception {
      public:
            virtual const char* what() const throw();
            ...
      };
}

使用what来获取信息:
try {
    ...
}
catch (const exception& error) {
    //print implementation-defined error message
    cerr << error.what() << endl;
    ...
}
可以以下面的方式创建标准异常:
string s;
...
throw out_of_range(s);

或者
throw out_of_range("out_of_range exception (somewhere, somehow)");
从标准异常类继承
例如:

#include <exception>
#include <iostream>
class MyException:public std::exception
{
private:
    char* errorMessage;
public:
    MyException(const char* errMsg)
    {
        errorMessage=new char[strlen(errMsg)];
        strcpy(errorMessage,errMsg);
    }
    ~MyException() throw()
    {
        if(errorMessage)
        {
            delete[] errorMessage;
            errorMessage=NULL;
        }
    }
    virtual const char* what() const throw()
    {
        return errorMessage;
    }

};
int main()
{
    try
    {
        throw MyException("Error Occured!!");
    }
    catch(const std::exception &e)
    {
        std::cout<<e.what()<<std::endl;
    }

}

littlegai 2007-06-26 22:18 发表评论

The C++ Standard Library : A Tutoral and Reference 读书笔记之命名空间(2)

littlegai — Mon, 25 Jun 2007 13:18:00 GMT

命名空间是为了应对命名冲突这种情况的出现而产生的 .命名空间是可扩展的.你可以使用相同的命名空间来定义你的那些在物理上处于不同位置的组件.一个典型的例子就是namespace std.
你可以有三种选择来使用std命名空间.
1.使用std::作为前缀.
如:
std::cout << std::hex << 3.4 << std::endl;
2.使用using 进行预定义
using std::cout;
using std::endl;
然后这样使用:
cout << std::hex << 3.4 << endl;
3.直接使用using.
using namespace std;
cout << hex << 3.4 << endl;
不要在代码上下文不明确的地方使用这种用法( 如头文件中).
c++标准中对于头文件引入使用了一种新的写法,如:
#include
这实际上是引入了c++的标准模板库的iostream.h文件.
而对于旧的c语言的头文件,可以使用这种方式引入:
#include //相当于
#include //相当于
有意思的是,如果在引入头文件的时候这样写,可以把c风格的函数加上std命名空间来使用.
如:

#include <cstring>
#include<cstdio>
int main()
{
std::printf("%d",std::strlen("hello world!"));
}

当然,仍然可采用兼容于c风格的头文件引入方式:
#include

littlegai 2007-06-25 21:18 发表评论

重构--改善既有代码的设计读书笔记第二章(3)

littlegai — Sun, 24 Jun 2007 13:35:00 GMT

难以通过重构手法完成的设计改动
比如说在一个项目中，我们很难（但还是有可能）将“无安全需求情况下构造起来的系统”重构为“安全性良好的系统”。
这种情况下我的办法就是“先想象重构的情况”。考虑候选设计方案时，我会问自己：将某个设计重构为另一个设计的难度有多大？如果看上去很简单，我就不用担心选择是否得当，于是我就会选择最简单的设计，哪怕它不能覆盖所有潜在需求也没关系。但如果预先看不出简单的重构办法，我就会在设计上投入更多力气。
何时不该重构？
重写（而非重构）的一个清楚的讯号就是：现有代码根本不能正常工作。你可能只是试着做点测试，然后就发现代码中满是错误，根本无法稳定运作。记住，重构之前，代码必须起码能够在大部分情况下正常运作。
另外，如果项目自己已近最后期限，你也应该避免重构。在此时机，从重构过程中赢得的生产力只有在最后期限过后才能体现出来，而那个时候已经时不我予。
Wrad Cunningharn的看法：未完成的重构工作是“债务”。过于复杂的代码所造成的维护和扩展的额外开销，就是利息。你可以承受一定程度的利息，但如果利息太高你就会被压垮。把债务管理好是很重要的，你应该通过重构来偿还部分债务。
重构与设计
Alistair Cockburn：有了设计，我可以思考更快，但是其中充满小漏洞。
有一种观点认为：重构可以成为“预先设计”的替代品。这意思是你根本不必做任何设计，只管按照最初想法开始编码，让代码有效运作，然后再将它重构成型。极限编程的支持者极力提倡这种办法。
但这不是最有效的途径。极限编程的爱好者们也会进行预先设计。他们会使用CRC卡或类似的东西来检验各种不同的想法，然后才得到第一个可被接受的解决方案，然后才开始编码，然后才能重构。关键在于：重构改变了“预先设计”的角色。如果没有重构，就必须保证“预先设计”的正确无误，这个压力太大了。

什么是CRC卡?
CRC(Class-Responsibility-Collaborator)卡建模是一种简单且有效的面向对象的分析技术。在一个OO(面向对象)开发项目中，包括用户、分析员和开发者在建模和设计过程中经常应用CRC卡建模，使整个开发团队普遍的理解形成一致。
它由三部分组成：
1. 类(Class)
2. 职责(Responsibility)
3. 协作(Collaborator)
一个类代表许多类似的对象。而对象是系统模型化中关注的事物。他们可以是一个人、地方、事情、或任何对系统有重要性的概念。类名在CRC卡的顶部。
职责是类需要知道或做的任何事物。这些职责是类自身所知的知识，或类在执行时所知的知识。
协作是指为获取消息，或协助执行活动的其他类。在特定情形下，与指定的类按一个设想共同完成一个(或许多)步骤。协作的类顺着CRC卡的右边排列。

(上图出自http://book.csdn.net/bookfiles/116/1001163602.shtml)

在可以重构的前提下，你只需要得到一个足够合理的解决方案就够了。
如果你在预先设计时在所有有可能出现变化的地方都建立起灵活性，却在最后发现这些灵活性都毫无必要，这才是最大的失败。你知道，这其中肯定有些灵活性的确派不上用场，但你却无法预测到底哪些派不上用场。
而有了重构，则只需要考虑：把一个简单的解决方案重构成这个灵活的解决方案有多大难度？如果答案是“相当容易”，那么你就只需实现目前的简单方案就可以了。
重构与性能
虽然重构必然会使软件运行更慢，但它也使软件的性能优化更易进行。除了对性能有严格要求的实时系统，其他任

何情况下“编写快速软件”的秘密就是：首先写出可调软件，然后调整它以求获得足够速度。
编写快速软件的方法：
1、时间预算法。
为每个组件分配资源（包括时间资源和执行轨迹）；每个组件绝对不能超过自己的预算，就算拥有“可在不同组件之间调度预配时间”的机制也不行。例如心律调节器，在这样的系统中，迟来的数据就是错误的数据。
2、持续关切法。
要求程序员在任何时间做任何事时，都要设法保持系统的高性能。
这种方式通常不会起太大作用。任何修改如果为了提高性能，通常会使程序难以维护，因而减缓开发速度。性能一旦被分散到程序各个角落，每次改善都只不过是从“对程序行为的一个狭隘视角”出发而已。
3、利用90%统计数据
90%的优化都是白费劲，因为难得被执行。
所以以一种“良好的分解方式”来建造自己的程序，不对性能投以任何关切，直至进入性能优化阶段。
优化的过程：测量-->优化-->编译-->测试-->再次测量.
使用性能热点测量工具“发现热点、去除热点”，直到获得客户满意的性能。
McConnell提供了关于这项技术的更多信息。

很想了解相关技术,但是没有找到具体资料.倒是有两个开源项目

p-unit和junitperf
http://www.javapronews.com/javapronews-47-20030721ContinuousPerformanceTestingwithJUnitPerf.html

littlegai 2007-06-24 21:35 发表评论

The C++ Standard Library : A Tutoral and Reference 读书笔记之第二章扫尾

littlegai — Wed, 20 Jun 2007 14:50:00 GMT

静态常量的初始化
书中说:现在可以在类结构中初始化整型的静态成员了(难道以前不可以?).我想书中大概是这个意思:

class MyClass
{
public:
static const int num=100;
int values[num];
};
int main()
{
std::cout<<MyClass::num;
}

main的声明
在c++标准中只有两种main函数的写法会被接受:

int main()
{

}

int main (int argc, char* argv[])
{

}

与C语言不同,C++在main中没有返回值的情况下,会隐式的返回0.但这种情况,编译器在编译的时候,会给你警告.
复杂度问题和大写的O标志
大写的O标志是用来考量一个算法的时间复杂度的.如果运算的时间与运算元素的个数接近于正比,那么时间复杂度就是O(n).当然除此之外,还有幂级的时间复杂度.这里强调的是,c++ 中的数学库中一些算法的实现都仔细考虑了时间复杂度的问题.

littlegai 2007-06-20 22:50 发表评论

重构--改善既有代码的设计读书笔记第一章(2)

littlegai — Wed, 20 Jun 2007 13:42:00 GMT

运用多态(polymorphism)取代与价格相关的条件逻辑
在另一个对象的属性基础上运行switch语句，并不是什么好主意。如果不得不使用，也应该在对象自己的数据上而不是在别人的数据上使用。选择对象之间的传递关系的时候，应当考虑选择将稳定的对象的属性传递给易变的对象（如书中的将租期长度来自Rental（稳定，不易变）传递给Movie（不稳定，易变））。
对于类A和类B，如果A中存在因B而变化的属性或方法体，则将它们移动到B中，A中只保留移动后B暴露给A的接口（或方法）。
终于.......我们来到继承(inheritance)
此部分包含的重构方法：
Self Encapsulate Field：自封装域。
Move Method：移动方法。
Replace Conditional with Polymorphism：用多态替换条件选择。
Replace Type Code with State/Strategy：在这个方法中使用了上面三个方法作为步骤。即用状态、策略替换代码，将与类型相依的行为搬移到模式内。在使用它的时候，多使用对于以类型相依的行为进行Self Encapsulate Field作为第一步骤。从而确保任何时候都通过getter和setter两个函数来运行这些行为。第二步通常采用Move Method方法，即把代码从超类的宿主中搬移到子类中去。第三步采用Replace Conditional with Polymorphism方法，将switch，if等条件分支语句转变为多态形式。
下面是一个小实验：
一、重构之前的代码：

public class ClassA {
    public int getValue(TheType type)
    {
        switch(type)
        {
        case SmallValue:return 100;
        case MidValue:return 200;
        case BigValue:return 300;
        default:return 0;

        }
    }

    public static void main(String args[])
    {
        ClassA instanceA=new ClassA();
        System.out.println("theValueIs:"+instanceA.getValue(TheType.SmallValue));
    }
}

应用Self Encapsulate Field之后的效果：

public class ClassAModified {

    /**
     * @param args
     */
    public TheValue _theValue;
    public int getValue(TheType type)
    {
        switch(type)
        {
        case SmallValue:return 100;
        case MidValue:return 200;
        case BigValue:return 300;
        default:return 0;

        }
    }


    public TheValue get_theValue() {
        return _theValue;
    }

    public void set_theValue(TheType type) {
            }

}
public class TheValue
    {

    }

应用Move Method之后的效果：

public class ClassAModified {

    /**
     * @param args
     */
    public TheValue _theValue;
    public int getValue(TheType type)
    {
        return _theValue.getValue(type);
    }

    public static void main(String[] args) {
        // TODO Auto-generated method stub

    }

    public TheValue get_theValue() {
        return _theValue;
    }

    public void set_theValue(TheType type) {
        _theValue=new TheValue();
    }
    public class TheValue
    {
        public int getValue(TheType type)
        {
            switch(type)
            {
            case SmallValue:return 100;
            case MidValue:return 200;
            case BigValue:return 300;
            default:return 0;

            }
        }
    }


}

应用Replace Conditional with Polymorphism之后的效果：

public class ClassAModified {

    /**
     * @param args
     */
    public TheValue _theValue;
    public int getValue(TheType type)
    {
        return _theValue.getValue();
    }

    public static void main(String[] args) {
        // TODO Auto-generated method stub

    }

    public TheValue get_theValue() {
        return _theValue;
    }

    public void set_theValue(TheType type) {
        switch(type)
        {
            case SmallValue:_theValue= new SmallValue();
            case MidValue:_theValue= new MidValue();
            case BigValue:_theValue= new BigValue();
            default:_theValue=new TheValue();

        }
    }
    public class TheValue
    {
        public int getValue()
        {
            return 0;
        }
    }
    public class SmallValue extends TheValue
    {
        public int getValue()
        {
            return 100;
        }
    }
    public class MidValue extends TheValue
    {
        public int getValue()
        {
            return 200;
        }
    }
    public class BigValue extends TheValue
    {
        public int getValue()
        {
            return 300;
        }
    }

}

结语
重构的节奏：测试、小修改、测试、小修改、测试、小修改。。。
正是这种节奏让重构得以快速而安全的前进。

littlegai 2007-06-20 21:42 发表评论

数据结构读书笔记（用栈替代递归）

littlegai — Sun, 17 Jun 2007 09:19:00 GMT

数据结构上面在讲到栈的时候，顺便提了一下递归。实际上递归就是用栈来实现的。在很多算法书上，对于一些用递归方式写成的算法，相应的也给出了栈的算法。这里我要把fibonacci数列分别用递归和栈的方式写出来，由于我以前的算法教材丢失了，而数据结构中也没有给出相应的伪码，所以只有自己从头写起了。
首先是fibonacci的递归写法（不是很标准，但是很亲切）：

int fib(int value)
{
    if(0==value)
        return 0;
    else
        if(1==value)
            return 1;
        else
        {
            return fib(value-1)+fib(value-2);
        }
}

        接下来要把这个算法转换为使用栈的写法。
        首先进行一下分析。递归是逆向求结果的，对于不能求出结果的函数，先将运行场景压栈，然后递归调用自己，如果仍然不能出结果，就再将运行场景压栈，一直到函数可以返回结果为止。此时依次将运行场景弹栈，完成运行场景，取得返回值，再弹栈......印象中的递归调用过程就是如此。如果我们要自己写递归求fibonacci数列，就要自己手动用程序来模拟这个过程。我首先准备一个栈来存放结果序列。在这个结果序列里面，保证第一个结果和第二个结果总是可以直接求得的数值。因为只需要n-1和n-2便能求出fib(n)，所以我们在算法中要把多余的n-3弹出，这样栈内的元素个数在每一次调用的过程中逐渐减少，一直到里面只剩下一个元素，在这个时候，刚才弹出的两个元素之和就是我们要求的fibonacci(n)。
        下面是算法：

int fibByStack(int value)
{
    int currentValue;
    currentValue=value;
    while(currentValue>=0)
    {
        fibStack.push(currentValue);
        currentValue--;
    }
    fibStack.pop();
    fibStack.pop();
    //1和0是n=1和n=0时的值，为了强调压入的是“结果”，我将头两个元素弹出再压入这两个值
    fibStack.push(1);
    fibStack.push(0);
    while(true)
    {
        int topValue1,topValue2
        topValue1=fibStack.top();
        fibStack.pop();
        topValue2=fibStack.top();
        fibStack.pop();
        if(1==fibStack.size())
            return topValue1+topValue2;
        fibStack.pop();
        fibStack.push(topValue1+topValue2);
        fibStack.push(topValue2);
    }
}

littlegai 2007-06-17 17:19 发表评论

The C++ Standard Library : A Tutoral and Reference 读书笔记之类型转换(1)

littlegai — Sun, 17 Jun 2007 06:56:00 GMT

在阅读类型转换之前,还是先看一下关键字explicit(显式)
书上的例子中的类名叫做Stack,这样总感觉有些误解,因为栈这个概念已经在我们的脑海中先入为主了,容易形成思维定式.那么我写一个和其他任何概念都无关的例子:

class MyClass
{
    private:
    int _number;
    public:
    MyClass(int number)
    {
        _number=number;
    }
};

上面的类很普通,没什么特别的.我们可以这样创建这个类的对象:

int main()
{
MyClass instance=5;
}

这就比较有意思了,c++还能这样写,我以前的确没有见过.那么explicit关键字的作用就是不让你这样写,如果你这样写了,编译器就会给你一个错误提示.现在改造一下MyClass

class MyClass
{
    private:
    int _number;
    public:
    explicit MyClass(int number)
    {
        _number=number;
    }
};

main函数不变的情况下,编译器会这样提示你:
Explicit.cpp: In function ‘int main()’:
Explicit.cpp:14: 错误： conversion from ‘int’ to non-scalar type ‘MyClass’ requested
这样,就只能这样写了:
MyClass instance(5);
好了,下面开始阅读类型转换的部分.
1 static_cast
这个操作符的执行过程可以被认为是:它创建了一个新的对象,然后用要转换的值去初始化这个新对象.这个转换只有当一个类型转换被声明过才能执行.
首先是一个简单的例子:

//一个简单的类型转换
   int valueToBeConverted=int();
   using namespace std;
   cout<<static_cast<float>(valueToBeConverted)<<"\n";

很像其他语言中的显式类型转换.那么对于我自己的类如何进行转换呢?可以看一下下面的这个例子:

#include <iostream>

class MyClass2
{
   public:
    int IntMember1;
   MyClass2()
   {
      IntMember1=1;
   }
};
class MyClass1
{
   public:
   int IntMember1;
   virtual void  f()
   {
       std::cout<<IntMember1<<"\n";
   }
   explicit MyClass1(MyClass2 instance)
   {
       IntMember1=instance.IntMember1;
   }
};
int main()
{
   MyClass2 mc2Instance;
   MyClass1 mc1Instance=static_cast<MyClass1>(mc2Instance);
   mc1Instance.f();
}

注意看上面的粗体字explicit.如果没有explict对于构造函数的修饰,那么万全可以简单爽快的这么写:
MyClass1 mc1Instance=mc2Instance;
换句话说,如果你想让别人写代码的时候不关心类型,舒舒服服的写出你认为不安全的代码,那么你就去掉explicit,如果你想让别人在写代码的时候,让那些不安全的类型转换变得更加"显眼"一些,那么你就按上面这样写.然后让编译器狠狠的给他们一个警告.
2 dynamic_cast
This operator enables you to downcast a polymorphic type to its real static type. This is
the only cast that is checked at runtime. Thus, you could also use it to check the type of a
polymorphic value.

这个运算符能够让你把一个多态的类型转换成它的真实的静态类型.这是唯一的在运行时进行检验的转换方法.所以你同样需要在转换之前检验多态值的类型.
首先dynamic_cast只能够用于指针或者引用.否则编译器会告诉你类似这样的错误:
无法将 ‘scInstance’ 从类型 ‘SubClass’ 动态转换到类型 ‘class BaseClass’ (target is not pointer or reference)
这里使用书中的例子:

class Car;         // 至少拥有一个抽象函数的抽象类
   class Cabriolet : public Car {

   };
   class Limousine : public Car {

   };
   void f(Car* cp)
   {
       Cabriolet* p = dynamic_cast<Cabriolet*>(cp);
       if (p == NULL) {
           //p并非Cabriollet类型

       }
   }

In this example, f() contains a special behavior for objects that have the real static type
Cabriolet. When the argument is a reference and the type conversion fails,
dynamic_cast throws a bad_cast exception (bad_cast is described on page 26).
Note that from a design point of view, it it always better to avoid such type-dependent
statements when you program with polymorphic types.
当参数是一个引用并且类型转换失败的时候,dynamic_cast会抛出一个bad_cast异常.值得注意的是,从设计的角度来说,通常在进行多态类型的程序编写时,应该避免这样的类型依赖.
3 const_cast
This operator adds or removes the constness of a type. In addition, you can remove a
volatile qualification. Any other change of the type is not allowed.
这个操作符添加或除去一个类型的常量化(特性).另外,你可以除去一个变量变化的能力.任何对于这个类型变量的变化都将不被允许.
让常量可修改的例子:

class MyClass
{
    public:
        int MemberValue;
        void showValue()
        {
            cout<<"My Value is"<<MemberValue<<"\n";
        }
        MyClass()
        {
            MemberValue=1;
        }
};
int main()
{
    const MyClass myValue;
    MyClass *ptr=const_cast<MyClass*>(&myValue);
    ptr->MemberValue=100;
    ptr->showValue();
}

上面的例子只是将一个const变得可以修改了,但是注意到书中的这样一句:
In addition, you can remove a
volatile qualification. Any other change of the type is not allowed.
似乎还可以将一个可变量转换为非可变的,这里没有查到相关资料,也许书的后面会有相应解释,所以这里先放一放.
4 reinterpret_cast
这个比较有趣,支持不兼容类型之间的转换.以下是例子:

#include <iostream>
using namespace std;
class ClassA
{
    public:
    int Value1;
    int Value2;
    int Value3;
    void showValue()
    {
        cout<<Value1<<","<<Value2<<","<<Value3<<"\n";
    }
};
class ClassB
{
    public:
    int Value1;
    int Value2;
    int Value3;
    ClassB()
    {
        Value1=1;
        Value2=2;
        Value3=3;
    }
};
int main()
{
    ClassB *b=new ClassB();
    ClassA *a=reinterpret_cast<ClassA*>(b);
    a->showValue();
}

同样,这种转换对于非基本类型来说,仍然只能支持指针和引用.
这些运算符的优点就是他们明确了类型转换的意图,并且能够让编译器获取更多的信息来了解这些类型转换的原因,然后当这些转换操作越过他们的职能的时候,编译器会报告错误.
另外需要注意的是,这些类型转换都只能接受一个参数.看下面的例子:
static_cast(15,100)
上面不会产生你想要的结果.这里的逗号并不是用来连接两个参数的,而是作为逗号运算符出现,这里15会被舍弃,而采用100作为参数构造Fraction.
所以还是需要采用下面的方法才合适:
Fraction(15,100)

littlegai 2007-06-17 14:56 发表评论

重构--改善既有代码的设计读书笔记第一章(1)

littlegai — Fri, 15 Jun 2007 14:53:00 GMT

        以前看过一点这本书的英文版本,感觉相当不错,但是由于英文水平有限,总是感觉里面有些说法对我来说比较生涩,特别还有一些理论性的东西,如果只看英文,基本上是无从查起的.好在这本书有了中文版(也许早就有了,我可是才刚刚找到),高兴之余,细细品读,写写笔记,潦记于此.
        先看看书中有关重构的定义：
        重构的定义：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。本质上说，重构就是在代码写好之后改进它的设计。
        这个定义说得很清楚了，基本上不需要进行任何的说明。我们只要将它当作原则去遵照就好了。
        然后书中讲了：
        快速而随性(quick and dirty)的设计一个简单的程序并没有错。
        于是我就有这样的问题了：
        什么规模的程序才值得重构？
        然后书中给了我这样一个回答：
        如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便的那么做，那就先重构那个程序，使特性的添加比较容易进行，然后添加特性。
        重构之前要做这样一些准备：
        重构的第一步--为代码建立测试环境。
重构之前，首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检查能力。
        下面是一些摘录：
        首先在代码中找出函数内的局部变量和参数。任何不会修改的变量都可以被当成参数传入新的函数，至于会被修改的变量就需要格外小心。如果只有一个变量会被修改，可以把它当作返回值。
在找出一个函数的逻辑泥潭并将之提练到另外一个函数中的时候，要格外注意返回值。如果你经常犯这样的错误，那么一定确保在修改前后函数的调用结果相一致。
        代码应该表现自己的目的，这一点非常重要。阅读代码的时候，我经常进行重构。这样，随着对程序的理解逐渐加深，我也就不断地把这些理解嵌入代码中，这么一来才不会遗忘我曾经理解的东西。
        几个重构的方法（下面的伪码是我自己写的）：
        1、Extract Method （提取方法）
        2、appending assignment ,operator+=（附添赋值动作）
        这两种重构方法结合的形式为：
        重构前：
        A=0;
        A++;
        if(expression)
          A++;
        重构后：
         A=0;
         A+=function1();
         TypeOfA function1()
         {
             if(expression)
               return 2;
             else
               return 1;
          }
         3、Replace Temp with Query（字面上用查询取代临时变量）
         利用所谓的query method来取代临时变量。由于class内的任何函数都可以取用（调用）所谓query methods,所以它能够促进比较干净的设计，而非冗长复杂的函数。
          Replace Temp with Query的伪码例子：
          A=0;
          while(expression)
          {
             A++;
           }
          return "The Result is "+A;
          上面A是一个临时变量.所以可以用一个querymethod来取代：
           TypeA function1()
          {
             A=0;
             while(expression)
             {
                A++;
              }
             return A;
           }
这样主程序可以这样写:
           return "The Result is "+function1();
继续摘抄：
重构可能会存在另外一个问题，就是性能。原本代码只执行一次循环，在重构以后可能要执行三次。如果循环中的语句耗时很多，就可能大大降低程序的性能。单单为了这个原因，许多程序员就不愿进行这个重构动作。但是请注意这里只是“可能”。除非进行评测，否则无法确定循环的执行时间，也无法知道这个循环是否经常使用以至于影响系统的整体性能。重构时程序人员不必担心这些，优化时才去担心它们，但那时候你已经处于一个比较有利的位置，有更多选择可以进行有效优化。
使用Form Template Method（字面上建立模板方法）可以进一步减少重复代码。这会在书后面的章节讲到。

littlegai 2007-06-15 22:53 发表评论

The C++ Standard Library : A Tutoral and Reference 读书笔记之命名空间

littlegai — Thu, 14 Jun 2007 14:06:00 GMT

在这一部分之前,书中介绍了基本类型的显式初始化以及简单的异常处理.
基本类型的显式初始化是比较简单的.就是说你在定义一个整型变量的时候,有两种不同的情况:
int i1; // undefined value
int i2 = int(); // initialized with zero

如果按照前一种,会作"值未定义;如果按照后一种,则自动被初始化为0.这样也就确保了你的类在初始化的时候有一个确定的初始值.
至于异常的处理等问题,书中会在后面有比较详细的描述.这里可以看到比较有意思的一点,就是指定函数抛出的异常类型,这于Java很像:
void f() throw(bad_alloc);
下面转入正题:命名空间.
有了命名空间,它将会取代函数和类作用于全局,并作为它所统领的那些类和函数的唯一标识存在.这样可以避免命名冲突情况的出现.正如书中所说:
Unlike classes, namespaces are open for definitions and extensions in different modules. Thus
you can use namespaces to define modules, libraries, or components even by using multiple
files. A namespace defines logical modules instead of physical modules (in UML and other
modeling notations, a module is also called a package).

可以像这样定义一个命名空间:

namespace MyNameSpace
{
    class MyClass
    {
        private:
        char * _classInfo;
        public:
        char* getClassInfo()
        {
            return _classInfo;
        }
        MyClass(const char* info)
        {
            _classInfo=new char[strlen(info)];
            strcpy(_classInfo,info);
        }
        ~MyClass()
        {
            if(_classInfo)
            {
                std::cout<<"free classinfo";
                delete[] _classInfo;
            }
        }
    };
    void printMyClassInfo(MyClass &instance)
    {
        std::cout<<instance.getClassInfo();
    }
}

从上面可以看出,这个命名空间里面包括了一个类和一个函数.类中包含了char*类型的成员变量.函数printMyClassInfo 以一个MyClass类型的引用作为参数.为什么要用引用呢?熟悉c++的人应当很清楚,我是通过实验才刚刚知道原因.这个原因我将会在后面说明.
好现在来看一下调用过程,通常的调用过程是这样的:

int main()
{
MyNameSpace::MyClass instance("MyClass!\n");
MyNameSpace::printMyClassInfo(instance);
}

这没有任何问题,但有意思的是,还可以这样调用:

int main()
{
MyNameSpace::MyClass instance("MyClass!\n");
printMyClassInfo(instance);
}

看来c++中在使用一个命名空间的类或者函数的时候,这个命名空间就被"自动"引入了.当寻找函数printMyClassInfo的时候会在当前的上下文中进行寻找的同时,还会到以前用到过的命名空间中去寻找.
当然,通常情况下我们喜欢这样做:

using namespace MyNameSpace;
int main()
{
MyClass instance("MyClass!\n");
printMyClassInfo(instance);

}

但是并不是在任何情况下都鼓励using namespace这种做法的.在书中将得比较清楚:
Note that you should never use a using directive when the context is not clear (such as in header
files, modules, or libraries). The directive might change the scope of identifiers of a namespace,
so you might get different behavior than the one expected because you included or used your
code in another module. In fact, using directives in header files is really bad design.

上面这段话强调了当上下文并不明确的情况下(比如在一个头文件,组件或者库里面),不要使用using这种写法,这个指令会改变命名空间标识符的作用域,这样你就有可能引发和你预期不相同的行为,因为你会在另外一个组件中引用你的代码或使用它.事实上,将using标识符写在头文件里面是一种相当不好的设计.
在这里,我看了一下c++程序设计语言这本书,发现命名空间除了像上面这样声明以外,还可以像类一样这样来写:
在命名空间中这样定义
void printMyClassInfo(MyClass &);
然后在外面写函数的主体

void MyNameSpace::printMyClassInfo(MyClass &instance)
{
std::cout<<instance.getClassInfo();
}

好了,写了这么多,再来看看刚才留下来的那个问题.
其实很简单,一个函数如果传递的是值,那么就会在内存中产生一个一模一样的"复本",而那个字符指针也会被复制一次.当传送的值超过它的作用域的时候 ,就会被释放掉,而被复制的"本体"在程序运行结束之后,又会被"释放一次".这样在运行的时候,它会提示你这样的错误:
*** glibc detected *** double free or corruption (fasttop): 0x0804a008 ***

在我们的MyClassl类的析构中,我们有一个输出,所以这里就输出了两次:
free classinfofree classinfo

littlegai 2007-06-14 22:06 发表评论

富爸爸投资指南读书笔记

littlegai — Wed, 13 Jun 2007 11:42:00 GMT

富爸爸研究过公司法和税法，并找到了利用法律为他赚很多钱的方法。
mortgage
KK: []
DJ: []
抵押贷款，源于法语mortir，法语意思是死亡，因而抵押贷款就是直到死的一种契约
real estate
KK: []
DJ: []
不动产，并不是“真正”的财产，来自于西班牙语，意思是贵族的财产。
我们仅仅是在技术上控制了不动产，却并不能占有它，政府占有这些财产，向我们征收不动产税。
奥肖内西华尔街股市投资经典
What Works On Wall Street:A Guide to the Best Performing In-vestment Strategies of All Time
提出两种不同的决策方法：
经验型的分析方法或称直觉式分析方法。该方法以知识，经验和常识为基础。
定量分析法或称精确统计法。这种方法以大量数据为基础，推论出各种关系。
在多数情况下，直觉分析法的投资者常常做出错误的决定，或败给几乎纯机械的方法。即：人类的推断力远小于我们所想象的。

企业取得权不动产组合购买抵押品贴现合同投资研讨班罗宾逊准则
有些东西你的眼睛是看不到的，不动产就是不动产，股票就是公司股票，这些东西你能看到，但是你看不出什么事重要的。决定某种东西是不是一项好的投资的还有：交易、财务协议、市场、管理、风险因素、现金流、企业结构、税法和很多其他的事情。
你为什么要付这么高的利率？你认为你的投资回报是多少？这项投资于你的长期财务战略吻合吗？你打算用多大比例计算修理费用？你知道这个城市刚刚宣布要在那个地区修路以改善交通状况吗？一条大道就要从你的房前穿过，你知道这些吗？我知道现在市场看好，但是你知道是什么在驱动市场，商业经济还是贪婪？你认为这种趋势会维持多久？如果你的房子租不出去，你将怎么办？

建议并不是现实.
成为-->做-->拥有
大多数人追求做而不是追求“成为”
一个拥有失败者心态的人将一直失败
不要在对方身上下功夫，而要在你对对方的看法上下功夫
丹尼尔格鲁曼《情商》
父母会说很多的“应该”，小孩说很多的“感觉”
父母并不一定就是成年人
作为一个成年人应当意识到你必须去做什么并且去做，即使你可能感觉上并不喜欢做这件事
我的富爸爸不许我说：
“我付不起钱”
“我做不到”
“做事要稳妥”
“别赔钱”
“如果你失败了并且再也翻不了身，该怎么办？ ”
他不许我说这些是因为他坚信语言是人类最有影响力的工具，一个人所说的和所想的终将变为现实。
用圣经里面的话即使：
语言将变为血肉，留在我们体内。

littlegai 2007-06-13 19:42 发表评论

数据结构读书笔记（栈：不只是C++的东西）

littlegai — Mon, 11 Jun 2007 14:11:00 GMT

栈在概念方面确实没有提的必要了。看了数据结构的这一部分，就将书中的一小段代码实现了。这里用到了标准库中的stack。下面就是根据输入的十进制正数获取二进制正数的程序（书上是八进制）：

1 #include <stack>
2 #include <iostream>
3 using namespace std;
4 int _tmain(int argc, _TCHAR* argv[])
5 {
6     stack<int> binaryStack;
7     int decimalValue;
8     cout<<"please input decimal value:";
9     cin>>decimalValue;
10     while(decimalValue)
11     {
12         binaryStack.push(decimalValue%2);
13         decimalValue=decimalValue/2;
14
15     }
16     cout<<"\n"<<"the binary result is:";
17     while(!binaryStack.empty())
18     {
19         int result=(int)binaryStack.top();
20         binaryStack.pop();
21         cout<<result;
22     }
23     cout<<"\n";
24     return 0;
25 }

另外顺便看了一下C#和JAVA，当然也支持栈。但是这些东西在我平时使用的时候却很少用到，或者在用到的时候去“重复发明轮子了”。作为一个经典的数据类型，栈理应是被绝大多数语言支持的（不知道PB怎样）。所以在这里要树立一下“重用轮子”的意识：
C#的十进制转二进制实现：

1 class Class1
2 {
3 ///

4 /// 应用程序的主入口点。
5 ///

6         [STAThread]
7         static void Main(string[] args)
8         {
9             //
10             // TODO: 在此处添加代码以启动应用程序
11             //
12             Stack binaryStack=new Stack();
13             Console.WriteLine("Please input decimal value:");
14             String sDecimal=Console.ReadLine();
15             int decimalValue=Int32.Parse(sDecimal);
16             while(decimalValue!=0)
17             {
18                 binaryStack.Push(decimalValue%2);
19                 decimalValue=decimalValue/2;
20             }
21             Console.WriteLine("The binary result is:");
22             while(binaryStack.Count!=0)
23             {
24                 Console.Write(binaryStack.Pop());
25             }
26             Console.WriteLine();
27         }
28     }

JAVA的十进制转二进制实现：

1 import java.io.BufferedReader;
2 import java.io.InputStreamReader;
3 import java.util.Stack;
4 public class hello1 {
5     public static void main(String args[])
6     {
7         try {
8             Stack<Integer> binaryStack=new Stack<Integer>();
9             int decimalValue;
10             System.out.println("please input decimal value:");
11             BufferedReader bufferedReader=new BufferedReader(new InputStreamReader(System.in));
12             decimalValue=Integer.parseInt(bufferedReader.readLine());
13             while(decimalValue!=0)
14             {
15                 binaryStack.push(decimalValue%2);
16                 decimalValue=decimalValue/2;
17             }
18             System.out.println("the binary result is:");
19             while(!binaryStack.empty())
20             {
21                 System.out.print(binaryStack.pop());
22
23             }
24         } catch (Exception e) {
25             // TODO Auto-generated catch block
26             e.printStackTrace();
27         }
28
29
30     }
31     }

通过比较，会发现C#不大有“栈”的感觉，JAVA和C++更贴近于《数据结构》中对于数据类型“栈”的操作的定义。另外支持模板或者范型的特点让人用起来总会感觉十分舒服。在这里提醒自己：以后这三种语言有“栈”可用了！

littlegai 2007-06-11 22:11 发表评论

数据结构读书笔记（冒泡排序:不要只注意最坏的情况）

littlegai — Sun, 10 Jun 2007 14:34:00 GMT

数据结构第一章讨论了一些有关算法的问题.在这一部分再次引入了那个经典的算法--冒泡排序法。
如果让我来描述一下这个算法的过程的话，我会这样描述：
从第一个元素开始和依次进行比较，大的那个放在后面，一直到最后一个元素。这样最后一个元素就会成为最大的那个；除刚才产生的最大的那个元素外，再次从头开始比较，一直到第一个元素没得可比为止。
这是我的理解。进而通过这个理解，我可以写出这个算法来。这没有问题。但是当我看到原版的算法的时候，我立即就感觉出差别来了：

1 void bubble_sort(int a[],int n)
2 {
3      for(i=n-1,change=TRUE;i>1&&change;--i)
4      {
5          change=FALSE;
6          for(j=0;j<i;++j)
7              if(a[j]>a[j+1]{a[j]<-->a[j+1];change=TRUE;}
8      }
9 }

注意变量change。这里体现的思路是：如果在某一次比较过程中没有移动任何元素，那么就没有必要再从头比较一次了。因为实际上已经得到了一个排好序的数组。
这样对于相当多的情况来讲，减少了很多的不必要操作，自然平均时间复杂程度就降低了。
因为我往往只考虑到比较坏甚至极端的情况（比如完全逆序），所以自然就会忽略这些看上去不太坏，甚至是非常好的情况，这样一个直接的结果就是让那些好的情况下的操作也变得繁琐异常，而仅仅是为了照顾那些比较难于出现的个别异常情况，现在想想，这样做不可取。日后应当注意。

littlegai 2007-06-10 22:34 发表评论

The C++ Standard Library : A Tutoral and Reference 读书笔记之模板(1)

littlegai — Sat, 09 Jun 2007 15:53:00 GMT

最近开始系统学习STL.首先找到这本书--The C++ Standard Library : A Tutoral and Reference然后一边看书一边找着里面的例子做做.个人认为比较重要的内容将会在这里进行记录.
与此相关的阅读和实验过程都是在linux下进行的,所以这些读书笔记也会在linux下完成.这里不由得感叹一下--博客园的博客系统的通用性确实做得非常好,至少我在fire fox下面下使用没有感觉到任何的差别.
首先是模板Template.

template<class T>
class MyClass
{
private:
T value;
public:
const T getValue()
{
return value;
}
void assign(const MyClass<T> &m)
{
value=m.value;
}

MyClass(T theValue)
{
value=theValue;
}

};

上面的MyClass就是我的模板类.然后我按照如下的方式进行调用,是没有问题的:

MyClass<int> i1(1);
MyClass<int> i2(2);
cout<<"\n";
cout<<i1.getValue()<<"\n";
cout<<i2.getValue()<<"\n";
i1.assign(i2);
cout<<i1.getValue()<<"\n";
exit(0);

但是如果这样,就会出现问题.

MyClass<int> i1(1);
MyClass<float> f3(3.9);
f3.assign(i1);

编译器会告诉你:
TemplateExp.cpp: In function ‘int main()’:
TemplateExp.cpp:36: 错误：对 ‘MyClass::assign(MyClass&)’ 的调用没有匹配的函数
TemplateExp.cpp:13: 附注：备选为： void MyClass::assign(const MyClass&) [with T = float]
因为在编译器看来
void assign(const MyClass<int> &m)和
void assign(const MyClass<float> &m)是不同的.
这样就必须assign进行修改.我在这里建立了一个新的函数assignX,如下:

template <class X>
void assignX(MyClass<X> &m)
{
value=m.getValue();
}

在调用的时候这样写就没有问题了:

MyClass<int> i1(1);
MyClass<float> f3(3.9);
f3.assignX(i1);
cout<<f3.getValue()<<"\n";
exit(0);

有一点需要注意,在assignX中,不能够只接使用m.value而要使用m.getValue().正如书中所说:
Note that the argument x of assign() now differs from the type of *this. Thus, you can't
access private and protected members of MyClass<> directly. Instead, you have to use
something like getValue() in this example.
由于类型不同了(即MyClass不同于MyClass)所以就不能使用this.因而要另外建立一个获取值的函数.
实际上上面写的代码和书中还是有所不同的.比较重要的区别是函数assign.
书中的参数为:
template
assign(const MyClass& x)
这样实际上是不能得到x.getValue()的.编译器会给出这样的提示:
TemplateExp.cpp:36: instantiated from here
TemplateExp.cpp:20: 错误： passing ‘const MyClass’ as ‘this’ argument of ‘const T MyClass::getValue() [with T = int]’ discards qualifiers
但是修改成
template
assign(MyClass& x)
就不会有问题了

littlegai 2007-06-09 23:53 发表评论

Domain-Driven Design: Tackling Complexity in the Heart of Software 语句精摘.3.

littlegai — Thu, 31 Aug 2006 15:22:00 GMT

Chapter Three. Binding Model and Implementation
If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect. At the same time, complex mappings between models and design functions are difficult to understand and, in practice, impossible to maintain as the design changes. A deadly divide opens between analysis and design so that insight gained in each of those activities does not feed into the other.
如果一种设计,或者它的一些核心并没有与域模型相关联，那么这个模型就没有价值，并且以此而开发出来的软件的正确性也值得怀疑。同时，模型与功能设计之间复杂的对应关系会变得难于理解，并且当设计变化的时候，它们将很难维护。一种致命的分歧就此在分析与设计之间出现，以至于那些分析设计活动中所获得的见解不能彼此满足。

Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious. Revisit the model and modify it to be implemented more naturally in software, even as you seek to make it reflect deeper insight into the domain. Demand a single model that serves both purposes well, in addition to supporting a robust UBIQUITOUS LANGUAGE.

Draw from the model the terminology used in the design and the basic assignment of responsibilities. The code becomes an expression of the model, so a change to the code may be a change to the model. Its effect must ripple through the rest of the project's activities accordingly.

To tie the implementation slavishly to a model usually requires software development tools and languages that support a modeling paradigm, such as object-oriented programming.

以书面的形式设计软件系统的一部分，进而与域模型相映射，这样双方的对应关系将会变得明显。重新考虑这些模型并且通过修改让他们在软件当中显得更加自然，甚至是当你在寻求一种方法，来让模型更加深刻的反映问题域的时候也要如此。追求尽可能简单的模型，让它能够满足多方面目的（软件方面和设计方面？），又能够支持足够健全的通用语言。

        从模型中提取那些在存在于设计中，以及存在于（域专家的?）职责所包含的基本工作中的那些术语。代码会因此成为对于模型的一种描述，所以对于代码的更改或许就是源自于对于模型的更改。从而，它们的影响将会波及到项目其他部分的行为。
        要牢固的把实现和模型绑定在一起，通常需要一些软件设计工具以及支持模型范例的语言，例如面向对象程序设计。

If the people who write the code do not feel responsible for the model, or don't understand how to make the model work for an application, then the model has nothing to do with the software. If developers don't realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it. Meanwhile, when a modeler is separated from the implementation process, he or she never acquires, or quickly loses, a feel for the constraints of implementation. The basic constraint of MODEL-DRIVEN DESIGN—that the model supports an effective implementation and abstracts key domain knowledge—is half-gone, and the resulting models will be impractical. Finally, the knowledge and skills of experienced designers won't be transferred to other developers if the division of labor prevents the kind of collaboration that conveys the subtleties of coding a MODEL-DRIVEN DESIGN.
如果写代码的那些人对于模型没有责任感的话，或者他们并不能懂得如何让模型作用于应用，那么模型对于软件来讲毫无用处。如果开发人员不能够认识到对于代码的修改就是对于模型的修改的话，它们的重构将会使模型变得更糟，而不是让它们更加健壮。同时，当一个从事建模的人与实现过程相隔离的时候，他（她）永远也不会获得，或者说会很快失去对于实现的约束感。模型驱动设计的基本约束即是--模型需要对那些有效的（程序）实现提供支持，并且能够抽象关键的域知识--任缺其一，模型都会变得不切实际。最后，如果项目中的分工阻止了能够微妙的改善模型驱动设计代码编写的那些协作，那么团队中经验丰富的设计人员的知识和技术将不能给的其他设计人员带来提高。

Any technical person contributing to the model must spend some time touching the code, whatever primary role he or she plays on the project. Anyone responsible for changing code must learn to express a model through the code. Every developer must be involved in some level of discussion about the model and have contact with domain experts. Those who contribute in different ways must consciously engage those who touch the code in a dynamic exchange of model ideas through the UBIQUITOUS LANGUAGE.
任何专注于模型的技术人员必须花时间接触代码，而不论他（她）在项目中的首要角色是什么。任何负责修改代码的人必须学会通过代码来描述模型。每一个开发人员必须不同程度的被纳入到对模型的讨论以及和域专家的交流中。那些上述工作之外所涉及的项目人员必须自觉地让那些接触代码的人通过通用语言动态的交换对于模型的意见。

littlegai 2006-08-31 23:22 发表评论

Domain-Driven Design: Tackling Complexity in the Heart of Software 语句精摘.2.

littlegai — Tue, 29 Aug 2006 13:25:00 GMT

Chapter Two. Communication and the Use of Language

A project faces serious problems when its language is fractured. Domain experts use their

jargon while technical team members have their own language tuned for discussing the domain

in terms of design.

The terminology of day-to-day discussions is disconnected from the terminology embedded in

the code (ultimately the most important product of a software project). And even the same

person uses different language in speech and in writing, so that the most incisive

expressions of the domain often emerge in a transient form that is never captured in the

code or even in writing.

Translation blunts communication and makes knowledge crunching anemic.

Yet none of these dialects can be a common language because none serves all needs.

当用于交流的语言出现断层的时候，项目将会面临一系列严重的问题。域专家们与技术团队自

说自话。
日常讨论所用的术语不再与代码（它们会成为软件项目的重要部分）中的术语相联系。甚至同

一个人会在交流中和在记录中所用的术语不相一致，以至于问题域中那些重要的表达方式出现得如此短

暂进而使它们无法被捕获到代码中去甚至无法被记录下来。

Use the model as the backbone of a language. Commit the team to exercising that language

relentlessly in all communication within the team and in the code. Use the same language in

diagrams, writing, and especially speech.

Iron out difficulties by experimenting with alternative expressions, which reflect

alternative models. Then refactor the code, renaming classes, methods, and modules to

conform to the new model. Resolve confusion over terms in conversation, in just the way we

come to agree on the meaning of ordinary words.

Recognize that a change in the UBIQUITOUS LANGUAGE is a change to the model.

Domain experts should object to terms or structures that are awkward or inadequate to

convey domain understanding; developers should watch for ambiguity or inconsistency that

will trip up design.
把模型作为通用语言的核心。推动整个团队在各种各样的交流中以及在编码中严格的实践这种

语言。在图表、记录特别是谈话中统一交流方式。
通过选择性的表达方式，即那些对应不同模型的表达方式来消除通用语言中的难点。然后重构

代码，重新命名那些类、方法模块，使它们和新的模型相一致。我们对那些常用词汇的理解渐渐的达成

一致，并以此来解决交谈期间的那些混淆。
要知道，对于通用语言的任何变化都是对模型的变化。
域专家们应当积极反对那些尴尬的或者不能充分传达域概念的术语，开发者应当时时留意含义不

明确或者有矛盾的地方，这些地方会给设计埋下隐患。
Play with the model as you talk about the system. Describe scenarios out loud using the

elements and interactions of the model, combining concepts in ways allowed by the model.

Find easier ways to say what you need to say, and then take those new ideas back down to

the diagrams and code.
当你谈论系统的时候，多多使用模型。大声地使用模型所提供的那些元素和交互方式描述情节

，以模型所接受的方式联结域中的概念。尽可能简单的表达你所要表达的东西，然后反过头来把这些思

路转变为图表和代码。

littlegai 2006-08-29 21:25 发表评论

Domain-Driven Design: Tackling Complexity in the Heart of Software 语句精摘.1.

littlegai — Mon, 21 Aug 2006 12:50:00 GMT

Part I: Putting the Domain Model to Work
A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert's head; it is a rigorously organized and selective abstraction of that knowledge. A diagram can represent and communicate a model, as can carefully written code, as can an English sentence.
域模型并非一种特殊的图，却是这种图所要传达的含义。它并不仅是域专家头脑中的知识，它是严格组织出来的，并且有选择的抽象的知识。一张图示可以展现以及表达一种模型，同样的，一段仔细斟酌的代码可以，一句英文也可以。
In domain-driven design, three basic uses determine the choice of a model.
1.The model and the heart of the design shape each other.
2.The model is the backbone of a language used by all team members.
3.The model is distilled knowledge.
在DDD中，三种基本用途决定了模型的选择。
1.模型和设计的核心交相辉映。
2.模型是所有团队成员交流方式的中心。
3.模型是精化后的知识。

littlegai 2006-08-21 20:50 发表评论