wangle79的专栏

原创 今天开会的一点感想

1. 我们在分析耦合性的时候，常常需要基于对象进行考虑。本应封装在一个对象内部的内容，却分散到了多个其他对象中，这势必引入一种耦合性。例如IProperty这个类型，之所以用它取代Variant就是因为IProperty作为一个对象封装了数据、显示、合法性检查等其本身相关的内容，这样使得松散耦合成为可能。2. Observer应该是AttachAsync还是AttachSync取决于(1).被通知

原创 About Windows 读书笔记

1. 使用SystemParametersInfo可以设置桌面背景位图。2. Window Style可以经由SetWindowLong设置。3. AdjustWindowsRect/Ex可用于在CreateWindow之前根据客户区的大小计算窗口的大小，并将之作为CreateWindow的参数。4. 如果一个窗口具有WS_CLIPSIBLINGS 和WS_CLIPCHILDREN，那

原创 Command设计模式应用时的几个问题

在文档/视图设计时需要考虑Undo/Redo，而最好的方法是使用Command设计模式实现。在实际应用Command模式实现Undo/Redo时遇到了一些问题。在开始的时候，逻辑非常混乱，不过经过讨论之后，问题开始清晰，实际上良好的设计使得实现的复杂性大大降低。1. 时间戳的问题。Command都有时间戳，文档是否修改正是通过比较文档的时间戳和当前Command的时间戳是否相等。但是Undo到Co

原创 静态变量的生命周期

原创 封装变化以实现去耦合

在《设计模式》一书中，使用最频繁的词可能就是“封装变化”和“去耦合”这两个了，这两个词的意义，其实不难理解，但是要在实际工程中恰当的应用，是非常困难的。所谓封装变化，就是将可能发生变化的内容放到一起封装起来，对外只是提供固定的通讯方式。去耦合，顾名思义就是不同的内容的相互影响尽量小，一者发生改变时，另一者不需要随之改变。以下以实际项目中遇到的一些设计问题为例，对这两个词进行解读。1. 在多处可能都

原创 最近工作中犯的一些错误，以及总结的体会

1. 做事切忌急于求成，一定要按部就班的来。每一个小小的步骤都必须确信没有问题了，才能进入下一个步骤。以前，为了尽快看到效果，我会选择将某些复杂的任务用一个简单的任务替代，待到效果实现之后，然后再继续修改为复杂的任务，这其实是一种极其低效的工作方法，等于原来写的简单任务的代码完全作废了，而且在修改的时候说不定会遇上新的原来未考虑到的问题，这甚至导致所有的代码必须重写。另外一个例子：在clearca

原创 谈一谈stl的iterator

这两天，使用std::map的iterator的时候，遇到了很多的问题，最后发现很多想当然的想法是错误的。比如：list的iterator自减到了begin()之后，再自减的话会回到end()，从而形成一个循环队列。而map的iterator如果一直自减到begin()之后，继续自减的话，iterator会始终指向begin()；end()之后自增的话，也不会有任何改变。其实上述行为还与stl的实

原创 几个小知识点

前两天看见一句话：不要轻易的下决定，也不要轻易的改变已作的决定，深有同感。今天从VC中内存分配引申出几个小问题。1. 在vc7/crt/src/new.h文件中，有如下语句：inline void *__cdecl operator new(size_t, void *_P)        {return (_P); }显然这就是通常所说的placement new了，确实该operator ne

原创 VC中内存泄露的诊断

我以前的编程风格就是：闷头苦干，想到什么做什么，总是希望能够尽快地看到运行结果。这带来的直接后果是，很多煞费苦心写出来的代码，由于整体设计上考虑欠周道，必须大动手术，甚至重写和删除，这实在是一种浪费。所以我体会到：良好的设计才是软件开发的王道。别说设计，就是代码工作本身也应该循序渐进，该停下来的时候必须停下来，好好的思考一下，整理一下。前段时间写了大量代码，由于浮躁的心态，却懒于整理，导致出现大量

原创 工作近半年的感受

这是我第一次在网络上写文章。因为我的文笔实在太差，软件开发的水平也实在拿不出手，所以一直不敢献丑。今年七月，我以核技术的博士毕业，却选择了软件开发这条道路，别说别人，连我自己都觉得很怪。工作刚开始的时候，确实很难适应。说实话，虽然老大不小的了，但是以前一直窝在学校里，对社会上的事情知之甚少，对软件开发的流程也只有一些平时在课题中积累的点滴经验。不过这点辛苦对我来说并不算什么，毕竟五年的博士生活都挨