C# 实例化两个对象为什么可以同名？？？

cl相当与指针，new Column();才是真正的创建对象
cl只是指向了new Column()创建出的对象
你第一个new Column()和第二个new Column()实际上开辟出的不是同一个内存空间

论述需求理论与设计的关系`

、是否对用户有用是一切产品的基础，理智的设计过程是先从了解用户开始的。
可用性是有环境基础的，高跟鞋在舞会的时候可用在打网球的时候不可用，对女人可用对男人不可用；只有深入了解用户和使用环境才能把确定是否有用，并把有用变成易用。

2、了解用户和环境的手段有很多，最常见的是”数据分析”。
在IT行业中早期大家叫它”数据库营销”，沃尔玛有个“啤酒和尿布的故事”是很成功的经典案例，从中体现了专业数据挖掘的巨大商业价值；

3、现在很多的企业都比较重视数据的分析。
据我所知门户网站的每个页面都埋有数据统计的代码；每个页面每个位置的点击率和操作情况都是详细的记录。
比如，一个注册界面：”多少用户进来，注册成功率(转化率)多少”、”用户出错比例多少”、”用户填写详实程度多少”、”多少用户直接离开，多少用户遭遇挫折后离开，在那里受到什么样的挫折离开”等等等等

4、这些海量数据的挖掘和分析，有着很大的价值和指导意义。
但，这种分析和挖掘也有着自身不够完善和不能真正准确的缺陷，因为很多意外的因素很容易会造成数据的变形，而往往数据分析人员不一定都能知晓这些意外因素。
比如，一个本不该放在某个位置的按钮、本不应该那么大的图片，可能会因为位置明显、面积大而造成点击量很高，这时 通过数据的结果我们并不能得到正确的结论。

5、真正通过和用户接触沟通然后拿到数据，是海量数据挖掘的一个有效补充。这种做法的手段可以比较多样化：
往往我们也会把一些设计的原型拿去让用户试用，或者给用户类似的同类产品让他们去用，设计师在一边观察用户怎么做，从而得到设计启发和思路。这是一种设计师自己去”看”的方式；
比如，要设计一个开红酒的工具，你可以观察用户现在是如何开红酒的，然后也可以把你设计的工具雏形交给用户去用，看他如何用你设计的工具。

很多传统的研究方式中(市场研究中较多)，会请很多用户填写设计好的问卷或者做电话调研、街头访谈、面对面用户访谈和测试等，然后作出数据统计。这是一种让用户”说”的方式；
比如，要设计一个公用电话亭，你可以在大街上采访市民，搜集他们对现有电话亭的抱怨和看法以及他们一般怎么在电话亭打电话..

当然我们还经常去想办法发现用户在怎么想，了解用户脑袋里面的那个MAP。
比如，我们设计一个圆的需要拧开的门把手，我们可以把设计拿给用户看，问他”看到这个圆的把手，你认为应该如何用它开门”；

6、有些时候我们也经常根据用户群的属性特征去做经验式的分析，
比如统计(或总结性模拟)用户的基本属性，分析用户的学习能力和使用习惯等，”学历”对计算机的数量程度”年龄”专业”等等也都是对设计很有用的参考依据。

7、上面所说的这些手段是最常见的一些低成本的做法，当然还有一些靠仪器的做法。
但，目前在国内，我个人认为这些昂贵的仪器对大多数企业都起不到太多的真正作用，或者它们只是一个噱头、业绩…

8、前一段和一位在Yahoo美国的朋友谈到用户研究时，她提到了一些做法也蛮有意思。
比如，在上期帖子回复里有人谈到“走近客服”，他们在巴拿马的一些后期用户研究中会有专门的人去和客服一起工作观察和记录他们的工作，也会亲自尝试接听热线电话；
（往往客服人员提交给数据部门的数据是把他们认为不重要的数据筛选掉以后的，数据部门提交给设计师的数据可能又经过了一次筛选；而他们筛选原则和判断能力可能和设计师有着很大的差别）

再比如，记录某个ID在网站上的全程活动，看这个ID怎么注册的，去了哪里 点了那里 过程中都干了什么等等，记录用户的真实交互轨迹，从而调整”用户操作流程”的设计；
（这种数据比海量分析真实，比逐个用户访谈高效且成本低。 但’隐私’问题需要考虑在内..）

还有，让用户通过他们习惯的方式主动描绘出他们对产品所期盼的感觉也值得尝试；比如我以前提到过一次麦当劳主动了解用户的例子。

9、总的说来：光靠对现状海量数据统计不一定能真正呈现真实现状，光靠点对点的访谈也不一定能全面的反应整体概况。

10、设计师想要深入了解用户和需求，首要的前提是：

通过各种方法走近用户，把用户当作老师；
想方设法拿到一线数据，把数据当作可以淘宝的垃圾堆”。
11、数据不是金矿，用户也不全都是正确的。
很多数据和用户反馈是无用的，甚至是会造成设计误导的。
最终，还得需要具备理智的分析和正确的判断能力。 (所以我最崇拜的UED还是那些”数据分析师”)

ps：对于用户研究我只是学习者，请更多的专业人士尽管指证。 :)