编程的思维PPT课件

1、JAVA,编程的思维和智慧,1,.,02心态、习惯、成长,目录,CONTENTS,03编程的智慧,01面向对象,2,.,面向对象,Java是一种面向对象的编程语言，C是一种面向过程的编程语言。面向对象的编程思维，就是要求我们把事物分成两部分：属性和动作，对属性的动作一定是归属于属性的所有者。,01,3,.,众所周知面向对象是一种编程思维，编程语言就是用面向对象的方式抽象了整个世界Java是一种面向对象的编程语言，c是一种面向过程的编程语言。,java编程语言中有两个很重要的概念：类和对象。类是什么？类就是对事物的抽象，包含两部分，一部分是类的属性，一部分是类的动作。比如：鸟就是一个类，可以有翅

2、膀的属性，可有羽毛的属性等等，还有可以有飞的动作，站立走动的动作等等。而对象呢是对类的具体实现。比如：某一只鸟就是鸟对象的实例。,什么是类和对象?,面向对象,什么是面向对象？,4,.,人开门，这个动作涉及到了两个事物，人和门，所有我们需要抽象出两个具体的类，人类和门类。,对象和动作,人class,门class,开门,面向对象,人开门,对象人只需要一个名字的属性。,想想开门的动作就是把门的状态从关着的状态转化为开着的状态，如：门的角度发生变化，门侧边的位置发生变化等等，我们就是最简单的记录门的状态发生变化，门类有一个属性是记录现在是开门状态还是关门状态。,开门这动作呢？这个动作及这个方法是人需要

3、有的动作还是门的动作？可能有些人这里就会有分歧了，有的人说开门这个动作是人类里面的方法，有的人可能认为这是门类需要有的方法。这里其实涉及到面向对象的一个重要的设计原则了，及谁有属性，对属性的操作就应该是谁的，门的状态这个属性既然是门的那么开门这个动作就应该是门类应该有的。,5,.,总结：面向对象的编程思维，就是要求我们把事物分成两部分：属性和动作，对属性的动作一定是归属于属性的所有者，及：人开门，开门这个动作的描述是：门的状态发生改变，门的状态这个属性是属于门的，所以开门这个动作也将是门的动作！理解了这一点，你会发现：人踢球，手拿包，去上学等等真是世界的各种动作，活动都可以在程序的世界中展示了

4、，属性越多，越全，对真实情景的描述就越真实！,面向对象,6,.,高内聚,高内聚：类内部的方法而言，把程序的功能尽量紧密联系，不要在一个类里只写一个或很长的方法，因为那样会给你的调试等带来很多问题。出了错你都不知道在什么地方。通俗说，就是尽量避免一个类中只有一个或把好几个方法都堆在一起写，这样容易出错，不易找到关键问题。.,低耦合,类与类之间的关系要简单，明了，不要有很强的关系，不然，运行起来就会出问题。一个类的运行影响到其他的类。一个完整的系统，模块与模块之间，尽可能的使其独立存在。也就是说，让每个模块，尽可能的独立完成某个特定的子功能。模块与模块之间的接口，尽量的少而简单。如果某两个模块间的

5、关系比较复杂的话，最好首先考虑进一步的模块划分。这样有利于修改和组合。通俗说，就是尽量减少一个类和另一个类之间的关系，不然，一个类出了问题，别的类也会跟着连带,面向对象封装应遵循的原则,7,.,心态、习惯、成长,02,心态、习惯、总结、成长,8,.,心态和习惯,软件开发所需的知识表现为一个特点：多熟悉或精通几个知识点是不足以体现出实力的提升，往往需要日积月累掌握相当数量的知识点，最后才能表现出实力。所以，这就要求你必须不急不燥认真学习、实践相关的知识，当这种积累达到一定程度的时候你就会明显感觉实力有所增强，而这种实力增强的周期通常在半年到一年半，如果一个人没有相当的毅力和良好的心态，急于求成，

6、学习的时候东一下西一下往往不能见成效，日子一久，就会逐渐丧失对知识、对技术的追求热情，最后不知不觉在竞争中被淘汰，或是处于很平常的状态。所以良好的心态和学习习惯是从事软件开发的第二个必备条件。,心态,9,.,心态和习惯,软件开发所涉及的知识和方面是非常广泛的，包括行业领域知识、技术知识、为人处世等各方面的知识。软件行业的思想和门派也五花八门，如果我们见风跟风见雨跟雨，通常是行不通的。其实无论软件开发涉及多广泛的知识，但它始终跳不出一个基本出发点，那就是：它都是为了做好软件，获得经济效益。所以，在软件开发的过程中，只要我们根据具体情况，认真分析问题、积累解决问题的有效手段，一般来说在公司里生存都

7、不会有太大的问题。这种积累越多，你就会发现良性循环的效益越大。如果不分析总结你可能会陷入失败再失败的恶性循环，即使你参与了一个成功开发的案例，往往也不知道之所以成功的原因，到哪天自己组织项目时还是感觉力不从心。对个人而言，无论是成功或失败的案例都是很宝贵的，失败的案例通常能提供给我们更多的教训，让我们在以后的软件开发中遇到类似问题时不再重蹈覆辙，甚至你从这些失败中提炼出了很有价值的问题，然后找到了很好的解决办法，间接从失败中获得了经验。成功的案例直接就给你提供了很多有益的参考。所以成功和失败是辩证的，关键是看我们如何吸收它所蕴含的财富。,习惯,10,.,面向技术点阶段,面向框架阶段,面对团队阶

8、段,面向问题阶段,开发的成长阶段,01,02,03,04,成长阶段,11,.,开发的成长阶段,首先踏踏实实把一些常用的技术点认真消化、深入理解、深入实践，为以后的发展积累良好的基础。对技术点的积累，你既要兼顾工作中的需要也要兼顾将来的发展，既不能完全被所在的环境束缚于一隅，也不能背离现实而一味追求知识面的扩张。你必须明白一个道理，只有工作相对愉快的前提下你才能有更高的学习效率，所以，首先把“工作上需要的技能”解决的情况下，才进行知识技能的扩张。知识技能的积累发展，通常也有一个过程，“想到(理论水平)能做到(可能水平)做到(极限实战水平)熟练做到(常态水平)”。对于很多常用的知识只有达到“常态水

9、平”才有实际意义，所以在学习、实践的过程中要注意体会、总结知识的应用特性，把那些需要达到常态水平的知识提炼出来，加强理解和运用，力争达到熟练状态。俗话说“学海无涯”，特别是软件开发这行，也可以算得上“博大精深”，我个人认为，应该以“如何能更有效的掌握知识，就如何去做”为主要指导思想，这样才能加速知识的学习进度。比如说，对你所在的环境而言，你向别人请教，能比你自己去研究更有效，你就应该优先考虑向别人请教，而不是放不下面子，自己花大量时间研究。如果你能认同这种“指导思想”，至少你能克服性格的上的缺陷，不是性格完全决定你的行为方式，而是主动根据需要去改变自己的行为方式，做事的时候也更能把握主次，懂得

10、如何取舍(比如：你舍点“面子”取得的是“知识”）。,01,面向技术点阶段,12,.,开发的成长阶段,当软件技能发展到一定阶段的时候，你会发现要做好一个项目往往不是有足够的技术点就能成功的。这个时候你会发现一个东西即使做出来了，也还有质量高低之分，质量高低在维护修改时，就能明显体现出来。然后你会关注如何写代码，如何让代码结构良好工整，如果不出意外，通常你会开始进行结构研究，最后过渡到框架。在达到这个阶段后，你就已经完成了从“只管做出来”，到关注“如何做比较好”的升级。这个阶段你大致会接触设计模式、组件化编程这样一些理念，并在思想和形式上有不同程度的运用，这个时候你基本上够格成为一个团队的主力了。

11、,02,面向框架阶段,03,13,.,开发的成长阶段,当你在技能上趋于成熟，框架上趋于成形的时候，你自然会想大家都按你的成果来展开工作，这个时候你会发现很多的矛盾和冲突。你会发现原来一个东西“自己会做”和“让别人也愿意这么做”之间有如此大的差距。如果你善于分析总结，你会发现：研究框架必须面向团队，它必须易于接受，真实的减少大家的工作量，明显示提升项目质量，对项目起到实质性的推进。否则，可能你的框架仅仅是为技术而技术，不是过于做作而显复杂，就是过于简单而没有“包容变化”的能力。“团队”应该是能互相影响，互相提高，个人技能能比较顺利的转化为“其它成员（即团队）”的技能。这样的环境才算得上是团队。,

12、03,面向团队阶段,14,.,开发的成长阶段,当你的技术在框架层面游弋一段时间后，你通常就会成一个经理、项目经理、或是技术Leader，这个时候你会发现，你手下会有很多不同特色的成员，面对项目“公说这么做，婆说那么做”争论不休。团队里人际关系也变得重要起来，对上要能交得了差，对下要能让大家认真做起来。这个时候，你不要昏了头，乱了分寸，你可以用“面向问题”的思维方式来处理这些问题。把握最本质的东西，把问题找出来，拆解问题，找最有效的手段，逐步解决问题，而不要为了运用技术或理念而争论不休，这个时候你要分析“要解决的问题”是不是有价值的？所倡导的技术或理念是不是能有效解决问题？一切皆从问题起，无论用

13、什么理念或技术，它一定是有目标的，如果它的目标和我们要解决的问题不一致，也就不用争论了。所以，找到“最有效的问题，最有效的解决手段”才经得起实践的检验。这个有效性包括“我们的问题确立是否有效？技术或理念是否和我们的目标一致？我们的团队有没这种技术或理念的驾御能力？在短期利益和长期利益之间如何取得平衡？”。无论多么先进的东西，不管出于什么样的原因，只要它不能解决问题都是“废物”。“面向问题”不仅适用于软件开发，还适用于处理生活上的其它事情。其实，它有点类似于武侠书中的“见招拆招”即无招，但并不等价于不懂招。,04,面向问题阶段,15,.,编程的智慧,编程是一种创造性的工作，是一门艺术。精通任何一

14、门艺术，都需要很多的练习和领悟，所以这里提出的“智慧”，并不是号称一天瘦十斤的减肥药，它并不能代替你自己的勤奋。然而由于软件行业喜欢标新立异，喜欢把简单的事情搞复杂，我希望这些文字能给迷惑中的人们指出一些正确的方向，让他们少走一些弯路，基本做到一分耕耘一分收获。作者：正义的花生,03,16,.,提高编程水平最有效的办法是什么？是反反复复地修改和推敲代码。有些人喜欢炫耀自己写了多少多少万行的代码，仿佛代码的数量是衡量编程水平的标准。然而，如果你总是匆匆写出代码，却从来不回头去推敲，修改和提炼，其实是不可能提高编程水平的。你会制造出越来越多平庸甚至糟糕的代码。在这种意义上，很多人所谓的“工作经验”

15、，跟他代码的质量，其实不一定成正比。如果有几十年的工作经验，却从来不回头去提炼和反思自己的代码，那么他也许还不如一个只有一两年经验，却喜欢反复推敲，仔细领悟的人。有位文豪说得好：“看一个作家的水平，不是看他发表了多少文字，而要看他的废纸篓里扔掉了多少。”我觉得同样的理论适用于编程。好的程序员，他们删掉的代码，比留下来的还要多很多。如果你看见一个人写了很多代码，却没有删掉多少，那他的代码一定有很多垃圾。就像文学作品一样，代码是不可能一蹴而就的。灵感似乎总是零零星星，陆陆续续到来的。任何人都不可能一笔呵成，就算再厉害的程序员，也需要经过一段时间，才能发现最简单优雅的写法。有时候你反复提炼一段代码，

16、觉得到了顶峰，没法再改进了，可是过了几个月再回头来看，又发现好多可以改进和简化的地方。这跟写文章一模一样，回头看几个月或者几年前写的东西，你总能发现一些改进。,编程的智慧,反复推敲代码,17,.,人们都讨厌“面条代码”（spaghetticode），因为它就像面条一样绕来绕去，没法理清头绪。那么优雅的代码一般是什么形状的呢？经过多年的观察，我发现优雅的代码，在形状上有一些明显的特征。如果我们忽略具体的内容，从大体结构上来看，优雅的代码看起来就像是一些整整齐齐，套在一起的盒子。如果跟整理房间做一个类比，就很容易理解。如果你把所有物品都丢在一个很大的抽屉里，那么它们就会全都混在一起。你就很难整理，

17、很难迅速的找到需要的东西。但是如果你在抽屉里再放几个小盒子，把物品分门别类放进去，那么它们就不会到处乱跑，你就可以比较容易的找到和管理它们。优雅的代码的另一个特征是，它的逻辑大体上看起来，是枝丫分明的树状结构（tree）。这是因为程序所做的几乎一切事情，都是信息的传递和分支。你可以把代码看成是一个电路，电流经过导线，分流或者汇合。,编程的智慧,写优雅的代码,18,.,编程的智慧,写模块化的代码,避免写太长的函数。如果发现函数太大了，就应该把它拆分成几个更小的。通常我写的函数长度都不超过40行。对比一下，一般笔记本电脑屏幕所能容纳的代码行数是50行。我可以一目了然的看见一个40行的函数，而不需要

18、滚屏。只有40行而不是50行的原因是，我的眼球不转的话，最大的视角只看得到40行代码。如果我看代码不转眼球的话，我就能把整片代码完整的映射到我的视觉神经里，这样就算忽然闭上眼睛，我也能看得见这段代码。我发现闭上眼睛的时候，大脑能够更加有效地处理代码，你能想象这段代码可以变成什么其它的形状。40行并不是一个很大的限制，因为函数里面比较复杂的部分，往往早就被我提取出去，做成了更小的函数，然后从原来的函数里面调用。,01,19,.,编程的智慧,写模块化的代码,制造小的工具函数。如果你仔细观察代码，就会发现其实里面有很多的重复。这些常用的代码，不管它有多短，提取出去做成函数，都可能是会有好处的。有些帮

19、助函数也许就只有两行，然而它们却能大大简化主要函数里面的逻辑。有些人不喜欢使用小的函数，因为他们想避免函数调用的开销，结果他们写出几百行之大的函数。这是一种过时的观念。现代的编译器都能自动的把小的函数内联（inline）到调用它的地方，所以根本不产生函数调用，也就不会产生任何多余的开销。同样的一些人，也爱使用宏（macro）来代替小函数，这也是一种过时的观念。在早期的C语言编译器里，只有宏是静态“内联”的，所以他们使用宏，其实是为了达到内联的目的。然而能否内联，其实并不是宏与函数的根本区别。宏与函数有着巨大的区别（这个我以后再讲），应该尽量避免使用宏。为了内联而使用宏，其实是滥用了宏，这会引起

20、各种各样的麻烦，比如使程序难以理解，难以调试，容易出错等等。,02,20,.,编程的智慧,写可读的代码,有些人以为写很多注释就可以让代码更加可读，然而却发现事与愿违。注释不但没能让代码变得可读，反而由于大量的注释充斥在代码中间，让程序变得障眼难读。而且代码的逻辑一旦修改，就会有很多的注释变得过时，需要更新。修改注释是相当大的负担，所以大量的注释，反而成为了妨碍改进代码的绊脚石。实际上，真正优雅可读的代码，是几乎不需要注释的。如果你发现需要写很多注释，那么你的代码肯定是含混晦涩，逻辑不清晰的。其实，程序语言相比自然语言，是更加强大而严谨的，它其实具有自然语言最主要的元素：主语，谓语，宾语，名词，

21、动词，如果，那么，否则，是，不是，所以如果你充分利用了程序语言的表达能力，你完全可以用程序本身来表达它到底在干什么，而不需要自然语言的辅助。有少数的时候，你也许会为了绕过其他一些代码的设计问题，采用一些违反直觉的作法。这时候你可以使用很短注释，说明为什么要写成那奇怪的样子。这样的情况应该少出现，否则这意味着整个代码的设计都有问题。如果没能合理利用程序语言提供的优势，你会发现程序还是很难懂，以至于需要写注释。所以我现在告诉你一些要点，也许可以帮助你大大减少写注释的必要：,21,.,编程的智慧,写可读的代码,使用有意义的函数和变量名字。如果你的函数和变量的名字，能够切实的描述它们的逻辑，那么你就不

22、需要写注释来解释它在干什么。比如：由于函数名put，加上两个有意义的变量名elephant1和fridge2，已经说明了这是在干什么（把大象放进冰箱），所以上面那句注释完全没有必要。,01,22,.,编程的智慧,写可读的代码,局部变量应该尽量接近使用它的地方。有些人喜欢在函数最开头定义很多局部变量，然后在下面很远的地方使用它，就像这个样子。由于这中间都没有使用过index，也没有改变过它所依赖的数据，所以这个变量定义，其实可以挪到接近使用它的地方。这样读者看到bar(index)，不需要向上看很远就能发现index是如何算出来的。而且这种短距离，可以加强读者对于这里的“计算顺序”的理解。否则如

23、果index在顶上，读者可能会怀疑，它其实保存了某种会变化的数据，或者它后来又被修改过。如果index放在下面，读者就清楚的知道，index并不是保存了什么可变的值，而且它算出来之后就没变过。如果你看透了局部变量的本质它们就是电路里的导线，那你就能更好的理解近距离的好处。变量定义离用的地方越近，导线的长度就越短。你不需要摸着一根导线，绕来绕去找很远，就能发现接收它的端口，这样的电路就更容易理解。,02,23,.,编程的智慧,写可读的代码,局部变量名字应该简短。因为它们处于局部，再加上第2点已经把它放到离使用位置尽量近的地方，所以根据上下文你就会容易知道它的意思：比如，你有一个局部变量，表示一个

24、操作是否成功。这个局部变量successInDeleteFile大可不必这么啰嗦。因为它只用过一次，而且用它的地方就在下面一行，所以读者可以轻松发现它是deleteFile返回的结果。如果你把它改名为success，其实读者根据一点上下文，也知道它表示“successindeleteFile”。所以你可以把它改成这样：这样的写法不但没漏掉任何有用的语义信息，而且更加易读。successInDeleteFile这种“camelCase”，如果超过了三个单词连在一起，其实是很碍眼的东西。所以如果你能用一个单词表示同样的意义，那当然更好。,03,24,.,编程的智慧,写可读的代码,不要重用局部变量。

25、很多人写代码不喜欢定义新的局部变量，而喜欢“重用”同一个局部变量，通过反复对它们进行赋值，来表示完全不同意思。比如这样写：虽然这样在逻辑上是没有问题的，然而却不易理解，容易混淆。变量msg两次被赋值，表示完全不同的两个值。它们立即被使用，没有传递到其它地方去。这种赋值的做法，把局部变量的作用域不必要的增大，让人以为它可能在将来改变，也许会在其它地方被使用。更好的做法，其实是定义两个变量：由于这两个msg变量的作用域仅限于它们所处的if语句分支，你可以很清楚的看到这两个msg被使用的范围，而且知道它们之间没有任何关系。,04,25,.,编程的智慧,写可读的代码,把复杂的逻辑提取出

26、去，做成“帮助函数”。有些人写的函数很长，以至于看不清楚里面的语句在干什么，所以他们误以为需要写注释。如果你仔细观察这些代码，就会发现不清晰的那片代码，往往可以被提取出去，做成一个函数，然后在原来的地方调用。由于函数有一个名字，这样你就可以使用有意义的函数名来代替注释。举一个例子：如果你把这片代码提出去定义成一个函数，原来的代码就可以改成：.put(elephant1,fridge2);更加清晰，而且注释也没必要了。,05,26,.,编程的智慧,写可读的代码,把复杂的表达式提取出去，做成中间变量。有些人听说“函数式编程”是个好东西，也不理解它的真正含义，就在代码里大量使用嵌套的函数。像这样：这

27、样的代码一行太长，而且嵌套太多，不容易看清楚。其实训练有素的函数式程序员，都知道中间变量的好处，不会盲目的使用嵌套的函数。他们会把这代码变成这样：Crustcrust=crust(salt(),butter();Toppingtopping=topping(onion(),tomato(),sausage();Pizzapizza=makePizza(crust,topping);这样写，不但有效地控制了单行代码的长度，而且由于引入的中间变量具有“意义”，步骤清晰，变得很容易理解。,06,27,.,编程的智慧,写可读的代码,在合理的地方换行。对于绝大部分的程序语言，代码的逻辑是和空白字符无关的，所以你可以在几乎任何地方换行，你也可以不换行。这样的语言设计是个好东西，因为它给了程序员自由控制自己代码格式的能力。然而，它也引起了一些问题，因为很多人不知道