#### 用句柄操作对象 通过创建句柄，可以对对象进行联系。比如：String s； 但此时s没有与任何对象进行连接，所以并没有指明对象是什么，此时需要赋初值：String s=”safsa“； 当然，一般写成：String s = new String(“fafafa”); #### 对象保存地址 Java对象一般保存在堆空间中。一种常规用途的内存池（也在RAM 区域），其中保存了Java 对象。和堆栈不同，“内存堆”或“堆”（Heap）最吸引人的地方在于编译器不必知道要从堆里分配多少存储空间，也不必知道存储的数据要在堆里停留多长的时间。因此，用堆保存数据时会得到更大的灵活性。要求创建一个对象时，只需用new 命令编制相关的代码即可。 #### 关于对象的清除 对象的作用域： Java中拒绝这样的写法： ~~~ { int x = 12; { int x = 96; } } ~~~ 编译器会认为x已经被定义。 在Java中，存在着一个特别的垃圾回收器，会自动查找用new创建的所有对象，若发现存在闲置的、不被使用的对象，则自动释放由闲置对象所占用的内存，以便由新对象使用。这样做很方便的解决了C++中的内存溢出问题。

在Java中，每个对象都必须有“资源”才能够生存，最重要的资源就是内存。 一般来说，如果一个对象被创建，则自动为其分配相应的存储空间；如果不再被使用，则清除其内存。 在C++中对象创建在堆栈中，对象可以自动清除；在Java中，由于有垃圾回收器的存在，也可以自动释放对象占据的内存空间。 但是在Java中，垃圾回收器的启动和执行时间是一个问题，所以在特殊的、执行连贯任务的场合要避免使用。 关于Exception： Exception是一开始就封装好的模块，由于采用的是独立的执行路径，所以不会干扰我们的常规执行代码。这样便使代码的编写变得更加简单，因为不必经常性强制检查代码。 注意违例控制并不属于一种面向对象的特性，尽管在面向对象的程序设计语言中，违例通常是用一个对象表示的。早在面向对象语言问世以前，违例控制就已经存在了。

原文地址：[点击打开链接](http://blog.csdn.net/lz201234/article/details/44774647) 代码中到处都需要命名。作为程序员，我们得给类命名，给变量命名，给函数命名，给参数命名，给命名空间命名，等等等等。下面有20条小贴士能帮助你提高你的命名能力。 ### 1.使用能够表达意图的名字 名字得能告诉我们它要做什么，为什么存在，以及是如何工作的。选择能够表达意图的名字，将更有利于我们理解代码。 **[html]**[view plain](http://blog.csdn.net/lz201234/article/details/44774647# "view plain")[copy](http://blog.csdn.net/lz201234/article/details/44774647# "copy") 1. int d; // elapsed time in days   1.    1. int elapsedTimeInDays;   1. int daysSinceCreation;   1. int daysSinceModification;   1. int fileAgeInDays;   在上面的片段中，我们只能从注释中知道变量d指的是什么。于是阅读代码的人为了知道它的含义就不得不去寻找它的实例以获取线索。所以，要是我们能够好好命名这个变量，阅读代码的人就能够瞬间知道这变量的含义。 ### 2.不要怕在选择名字上花时间 你应该多试几种不同的名字，直至足以描述其含义，千万不要害怕在这上面花时间。以后阅读你代码的人（包括你自己）将会因此而受益。此外，一个描述性的名称甚至还能有助于你在心中理清模块的设计。良好的命名的确需要花费时间，但是从长远来看，利大于弊。 ### 3.重构名字 如果你在后面的开发过程中想到了一个更好的名字，那就不要犹豫，马上去改吧。现在的IDE使得重构名字变得异常容易。 ### 4.避免在名字中出现干扰词 比如Manager、Processor、Data、Info以及“我不知道这叫什么”的同义词，都是干扰词。如果你需要使用上面这些干扰词的话，那么说明你的命名可能太累赘了。 ### 5.小心难以命名的类/功能 一个很难命名的类或函数很有可能是一个代码异味。这说明： - 代码做得太多。 - 代码做得还不够。 - 你对此问题理解得还不够透彻，需要先获取更多的信息。 ### 6.类名 类应该有个名词或名词词组的名字，如Customer、WikiPage、Account和AddressParser。继承性父类应该给个又短又有冲击力的名字。子类的名字应该长点，通过形容词来描述其不同于它的父类之处，如SavingsAccount衍生于Account。 ### 7.变量名 变量名也应该是名词。它们大多是由其指向的类衍生出去的。布尔变量应写成谓词的形式，如isEmpty和isTerminated，这样放到if语句才便于理解。 ### 8.方法名 方法名应该是一个动词或动词词组，如postPayment()、deletePage()和save()。访问器和调整器应该分别前缀get和set。返回布尔值的方法应该前缀‘is’，如isPostable()，这样在if语句中才便于理解。 ### 9.范围大小与变量名的长度 变量名的长度应和它的范围大小相匹配。如果变量的范围很短，那么变量名的长度也应该很短。反之，变量名则应该长一点，更有描述性。 ### 10.范围大小与方法/类名的长度 对于方法和类名的长度则应该与其范围成反比。对于公共方法，短一点的名字会比较好，这是因为它们会被调用多次。私有方法只在类的范围内被调用，长一点的名字反而可以作为文档使用。此条规则的例外是派生类的名字。类越派生，基类前所加的形容词就越多，名字也就越长。 ### 11.一个概念一个词 为某个抽象概念选定一个词，然后就不要变了。例如作为不同类中的等效方法，get()、fetch()和retrieve()会让人混淆起来。保持一致的词汇是程序员驾驭代码的重要工具。 ### 12.不要将同一个词用于两个不同的概念 如果你遵循第11点——一个概念一个词的原则，那么就可以避免许多有着相同方法名的类。只要参数列表和各种方法的返回值在语义上是等价的就没问题。只有当你将同一个词用于两个不同的概念时才会出现问题。 例如，我们可以在多个类中使用add()方法，通过添加或连接两个现有的值来创建一个新的值。如果我们之后又需要在类中引入一个add方法用于添加参数到集合中，这就会因为语义不同而导致问题。这种新方法最好是改叫为insert()。 ### 13.使用解决方案领域的名字 我们编写的代码今后可能会有其他程序员来阅读，所以我们使用一些技术术语进行代码命名会带来很大的好处。比如适当地使用算法名字、设计模式名字以及数学术语，这些命名方式很可能会让其他程序员更容易理解程序，引起共鸣。 ### 14.使用问题领域的名字 如果实在找不到易于理解的技术术语来命名，那么也可以从问题领域来寻找合适的代码命名。当未来阅读你代码的程序员不确定代码意义的时候，这将为他们提供一些问题的线索。 ### 15.添加有意义的语境 大多数名字其本身是没有意义的，并且需要放到语境（类/函数/命名空间）中，才能让阅读代码的人理解它们指代的是什么。在某些情况下，可能需要前缀名称以补充语境。例如，假设我们有一些用来表示地址的变量：firstName、lastName、street、houseNumber、city、state和zip。如果只看state这个变量，我们是很难推断出它指的是什么意思，一个比较好的解决办法就是将这些变量封装到Address类中。 ### 16.不要添加没来由的语境 只要意思明确，短一点的名字通常比长的好，所以不要多此一举地添加语境。名字前不应该被加缀一些可以从类/包/命名空间中推断的不必要的信息。 ### 17.避免编码 鉴于现在的IDE的强大，我们已经不需要编码类型和范围信息到变量名和类名中。这包括不必添加I至接口，因为使用代码的用户不需要知道他们的类正在向接口传递。所以如果你一定要使用编码，那么最好是对实现进行编码而不是接口。 ### 18.避免错误的信息 不要给一些错误的信息，因为这样会误导阅读代码的人。如果你将一个实际支持数组的变量命名为accountList，那就很容易让人得出错误的结论。 ### 19.使用读不出来的名字 编程是一个社会化的活动，使用那些读不出来的名字只会阻碍我们的讨论。 ### 20.使用易搜索的名字 使用短而通用的名字会妨碍我们在代码库中搜索事物。这对我们操纵代码和重构很有影响。 最后，你的代码一定可以完美的完成了，当然还有其他重要的步骤，那就是给[代码加层壳](http://t.cn/Rz0bhUA)，即[加密保护](http://t.cn/zQ6JvmN)！不要让自己好不容易辛辛苦苦写出来的代码开发好的程序为他人所利用，防患于未然！

原文地址：[点击打开链接](http://blog.csdn.net/jackfrued/article/details/44456495) 最近在网上看了一个非常好的帖子《程序员一生必读的书》（[我的腾讯微博](http://t.qq.com/jackfrued)上有分享该贴子链接，有兴趣就点击进去看看吧），该贴的第一个张图片是一个雷达图， 这张图是由ThoughtWorks（全球软件设计与定制领域的领袖级企业）的资深人士提供的，它将程序员要读的书分为四个类别，每个类别又分为初级、进阶和高级读物，并用黄色三角形点出了强烈推荐阅读的书籍。四个类别包括： - 编程实践（Coding Practice） - 设计与架构（Design & Architecture） - 方法学（Methodology） - 思想与领导力（Thought & Leadership）  相信这张图会帮助到很多迷茫的职业人，因为好书就像明灯一样会照亮我们的方向，那些大师级的人物将他们的经验分享给我们，真的有如浴春风的感觉。有时候会很感慨国外有那么多厉害的技术作家写了那么多好的作品，而国产技术书籍中的好书真算得上是凤毛麟角。有时候也会问自己，能不能做一个技术作家呢，我想我的修炼还远远不够。  虽然不能够自己写一本好书，但是还是很愿意把自己的读书心得跟大家一起分享，雷达图上的书我读过的约有1/3，下面就把读这1/3的心得跟大家分享。 ### Code Complete 《代码大全》  ### Refactoring《重构：改善既有代码质量》    如果一个人没有听说过《重构》这本书，那么他一定不敢说自己是程序员；如果一个人没有阅读过《重构》这本书，那么很难想象他会是一名优秀的程序员。这本书是很多公司要求Java程序员必读的三本书之一（另外两本书是《Java编程思想》和《Effective Java》），其实无关编程语言，是程序员就能够从这本书中受益。    这本书我个人最喜欢的第三章 - “代码的坏味道”，因为我喜欢在写完代码后去思考我的代码中有没有这些坏味道，然后再去想一想应该如何重构代码。这本书的作者是世界级的软件开发大师Martin Fowler，他也被誉为软件开发“教父”，同时他还是敏捷开发的创始人之一。Martin Fowler编写了很多极好的书籍，包括《企业应用架构模式》、《领域特定语言》、《NoSQL精粹》、《分析模式：可重用对象模型》等。Martin Fowler给出的代码的坏味道包括：  -Duplicated Code（重复代码）：“代码有很多中坏味道，重复是最坏的一种”，这句话我经常讲给自己的学生听，但是他们真正领悟并践行这句话的人却不多。一个类中的两个方法有重复代码，那么一定可以通过抽取方法的方式将重复代码放到另一个方法中以供调用；两个互为兄弟的子类中如果有重复代码可以将其重复代码抽取到父类中；两个没有关系的类中如果有重复代码，那么可以重新抽取一个类将重复代码放到这个第三方类中。  -Long Method（长的方法）：程序越长理解起来就越困难，这已经是常识了，使用短小的方法首先符合高内聚的要求，同时也可以给通过给方法起一个好的名字来帮助理解方法的作用。如果感觉到方法的某个地方需要注释来说明什么，那么可以把这些东西放入一个独立的方法中，并以用途（注意不是实现手法）来命名方法。  -Large Class（巨大的类）：如果希望写一个类来做很多的事情，那么最终势必导致重复和混乱的代码。类的设计应当遵循单一职责原则（SRP）。重构一个巨大的类可以使用抽取接口的方式来搞清楚这个类应该如何分解。  -Long Parameter List（长参数列表）：这个对于做过Windows编程或者用过MFC（Microsoft Foundation Class）的程序员来说再熟悉不过了，Windows函数和MFC中的方法那些长得变态的参数列表对程序员来说都是恶梦。重构的方式很多，比较常见的是将相关的参数组织成一个对象来替换掉这些参数。 -Divergent Change（分散的可变性）和Shotgun Surgery（散弹式手术）：这两种坏味道前者讲的是新功能难以加入，后者说的是某种变化会引发多个细节的修改。简单的说如果程序中的可变因素散落在代码的各个角落中，那么代码的维护将是一场恶梦。重构的方法是找到特定原因造成的所有变化，然后将它们抽取到另一个类中。设计模式中的桥梁模式就是为了解决这一问题而提供的解决方案。  -Feature Envy：这个真没想到如何翻译会比较容易理解，简答的说就是一个方法从另一个类的对象那里获取许多的值，重构的方案是将该方法移到另一个类中。  -Data Clumps（数据群集）：状况类似于长参数列表。  -Primitive Obsession（基本类型偏执）  -Switch Statements（重复的switch语句）：面向对象程序的一个明显特征就是用多态替换掉switch结构，因为这种switch结构会在多个地方重复。  -Parallel Inheritance Hierarchies（平行继承结构）：情况跟Shortgun Surgery差不多，可以使用桥梁模式进行重构。  -Lazy Class（冗余类）：如果一个类不值得存在，那么它就应该消失。  -Speculative Generality（投机通用性）：重构方式是如果你的抽象类、委托、方法的参数没有实际的作用，那么就应当被移除掉。  -Temporary Field（临时字段）  -Message Chains（消息链）：我个人并没有感觉到这个有多么坏。  -Middle Man（中间人）：如果一个类的很多功能都通过委托给其他类来完成，那么就不如去掉这些中间人直接和真正负责的对象打交道。  -Inappropriate Intimacy（过于亲密）  -Alternative Classes with Different Interfaces（异曲同工）  -Incomplete Library Class（不完整类库）  -Data Class（数据类）：类的退化结构。我们在分层开发中经常使用的失血模型（事务脚本模式）中的业务实体不就是数据类吗，这明显与面向对象的思想是背道而驰的。  -Refused Bequest（拒绝遗产）：如果子类复用了父类的行为，又不愿意支持父类的接口，可以考虑用合成关系聚合关系取代继承关系来消除这种坏味道  -Comments（注释劣质代码）：注释不是用来补救劣质代码的，事实上如果我们去除了代码中的所有坏味道，当劣质代码都被移除的时候，注释已经变得多余，因为代码已经讲清楚了一切。    如果你希望彻底根除这些坏味道，这本书的第六章到第十二章提供了完整的操作手册，赶紧读这本书吧! ### Clean Code 《代码整洁之道》    其实我应该先介绍下面那本书，喜欢下面那本书的原因是书中有很多非常精炼但是有用的Tip，这些Tip可以说是大师级的经验总结；而我个人喜欢这本书可能是因为非技术方面的原因（我喜欢这本书中的插图）。这本书的第一章的第一句话是这样说的：读这本书通常有两个原因：1. 你是一名程序员。2. 你想成为更好的程序员。我们需要更好的程序员。    这本书的每一章都可以总结出一句话或是一张图，就是下面这些：    本书的第一章是关于什么是整洁代码的讨论，引用了Bjarne Stroustrup（C++之父）、Grady Booch（UML的创始人之一）等人当然也Bob大叔（本书的作者Robert Martin）自己对整洁代码的理解。顺便说一下，上面那张图上的代码应该是保龄球计分程序（你必须佩服我的眼力）。    不管是现实世界还是软件项目中，命名都是一件让人头疼的事情，给小孩起过名字的就知道，你希望把你对孩子的期望包含在这个名字中，你又希望这个名字读起来要好听，至少不至于将来成为别人的笑柄（比如庞光大、魏升京这样的名字），可能你还要考虑族谱的排辈等等。软件项目中的命名情况会更加复杂，简单的说命名的原则是“见名知意”，当然你还需要用各种方式防范命名冲突的问题，不同的编程语言也有自己不成文的像契约一样的命名规则和方式（例如匈牙利命名法），这些可能都是需要考虑的事情。    第三章讲的是函数，说了这么一句话：Function should do one thing. They should do it well. They should do it only. （函数只应该做一件事情，把一件事情做好，而且只由它来做这一件事情），听起来很简单的一句话但是要践行这条原则却并不容易，所以我们的代码中才会有很多的坏味道（上一本书中提到的东西）。事实上，上升一个层次，我们在设计类的时候也应该如此，这是面向对象设计原则中说的单一职责原则（SRP），当我们的代码中出现了冗长的方法或者巨大的类的时候，我们就应该依据职责来对其进行拆分，这样程序的结构才会趋于合理，最终达到“高内聚”的目标。当然，这一章里面还提到很多理念，包括：Command Query Separation（一个方法要么执行某种命令，要么返回查询数据）、DRY（不要重复自己）、Prefer Exceptions to Returning Error Codes（异常优于返回错误码）等。    第四章讲的是注释，有一句话我很喜欢，说的是：Comments Do Not Make Up for Bad Code （注释不是对劣质代码的补救）。事实上好的代码即便没有注释也拥有良好的可读性，但恰当的注释会让代码变得更可读、可维护性更高。    第五章讲的是代码风格。现代IDE（集成开发环境）几乎都有代码格式化代码的功能，你只需要设置好你使用的代码风格就可以了，其实不只是IDE，很多高级的文本编辑工具也能够按照指定的风格格式化你的代码。用什么样的代码风格不是关键，关键是整个项目组的成员应当使用相同的代码风格，让多个人编写的代码看起来像一个人书写的。我个人特别钟爱1TBS（One True Bracing Style，也叫做K&R风格，这种风格是Kernighan和Ritchie两位老师在The C Programming Language一书中使用的代码风格），当然Allman风格（FreeBSD系统的作者之一使用的代码风格）也是很好的选择。    第六章讨论的是对象和数据结构，读完之后的感觉是虽然我们天天都嚷着吼着要面向对象编程，但是很多时候我们都使用了类的退化结构，包括我们开发时经常使用的失血模型和贫血模型（事务脚本模式）都和面向对象的设计理念相违背。我得承认在读这一章的时候我没有太抓住作者的观点，也欢迎大家来帮助我理解这章的内容。    第七章对错误处理（异常）的讲解仍然是非常精彩的，整洁的代码中对错误的处理应当是被分离的关注点（不要跟正常的业务逻辑混杂在一起），而面向对象中的异常机制就是一种在不打乱原有业务逻辑的前提下处理掉程序在运行时发生的不正常状况的手段。这章有两个观点我特别欣赏，一是Use Unchecked Exceptions（非受检异常允许你在适当的地方处理异常，而适当的地方就是异常影响代码执行逻辑的地方，不管做哪种类型的应用，都应该尽可能向用户隐藏异常的发生，除非发生了不可挽救的状况，这才是符合最小惊讶原则的设计）；二是Don’t Return Null（如果一个方法在出状况的时候返回null，那么调用者都要通过频繁的检查返回值来判定是否出错，一旦忘了这件事情就有可能出错，既然null是一种异常状况，那么用抛出异常的方式来代替null明显是更好的做法）。    第八章的内容对实际开发有重要的指导意义，因为我们的项目中不可避免的要使用第三方工具，因此我们需要将这些东西整洁的纳入到我们的系统中，这时就需要考虑系统边界的问题。有的时候我们会千辛万苦的发现系统中的一些bug是来源于第三方工具的，当然我们基本上没有时间去重头学习和研究第三方工具或者自己写代码来实现第三方工具的功能，但是我们至少应该先对第三方工具进行测试。我在以前的项目中，即使用Apache提供的那些著名的第三方工具，我的做法也是先写测试代码对这些工具的可用性和有效性进行证实，当然有的时候可能是过于谨慎了，但这种习惯和做法本身是好的行为。在这种场景下，适配器模式是非常好的设计，它不仅能将不兼容的接口改写成兼容的接口，还能够对通过对第三方工具重新封装来避免边界的变化对系统的影响。    第九章的内容是单元测试。Bob大叔是TDD（测试驱动开发）的倡导者，这一章讲的是如何编写整洁的测试，Bob大叔的答案是FIRST规则（Fast、Independent、Repeatable、Self-Validating、Timely）。    第十章介绍类的设计，最重要的还是SRP。    第十一章是关于系统设计的内容，开篇引用了微软首席技术官Ray Ozzie的一句话：Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test. （复杂要人命，它消磨开发者的生命，让产品难于规划、构建和测试）。这章对于希望了解面向切面编程的开发者是极好的，包括了对依赖注入、代理模式以及AOP的探讨。    第十二章探讨了系统的迭代式演进。    第十三章对并发编程的讨论非常经常，很多开发者都畏惧并发编程，也有的开发者迷信多线程可以解决所有的并发问题，如果你是这两类人之一，本章会教给你真正的并发编程。    第十四章是一个精彩的案例用来讲解对代码的持续改进，你可以自己好好阅读一次。   第十五章到第十七章说的都是重构，相当精彩。你在《重构》中了解过的代码的坏味道及其改进方案这里几乎都能见到它是如何应用的。 总之，这本书从引言到附录都无比精彩，赶紧去阅读吧。 ### The Pragmatic Programmer: From Journeyman to Master 《程序员修炼之道：从小工到专家》    这本书最初出中文译本的时候，它的名字叫《务实的程序员》，而这本书也正像它书名的副标题那样，是一本带领程序员从小工成为行业专家的著作。这本书里有70个Tip（指点、提示），这些Tip都是短小精炼的句子，但都是大师们编程经验的总结和沉淀。因此不管什么时候看这本书，也不管你翻到第几页，总会发现这样的Tip，而它们也会让你有醍醐灌顶的感觉。下面分享了这本书部分的Tip： - Tip8: Invest Regularly in Your Knowledge Portfolio （定期为你的知识资产投资） - Tip9: Critically Analyze What You Read and Hear （批判的分析你读到的和听到的） - Tip10: It’s Both What You Say and the Way You Say It （你说什么和你怎样说同样重要） - Tip11: DRY - Don’t Repeat Yourself （不要重复自己） - Tip13: Eliminate Effects Between Unrelated Things （消除无关事物之间的影响） - Tip18: Estimate to Avoid Surprises （通过估计来避免意外发生） - Tip20: Keep Knowledge in Plain Text （用纯文本保存知识） - Tip23: Always Use Source Code Control （总是使用源码控制） - Tip27: Don’t Assume It - Prove It （不要假定要证明） - Tip29: Write Code That Writes Code （用代码生成代码） - Tip31: Design with Contracts （按照契约设计） - Tip33: If It Can’t Happen, Use Assertion to Ensure That It Won’t （用断言确保不能发生的不发生） - Tip38: Put Abstraction in Code, Details in Metadata （将抽象置于代码，细节置于元数据） - Tip39: Analyze Workflow to Improve Concurrency （分析工作流以改善并发性） - Tip42: Separate Views from Models （让视图和模型分离） - Tip63: Coding Ain’t Done ‘Til All the Tests Run （测试不通过编码不停止） - Tip69: Gently Exceed Your User’s Expectations （超出用户期望一点点就好）   除此之外，该书中有很多名人名言以及很多经验的分享，例如：“不要让调试改变了被调试系统的行为”、“异常尽量不被作为程序正常流程的一部分来使用”、“要有始有终，分配资源的程序也应当释放它”、“最大的弱点是害怕暴露弱点”等等。 当然，这本书也包括了对契约式编程、解耦合、重构、算法效率、测试等内容的探讨。    老实说，整本书的内容都很棒，附录也不例外，附录A中列出了一些作者推荐阅读的计算机书籍，这些书籍正好也出现在了我们给的这个必读书籍的列表中，真的是英雄所见略同（就算我臭美了一次哈） ### The Practice of Programming 《程序设计实践》  ### Design Patterns 《设计模式》  ### Domain-Driven Design 《领域驱动设计》  ### The Art of UNIX Programming 《UNIX编程艺术》    这本书是给予我无数次帮助的书籍，我会慢慢的把我读这本书的心得记录在这里。每次当我遇到问题不知所措的时候，这本书总是能给我答案；在我参加的所有面试中，只要有答不上来的问题，想想这本书中的一些只言片语就能在电光火石间发现答案。 ### Practical API Design 《软件框架设计的艺术》  ### Patterns of Enterprise Application Architecture 《企业应用架构模式》    还有很多好书可能因为选择标准的不同在雷达图中虽然没有出现，但是仍然值得每个程序员去阅读，这些好书包括： ### The C Programming Language 《C语言程序设计》    C语言之父Dennis Ritchie以及Brian Kernighan两位老师合著的神一样的书籍。我到现在都没有想明白为什么国内只有极少数的几所大学用这本书作为教材，难道C语言的入门书中还有出其右者吗？这本书的内容无比精彩，不管是对于初学者还是有经验的程序员；这本书中的代码无与伦比，几乎每一段代码都是经典。即使你还没有读过本书，但是你一定听说过一个叫Hello, world的程序，该程序就出现在这本书中。 ### The Mythical Man-Month 《人月神话》    这本书是号称软件工程领域的第一奇书，与《人件》合称为软件工程著作中的倚天剑和屠龙刀。Brooks博士为人们管理复杂项目提供了最具洞察力的见解。既有很多发人深省的观点，又有大量软件工程的实践，其内容都是来自Brooks博士在IBM公司System/360家族和OS/360中的项目管理经验。这本书是项目经理和系统分析师必读的不朽之作，也是流行了30多年的传奇经典。 ### Hackers and Painters 《黑客与画家》    该书是我最近几乎每天都翻翻的一本书，准确的说这本书是硅谷创业之父Paul Graham的文集，主要介绍优秀程序员（书中称之为黑客，当然这和我们尤其是国内对黑客的理解有所差别）的爱好和动机，讨论它们如何成长以及如何为世界做出贡献，当然也包括了对编程语言和优秀程序员工作方法等的探讨和思考。该书的内容不但有助于了解计算机编程的本质、互联网行业的规则，还会帮助读者了解我们这个时代，迫使读者独立思考。该书的中文版是阮一峰博士翻译的，翻译的水准和书中的旁注都相当好。 ### The Art of Computer Programming 《计算机程序设计艺术》     ### Introduction to Algorithms 《算法导论》  ### Object-Oriented Analysis and Design with Applications 《面向对象分析与设计》  除此之外，因为自己做了很长时间的Java程序员，有一些Java方面的好书可以推荐给大家 ### Thinking in Java 《Java编程思想》  ### Effective Java  ### 《Java与模式》  ### The Well-Grounded Java Developer 《Java程序员修炼之道》  ### POJOs in Action    其实国产的Java书籍里面也有部分优秀的书籍，虽然国产书的质量总体偏低，但是最近几年还是有很多有责任感的技术作家（他们很多人同时也是一线程序员或架构师）写了不少好书。 ### 《设计模式之禅》  ### 《编写高质量代码：改善Java程序的151个建议》  ### 《Spring 3.x企业应用开发实战》  ### 《Tomcat与Java Web开发技术详解》  ### 《疯狂Java：突破程序员基本功能的16课》    如果你以前不是计算机相关专业又想转型从事软件行业，那么我推荐先看一些专业气质养成类书籍，当然最入的书就是《计算机导论》、《计算机文化》之类的书，也可以看看《计算机科学概论》或者是《计算机专业英语》，建议看原版的，一方面对整个行业有一个全面的了解，另一方面锻炼一下自己的英语水平。无论如何，我觉得程序员还是应该让英语成为自己的工作语言。 ### Computer Concepts 《计算机文化》  ### Computer Science Illuminated 《计算机科学概论》  ### Computing Essentials 《计算机专业英语》    如果你希望从零基础开始做一个Java程序员，那么我建议的这些书的阅读顺序是这样的（每项读一本就OK了）： 1. Computer Concepts / Computer Science Illuminated 1. The C Programming Language 1. Core Java (Vol. 1 & Vol. 2) / Introduction to Java Programming 1. MySQL Crash Course / 深入浅出MySQL / Sams Teach Yourself SQL in 10 Minutes 1. Thinking in Java / Effective Java / 编写高质量代码：改善Java程序的151个建议 1. Servlet & JSP: A Tutorial / Head First Servlets & JSP 1. Java与模式 / Design Patterns Explained / 设计模式之禅 1. 精通Hibernate / Java Persistence with Hibernate 1. Spring in Action / Spring企业应用开发实战 / Spring技术内幕 1. Clean Code / Refactoring Impoving the Design of Existing Code 1. The Well-Grounded Java Developer 1. Algorithms / Data Structures and Algorithm Analysis in Java 1. POJOs in Action / Core J2EE Patterns: Best Practices and Design Strategies 1. Java Performance 1. Software Engineering A Practitioner’s Approach 说明：读书心得我只能一点点与大家分享和交流了，争取在一个月之内把这件事情搞定吧：）

1.关于抽象的进步。面向对象OOP的设计思路其实是把“抽象”这种编程方法进行了新的解释说明，把具体的人或事务抽象成了“类”“对象”的形式。 面向对象的主要思想： - 万物即对象 - 程序是对象的组合 - 每个对象都有自己的空间，可以容纳其他对象 - 每个对象都有自己的实例 - 同一类的所有对象都能接收相同的消息 2.对象的接口 通过类构造对象，对象开放给使用者接口，此时使用者可以通过类的对象的接口给对象发出请求。 3.面向对象编程要提供给两个使用者：类的创建者和使用者。类的创建者的职责是从头创建一个类，提供给使用者接口就好，而类的使用者（书中称之为客户程序员）直接拿来接口使用，而不需要了解这个类具体是什么构造。同时类的创建者也不用有顾虑怕类被破坏或者修改。 4.方案的重复使用 我们知道在面向对象中一个类的对象可以置入另外一个类中，这叫做“创建一个成员对象”，在新建类的时候，首先可以考虑把不同类的对象组织起来使用，可以有效减少代码的复杂度，减少不必要的继承。 5.继承的进一步解释 在以前的认识中，继承只是用来创建新类，和旧的类区别开来，书中对创建继承的必要性进行了一定的探讨： - 为什么要使用继承：要创建新的类和已有类功能相似，但是有一定的新功能，此时使用继承，把旧的类所有的成员继承到新类中，复制了旧类的接口 - 如何区分衍生类和旧类：a.为衍生的类增加新的函数，提供新的功能；b.改善基础类的现有函数 6.关于类型的上溯 这个概念这次深刻的理解了。 举例： 此时有一个这样的类的构造：  同时有这样的一个函数： ~~~ void doStuff(Shape s){ s.draw(); ... ... } ~~~ 此时如果定义了新的形状，则只需要指出该形状的类衍生于Shape类即可调用Shape类的函数： ~~~ Circle c = new Circle(); Triangle t = new Triangle(); Square s = new Square(); doStuff(c); doStuff(t); doStuff(s); ~~~ 这里把衍生的类当成了它的基础类型处理，这种方法就叫做Upcasting，只需要指出某个类所属的基本类型，即可让它执行基础类的具体功能。

> 原文出处：[《Thinking in Java》读书笔记](http://blog.csdn.net/column/details/mynotetij.html) 作者：[tryitboy](http://blog.csdn.net/tryitboy) **本系列文章经作者授权在看云整理发布，未经作者允许，请勿转载！** # 《Thinking in Java》读书笔记 > 我自己的《Thinking in Java》读书笔记