面向对象是过程，而不是结果

先撤点别的：）

一直觉得博客园的氛围很好，有什么事大家可以一起讨论。
看到博客园里讨论面向对象，感到非常欣慰，因为我也喜欢面向对象。
对于非数据库相关项目来说，可以直接套用面向对象的理论，对我们来说没有什么困惑。
（因为非数据库项目数据结构通常是驻留在内存里的，而数据库相关项目数据结构是在数据库里）

但国内很多的项目是数据库相关的项目，所以学了面向对象，再去做项目的时候总是觉得，心有余力不足。
就是困惑啊，就是郁闷啊。

我想这个是正常的，因为这两个东东本来就有矛盾的，认清这一点，是非常重要的。你认定这两者之间存在着矛盾，
你就可以在实际的项目中，根据两者的特点做出选择，
1 - 略微面向对象（老马的企业应用架构模式里讲到的初级的几个，但也不必照搬它的，神式就可以了）
2 - 适中的面向对象（比如IBatis）
3 - 完全面向对象 (比如Hibernate)

当然上面讲的是关于面向对象和数据库怎么揉到一块儿的问题，关于领域模型，就是业务逻辑，怎么设计是别的话题了（需要精确把握需求，才可以做好，否则是空谈）

外国也有像博客园里各位一样，热衷于面向对象讨论的人，也很经典，今天就帖几个，大家可以看看。
不能说每个说法都正确，但肯定有学的东西，

超强反面向对象站点，没见过这样的，而且说的是有鼻子有眼。
http://www.geocities.com/tablizer/index.html
Your Code:OOP or POO?
http://www.codinghorror.com/blog/archives/000801.html
Costs of OO and n-tier
http://www.lhotka.net/Article.aspx?id=08b4a1dc-c4de-4ee4-872d-14c66d0bf36d

     摘要: 原来，面向对象和数据库是“冤家”没经证实的传说话说当年面向对象和数据库刚出道的时候，曾经引发过惊天动地的大讨论(当然，这里说的是关系型数据库,以下简称数据库)。两个阵营的人都试图说服对方，加入到自己的阵营里来(传说是都说了，你别做了那个了，没发展)。经过车轮式讨论，也没得到共识，只好分道扬镳了。虽然，无法考证这个传说是不是真的，但确实，面向对象和数据库之间存在着矛盾。这正是... 阅读全文

写下这个题目的时候，心中想到的是另外一句话：“该死的英语四级”。
当 努力想得到一种东西却得不到的时候，就会套用经典的“该死的xxx”句型，伴有举出应该抵制xxx的N种理由、到论坛上发帖力辩xxx是否有用等症状，这 在弗洛伊德的经典精神分析体系中被称为吃不着葡萄就说葡萄酸综合症。此类病症在我国较为普遍，尚无特效药，较难治愈，偶尔痊愈者有时还会就下后遗症，具体 表现如考过四级之后散布“四级这么简单没过的都是白痴”等言论等等，给众多家庭带来了苦恼，给社会带来了沉重的负担。

不幸的是本人也身染此 病，现在正陷入自身的苦恼和因给他人带来苦恼而更加的苦恼之中不能自拔。根据市级以上医院的三维彩超诊断，本人应该属于后遗症阶段，具体表现为散布“面向 对象这么简单学不会的都是白痴”之类言论。其实前一段时间，由于医院的精心治疗，我的症状已经有所好转，然而最近轻心大意，不遵医嘱，接触了不适环境，又 使病情出现了反复，让我后悔莫及。

具体地说，我是到若干企业进行了面试，那真是一些难忘的场景。

HR：我们这个职位一般不要毕业生，要求有实践经验的。
Me：您写的要求技能，我觉得我有点基础，不知可不可以试一试？
HR：那，你给我解释一下，什么叫虚拟？
Me：虚拟？
HR：对，虚拟。
Me：……您是指……虚拟的什么？
（虚 拟的东西可多呀，虚拟机？VMWare？JVM？.NET？Win32VM？还是虚拟电路？EWB？虚拟现实？VRML？虚拟光驱？虚拟PS？模拟器？虚 拟人生？……我研究过JVM结构，还自己写过基于堆栈机原理的、运行自己设计的汇编语言的虚拟机器，它是指这个？那我也许可以……）
HR：就是“虚拟”这个概念，你给我解释一下。
（这个问题还真有难度，如此泛泛地解释“虚拟”，我还真要仔细组织一下语言。）
Me：呃……我想，虚拟在计算机领域一般指用软件来模拟一个真实存在的事物……
HR：不对。
Me：……（迷茫中）
HR：你根本不懂什么叫“虚拟”。
（我开始冒汗，毕竟是高人，我觉得我对虚拟也算有所理解了，可在人家看来都不值一提。难以想象，高人们的思想都到了什么境界！）
HR：这样吧（递给我一张纸），你给我写一个例子，一个虚拟的例子。能写出来吗？
(我开始绝望，写什么？难不成把我写的虚拟机代码在这里都默写一遍？就算我能记得住，你就给我这一张纸？）
我迟迟不能动笔，HR摇头。
HR：那你了解面向对象吗？
Me：了解一点！（我如获至宝，赶快擦干汗）
HR：那你给我说说面向对象吧。
（也 这么泛泛地说？我……面向对象还有什么可说的么？那哪是两分钟能说得完的？我设计OO虚拟机的时候，设计动态联编虚方法表的时候，为了解决多继承，可谓绞 尽脑汁；为寻找用面向过程来模仿面向对象的方法而费尽心思；为了发挥面向对象的最大优势而努力引入垃圾收集；设计正则表达式解析器的时候为构建递归解析 树，对parse方法进行了各种重载以适应& | *三种运算符，等等，面向对象在我心中早不是一个整体，而是融合到各种设计思想当中去了，现在让我泛泛地说，还是相当有难度……）
Me：面向对象，……我想，泛泛地说，就是三条原理，封装性，继承性和多态性……（那时我像一个混日子的大学男生，或者一个刻苦努力的大学女生，在死记硬背）
HR：不行，你对面向对象掌握也不好。
（太对了，我这么回答，要是有人能觉得我掌握得好才怪。可我究竟应该怎么回答呢？我深切地感受到自己语言功底之差。）
HR：（语重心长地）面向对象，虚拟这些东西，都是很基础的，应该掌握好，要是……
（慢着！！！！我有种被愚弄的感觉，也怪我笨，居然没有听出来他的意思！）
Me：您说的虚拟是指虚拟方法吧？virtual方法？
HR：对。
我吐血。
Me：这个，这个我知道，就是指子类重写基类的方法，目的是用统一的接口访问不同的功能实现……（此处省略10000字）
HR：那你再给我写一个虚拟的例子（注视着纸上刚出现的潦草的图形，一个方框派生出三个方框，及各种乱七八糟的标注，若有所思）。
我在纸上写：virtual void func(int x);
HR：（沉思片刻）你会SQL语言吗？
Me：（考虑片刻后，我再也不敢轻易说我会了）学过一点……
HR：那，你给我写一个命令，比如这有一个表（迅速在纸上画了方格状图形），你写一条，来查询第5000条至第6000条记录。
Me：这……这不是标准SQL，关系数据库理论中没有这种成份，它类似于集合……
HR：（打断）不过现实应用中都需要这种非标准的东西，需要你很熟练，用的时候拿来就用。
我终于败下阵来。

当 时我想那个HR不是我的冤家派来玩我的吧？还是本来就不想要我却看我挺能装B的所以故意戏耍一番？不过这都不重要了，因为我从人才市场上直接被救护车拉走 了，我的旧病复发了。后来医生告诫我，我切不可再去那个人才市场，以免性命不保。然而，为了养家糊口，为了对得起不嫌弃我的病的温柔女友，我不能不找工 作。于是出院之后，我又冒死去了几家企业面试。但有了这次血的教训，我时刻保持了注意，远离类似上次的那种场所。还好，再没遇到如此严重的刺激，但小的刺 激时常也不可避免，所以我现在一直随身携带急救盒绷带等物。事实证明，不受一点刺激是相当有难度的，因为每面试一个地方，中心问题几乎都是“面向对象”， 好象面向对象真是什么高不可攀的真理似的。该死的面向对象！

后来有人劝我，说我把自己定位错了，说我不应该去那些会问我面向对象的地方面 试，而应该去那些能问更有意义的问题的地方。此言我觉得甚有道理，只是之前我并不知道他们会问我面向对象。然而，就算他不问面向对象有怎样？也许还会问 SQL，问网络，过两年没准都一窝蜂似的都问面向方面编程，相信那时“该死的面向方面”等言论也会纷纷出笼。我不知道我有没有希望把自己的病治好，仅仅在 睡不着觉的时候会偶尔梦想，将来我开个公司，出大钱雇人做经理CxO等，自己去做HR，也见人就问：你懂面向招聘的编程吗？也许对方也一头雾水，或也许世 道发展了，谁都能对答如流，也说不定。不过最吸引我的也许并不是对答如流，也许朝我大吼一声：“问我点别的吧，不要问该死的面向xx！”更能给我深刻印 象。谁知道呢？然而，我仍然不见得会要那个留给我深刻印象的，因为他有病，和我一样的病，而且同样是后遗症阶段。这样或许可以刺激到他们，让他们后半生致 力于建立一个组织，帮助全国乃至全球患者进行维权。这样我或许也可从中受益，没准还能引起世界医疗界的重视，能攻克这种顽疾也说不定，那对社会不可不谓一 种大的解脱，我自己也不用揣着急救盒到处抱怨一句“该死的面向对象”了。
原文地址：http://lych.yo2.cn/articles/%e6%bc%ab%e8%b0%88%ef%bc%9a%e8%af%a5%e6%ad%bb%e7%9a%84%e9%9d%a2%e5%90%91%e5%af%b9%e8%b1%a1.html

   面向对象是什么？你可以说出这个答案吗(相信没有正确答案)？我觉得面向对象只是软件工程中的一种工具而已。那软件工程的目的是什么？目的是编写出可靠、高效、灵活、易扩展、可复用的软件产品。既然面向对象是软件工程当中的一种工具，那我们使用面向对象的目的也应该是这些。就是说我们用面向对象的目的是编写出可靠、高效、灵活、易扩展、可复用的软件产品。我们一定要以这个目的为中心来学习和使用面向对象，不然你会失去方向。大多时候讲面向对象，多是讲面向对象本身，而不讲怎么利用面向对象去解决实际的问题，这样很容易误导初学者。再加上华丽的文字，很多人觉得只要面向对象了，什么事都可以OK了。举个例子，给你一把最好的枪，教你如何使用它，过了一段时间你对这把枪了如指掌。现在让你去打靶，结果100发子弹，一发都没有打中。咦，我不是用了最好的枪了吗？为什么一发都打不中？因为你不知道射击要领，不知道如何瞄准靶心，结果当然可想而知了。我们要OOP(Object-Oriented Programming)，不要POO(Programming Object-Oriented)。

    面向对象有3大特征（一般讲面向对象都会提到这三个），继承、封装、多态。按字面上理解，对我们来说是全新的概念，但只要你分析一下，就会发现这些都是我们在编程中，常常用到的概念。

    封装是什么？只有在面向对象里才有封装的概念吗？不是的，只要是程序就有封装。大家常常用的变量、函数就是封装。举个例子，你写了取用户状态的函数，对调用这个函数的程序来说，取用户状态逻辑是封闭的，所以逻辑发生变化时，不会对调用的程序造成影响。变量也是封装，你定义了一个int变量，无论你给它赋什么值，对调用这个变量的程序来说，就是一个整数型类型的值。提到封装不得不提接口，因为封装是做接口的过程。接口是什么？只有用了interface这个关键字才是接口吗？词典里的解释是物体的接触面、界面。世界是由物体组成的，所以我们的生活当中到处是接口。你看到一个球，它是圆的，圆就是接口。我们的程序也都是由接口组成的，数据类型、关键字、函数、变量等等。比如说看到int这个词，你就知道它是整数型数据类型，我们可以说:int是整数型数据类型的接口。所以封装和接口不是面向对象特有的概念，只不过在面向对象里它们的范围扩大了而已。我们在网上常常能看到面向对象和面向过程之间的讨论，说哪一个好。其实，这些都是不重要的，因为用哪一个方法，都是做接口的过程。关键在于使用这些方法的程序员，看你的抽象能力怎么样了。

    多态可能是我们最难理解的一个概念，polymorphism这个词，因为大家没有学习过面向对象的话，是很难碰到的。其实这个也是我们常常用到的一个概念，只不过没有给它命名而已(至少没用多态来命名它)。看下面的例子， 输出结果是
6
8.5
我们先定义了三个变量，a、b、c，先后给A赋值1，3.5，然后输出a+b的结果，可以看到，同样的逻辑随着a值的变化，输出的结果也是不一样的（多态的效果）。在这里double是高类型（相当于父类），1、3.5(int,float)是低类型（相当于子类）。这个例子是变量的多态，那有没有函数多态的例子，当然有，写过C的人都知道函数指针，它就是函数的多态。

    终于要说说对象了，重点就在这里~ 第一，类是一个模块。以前我们的模块是一个文件，比如一个.c、.cpp等等。一个模块文件里写什么功能函数没有限制（理论上没有明确定义该怎么写），按开发人员的经验来部署这些功能函数。所以很容易写出超级模块（一个文件里有几十个、几百个函数），代码维护起来很不方便。面向对象就很好的解决了这个问题,只要看过面向对象基础理论的程序员都知道,先定义类，然后把相关的函数放到类里。面向对象里有一个原则，类单一职责原则，遵循这个原则的话，你可以写出很好的模块出来。更重要的是我们沟通维护起来也很方便，比如以前沟通可能是这样的，修改customer.cpp文件里的某一个函数，面向对象里呢，可以这样说修改客户类的某一个方法。这个非常重要，因为这个跟人的思维有密切关系。比如我们到餐厅去吃饭，你对服务员说我要一瓶啤酒，我确信服务员会再问你一句：先生，你要什么牌子的啤酒？但如果你说：我要一瓶百威啤酒，服务员肯定不会再问你。要是把一个系统看成生产线的话，类就是工人。一个工人只负责一个操作，A负责打孔，B负责装螺丝钉，C负责包装。这样做非常有效率，而且出了问题，很好确定问题出现在哪个工人。第二，类是一个自定义数据类型。理解了这点，你的思路会清晰起来，也不会对面向对象感到陌生。看下面的简单例子，

 

例子里，低类型的int和float赋值给了高类型的double，然后用sum函数它们的合。如果编程语言不支持这种转换的话，我们只好写两个函数了， 所以我们可以确定-同类型当中，只有提供从低到高类型的转换，才可以实现多态的效果(不知道，没有面向对象以前是什么概念)。当然，类作为数据类型，也需要这种转换了。但类是自定义类型，所以，哪个是高类型，哪个是低类型，必须要由我们来定义:父类是高类型、子类是低类型(继承是这么诞生的吗:))。继承让我们可以复用父类的代码，但在这个例子中我们可以看出，它的主要目的是在多态。

    上面我们讨论了面向对象和它的三个特征，我们可以看到，这些都是编程当中常常用到的概念。我觉得最大的突破是给我们提供了新的思维模式、新的代码组织结构、定义了以前软件设计中比较模糊的概念(比如多态)。那我们怎么转换我们的思维呢？把你想象成公司的经理就可以了。你现在是一家公司的经理了，部门就是子系统，员工就是对象。你需要做的就是这些，

-每天会有很多事需要你处理，做好心里准备。
-公司做什么业务？
-要建立几个部门？，规定部门之间的沟通规则。
-需要什么样的职位？每个职位要做的事是什么？
-规定业务流程，业务流程中，需要哪个部门参与？需要哪个员工参与？他们之间怎么沟通？
-借鉴成功的管理模式，但要符合公司的情况，不要盲目地使用，因为代价太大了。
-不要设置太多的沟通环节，能简单就简单，只要完成目标就可以。
-准备应对变化。世界上没有对于错，永远是前进中不断修正。

就这些啦？恩，道理很简单，但要做一个好公司就非常困难了,因为变数太大了。面向对象也是一样的，需要付出努力，才可以做好。

   大家不要以为面向对象是从石头里蹦出来的。它只是提供了新的思维模式和代码组织结构，其他都是我们常常用到的东西。大家可能觉得歌手很风光，随便上台唱首歌就可以拿到比较好的报酬。但你知道吗？他们每天都得练基本功，声带、气息、咬字、共鸣等等，你觉得这些很简单吧~但恰恰是这些基本功，才让他们唱出最美丽的声音。

先把自己的卫生做好
   大家在舒适、整洁的环境里工作时，会感到心情舒畅，。我们写的代码也是，杂乱无章的代码，会让我们感到摸不着头绪，工工整整的代码，会让我们感到精神振奋。大部分公司都有自己的编码规则，大家一定要遵守。下面呢，我举几个最基本但非常重要的规则。

    命名规则，可能是大家觉得命名不重要，所以在实际的工作当中常常被忽视。我们写的程序像文章一样，不光是要让自己读懂，还要让别人读懂，所以规范命名是非常重要的。那怎么能够让人容易读懂呢？那就是用我们生活当中的日常用语，因为日常用语是被大家所接受的，所以大家容易达成共识。比如说顾客可以命名为Customer、工资可以命名为Salary,一目了然。

    还有在命名时尽量使用英语不要使用汉语拼音，因为程序语言是英语，英语和汉语拼音混杂在一起，不容易达成统一。另外一个原因，我们的开发环境正走向国际化，你把命名写成汉语拼音，老外肯定不知道你写的是什么，你总不能让老外去学习汉语拼音再来编程吧？

    控件的命名也很重要，比如说在.NET里创建了一个WINFORM,它的默认命名是From1,还有一些程序员使用这样的默认命名，因为他们觉得反正程序只有一个WINFORM,所以费劲脑汁去想名字，没那个必要。但你有没有想到过，假如你的程序有几十个WINFORM的时候，假如你是跟别人合作开发的时候，你怎么管理这些WINFORM？,你怎么跟别的同事沟通？。更要注意的是要做好WINFROM里的常规控件的命名，因为这些控件在一个WINFORM里重复率高，所以如果没有做好命名，你只有反复切换代码窗和属性窗，才可以知道这个控件是做什么的。看下面的例子，大家肯定不知道他是在做什么。

再看下面的例子，大家是不是觉得很好理解？
    代码注释，上面提到了命名规则会让代码容易读懂，如果加上注释的话就会锦上添花。最关键的问题，人的记忆力不太好。你写程序，开发过程中呢，可能感到轻车熟路，但时间久了，你再看代码时，我确信80%的逻辑你都忘记了。还有如果你写底层的类库，那你更应该要写好注释，因为你要保证代码准确性的同时，也要保证别人容易读懂。

    注释根据开发语言的规范来写，开发完成后可以直接生成代码文档。大家都知道JAVA、.NET、PHP都有自己的注释规范。

    每个类和函数都要有注释，哪怕是简短的一句。这个是起代码的概括说明作用，可以让我们不读代码也可以知道大概的功能。

    公用变量和重要的变量要有注释，因为这些变量在程序中起重要的作用，所以一定要有注释，必要时要详细注释。

    复杂的逻辑要有详细的注释，这里说的详细注释是指，实现功能时你的思路。

    函数的变量和返回值要有注释，这个也不必多说了吧。

    函数代码比较长时，在一个逻辑分段上注释，可以增加代码的易读性。下面是例子，大家可以参考一下，
    代码格式，这个也是增加代码易读性的一个方法，初级程序员，容易忽视这些问题，但只要你稍微注点意，就可以做好。

    统一的缩进可以让代码看起来整洁规范，现在流行的IDE环境这方面做的很好，它会给你自动缩进，但手写代码时大家一定要注意缩进的问题。

    不要使用过多的if嵌套来实现逻辑。这个问题呢，可能出现在没有写过C语言的程序员身上（其他语言对return的例子不是很多）。比如我们举上面的例子，用户登录。用户在没有登录并且ID和密码正确时才可以登录系统，有的程序员会写出一下代码， 大家可以比较一下，哪段代码更容易读？这个还算是比较好的，如果if里的代码超过一个屏幕的长度时，那才叫超级郁闷!

    一个函数的代码过长时要把它分解成几个函数，可以增加易读性和复用性。

养成懒的习惯
    这里指懒，不是让你去偷懒，而是让你培养复用意识，如果软件开发的世界里没有复用，那是一个多么黑暗的世界啊！复用包括很多方面，比如说变量、算法、业务逻辑、框架、系统等等，按开发的角度来说从前到后开发的难度是越来越大的。

    系统当中一个功能只能有一个接口，这样可以避免重复代码，增加复用性。比如说有一个订单管理项目，项目经理让A程序员写订单管理模块，让B程序员写用户管理模块。两个模块都有查询客户的功能，A程序员写了SearchCustomer函数，B程序员写了FindCustomer函数，大家想一想，这里有什么错误？首先有重复的代码，浪费了资源。第二，代码不容易维护和扩展，如果客户的表结构发生变化或有新的逻辑增加，那必须要修改两个函数。

   功能必须要写成函数，这是复用的基础。如果你还没有这样做，那你现在开始做吧。还是要用上面的例子来说明问题，查询客户并显示的代码如下，

 

这段代码把查询客户逻辑直接写到了显示页面的代码里，这样写，会比上面的例子，有更大的隐患，起码上面的例子，从程序员个人的角度来说做到了复用，并且如果业务发生变化，只需要改两个函数。但在这个例子里，如果业务发生变化，你需要修改所有包含查询客户逻辑的代码，你会不会觉得头大呢？我们不能确定一个功能会在项目里得到复用，但不怕一万就怕万一。再说写函数也不是一件非常困难的事情。

    必须要使用MVC模式，这里是指逻辑上的MVC。MVC是一个很好的设计模式，即使你还不了解，你也要用MVC。MVC让你的业务逻辑、显示逻辑、界面逻辑分开，使得各个层都可以复用。现在我们用MVC的结构写一下，上面的例子，

 

大家可以看到，因为我们把业务逻辑分离出来了，所以A程序员和B程序员都使用了同一个函数FindCustomer（代码得到了复用）。 而且如果业务逻辑发生变化，我们只需要修改一个函数就可以了。

    不要把逻辑写到控件里，因为这样做逻辑不清晰，而且逻辑不能得到复用。现在的开发工具为了提高开发效率，提供了很多方便的控件，但是我们要记住，不要把逻辑写到控件里。其实这个呢，跟上面说的一定要使用MVC是一样的道理。在这里呢，举数据库控件的例子,如果你直接用数据库控件（把SQL语句写到控件里），来写代码，第一，代码的逻辑不清晰，因为逻辑是隐藏在控件里的，而且数据库控件多时很难管理（DELPHI，DataModule里放了几十个TQuery控件，你不烦吗?）第二，很难复用逻辑，比如两个程序员要用同样的逻辑，那数据库控件里的逻辑应该怎么共享呢？你说，可以使用引用，对，是可以用，但需要用控件的名称来做接口， 控件的名称远不如函数名称来得清晰吧,。

    要把可变值放到变量里，不要写死在程序里，那样你会非常累。这好像是最基本的常识，我们在学校里学习C语言的时候都学过。比如圆周率是3.14，就不要把它写死在代码里，要写成常量。我们在实际的工作当中使用圆周率的机会不太多，但还是有很多相似的情况，大家一定要注意。还有能写后台管理程序的，就写成管理程序，不要每当需要修改或添加需求时直接修改代码，这样你会累，更危险的是当你离开公司之后会出现维护问题。这个要在代码设计时就要规划。举个实际的例子吧，A是一个游戏公司的程序员，公司让他写了一个双倍经验活动的代码。比如在6.1~6.2日，打怪会得到双倍经验。A写的代码逻辑如下，
   如果今天是6.1或6.2日，经验*2

代码写的没错，活动圆满结束了。10.1又要举办双倍经验活动,A修改原代码里的日期完成了任务，而且每当有活动时A就修改代码，不久A觉得不耐烦了，因为每当活动时，他都需要修改代码。后来A离开了公司，公司要举办双倍活动，但现在公司里没有懂游戏编程的程序员，公司只好取消了活动计划。

    要有开放的心态、谦虚的态度，对项目组、对公司尤其重要。
    那为什么要有开放的心态呢？只有拥有开放的心态，才可以跟身边的同事很好地沟通，才可以听取别人的意见，才可以提高团队的工作效率。如果有同事向你求教时，把你所知道的全都告诉他吧！如果你有问题，就问身边的同事吧,即使你的职位比他高！如果你写的代码，不是绝密的，就跟其他同事共享吧。

    那为什么要有谦虚的心态呢？只有拥有谦虚的态度，才可以得到别人的尊重，才可以互相学习共同进步。曾经在网上看到，有一个人炫耀地说自己用一个高深的问题难倒了公司的技术总监，使他离开了公司（很难理解）。软件技术有很多领域，有人喜欢研究算法，有人喜欢研究系统底层，有人喜欢研究框架，有人喜欢数据库编程，在各个领域里要想做到专家级别都很难，所以不要给这些领域划分等级，如果你做了3年的SI业务（成为了专家），现在让你去做游戏开发，你需要多长时间才可以成为专家？返过来也是一样的。

    不断地总结，才可以进步。每件事都不可能做到完美，编程也是一样的。大名鼎鼎的WINDOWS不也有很多BUG吗？但人家会总结经验，下一个版本里不会出现同样的BUG。不要因为你写的代码不够完美而气馁，只要你在下一个项目中修正了一个错误也是进步。学习面向对象也是，不要想一下子把面向对象所提到的所有概念都应用到实际的项目当中，比如，继承、多态、接口、设计模式，不久你会失去信心。我们可以一步一步来，比如先把代码封装到类里，等项目完成之后，你会发现，项目当中的一些地方可以使用多态，如果下一个项目有类似情况时，你就可以使用多态来实现代码，这样循序渐进。你会发现，你在慢慢进步。你的信心也增加了。

    上面讲了学习面向对象之前要做的基础训练，可能还有别的，但这不重要，提这些的原因是让你明确基本功的重要性。这些都是一个程序员应该所具备的基本素质。只要你在日常编码中，多练、多总结，就可以做到。如果你掌握了这些基础，并且理解其背后的思想的话，我相信你,运用这些知识也可以写出很好的程序（从代码组织上来说这些是足够了，但要做好的产品，还要加上算法、对技术领域的了解、对业务领域的了解）。

    软件开发是一个非常有创造性的工作，相信很多投身软件事业的朋友们，最初也应该是被它这个魅力所吸引吧。每当自己开发的软件，能够被别人使用时，每当自己写的程序足够漂亮时，别提多高兴了。是的，像我们初始的感受一样，软件开发要遵循以下两个原则
1．按规定时间给客户提供稳定、安全、高效的程序。
2．程序的代码要易维护、易扩展，而且要有复用。

    上面写的两个原则呢，比较简单，如果大家需要详细说明，建议大家买一本软件工程的书籍来阅读。我在这里提及两个原则的意图呢，是让大家明确两者之间的关系。满足客户需求是永远站在第一位的，即使你用了最高级的语言、方法、过程，但没有按时间完成或没有满足客户需求，那么你的开发是失败的。记得多年前迷恋面向对象，于是把公司的一个重要项目当成了试验品，结果项目进度一直提不上来，最终导致失败。还有一个项目由于时间赶得紧，没有用什么方法，直接用工具提供的组件来完成的，项目还很成功。我们是做技术的，所以对新技术的热衷是无可厚非的，但是你要记住，你没有彻底掌握之前，就不要用到实际的项目当中。

    在第二个原则当中大家一定要注意复用，按我的经验，只要把复用做好，其他的，都可以水到渠成。网上有人说过一句话，大概意思是：够懒才是好程序员。优秀的程序员为了能够懒，就要尽量想出办法减少重复性的工作。在这里呢，不仅要注意个人级别的复用，更要注意项目组、公司级别的复用。假如一个项目组有10个人，没有复用意识的话，有可能10个人重复开发同一个逻辑，如果一个公司没有复用意识的话，有可能几十人开发同一个逻辑，那这个公司的开发效率就可想而知了。

  再明确一下，
  满足客户需求是第一位，技术是第二位。
  思想是关键,其他都是工具。

关于武术绝招：我的武术老师告诉我他的绝招就是直拳，而且从第一天开始他就告诉我每天不低于五千次的训练，当我把这个直拳练到非常快速的时候，这就是绝招了。开始我根本不相信老师交给的绝招。后来在韩国练跆拳道，与世界第一号种子选手对话，才恍然大悟老师的话——他们把简单的动作练的不可替代，而往往简单的动作就是最常识的动作，最直接的动作、最致命的动作。有没有绝招，有的。任何事物都有关键和解决办法，而往往绝招就是常识，是最简单的方法。而我们常规的人都误解，我们认为要复杂才能够厉害。
                                                      -李践语录

    面向对象技术自上世纪60年代诞生以来已走过了40多年的历程。现在流行的开发工具、开发过程无不以面向对象技术为基础，可见面向对象技术的重要性。

    面向对象技术的目的是为了提高软件开发的速度和质量，但在实践当中并没有得到很好的效果。还有很多的项目在失败，还有很多开发人员为了完成任务无休止地加班。
    那面向对象技术到底有没有用？当然，面向对象技术是绝对有用的！
    那问题出在哪里？把面向对象技术当成了神！

忠告
-不管是白猫还是黑猫抓到耗子就是好猫。
只有商业上成功，技术才能得到肯定。
-先打好基础，再盖楼。
思想是基础，其他的都是工具。