1.抽象的进步

所有编程语言的最终目的都是提供一种“抽象”方法。

汇编语言是对基础机器的少量抽象。后来的许多“命令式”语言（如FORTRAN，BASIC 和C）是对汇编语言的一种抽象。
与汇编语言相比，这些语言已有了长足的进步，但它们的抽象原理依然要求我们着重考虑计算机的结构，而非考虑问题本身的结构。在机器模型（位于“方案空间”）与实际解决的问题模型（位于“问题空间”）之间，程序员必须建立起一种联系。这个过程要求人们付出较大的精力，而且由于它脱离了编程语言本身的范围，造成程序代码很难编写，而且要花较大的代价进行维护。

为机器建模的另一个方法是为要解决的问题制作模型。对一些早期语言来说，如LISP 和APL，它们的做法是“从不同的角度观察世界”——“所有问题都归纳为列表”或“所有问题都归纳为算法”。PROLOG 则将所有问题都归纳为决策链。对于这些语言，我们认为它们一部分是面向基于“强制”的编程，另一部分则是专为处理图形符号设计的。每种方法都有自己特殊的用途，适合解决某一类的问题。

面向对象的程序设计在此基础上则跨出了一大步，程序员可利用一些工具表达问题空间内的元素。由于这种表达非常普遍，所以不必受限于特定类型的问题。我们将问题空间中的元素以及它们在方案空间的表示物称作“对象”（Object）。当然，还有一些在问题空间没有对应体的其他对象。通过添加新的对象类型，程序可进行灵活的调整，以便与特定的问题配合。所以在阅读方案的描述代码时，会读到对问题进行表达的话语。与我们以前见过的相比，这无疑是一种更加灵活、更加强大的语言抽象方法。总之，OOP 允许我们根据问题来描述问题，而不是根据方案。然而，仍有一个联系途径回到计算机。每个对象都类似一台小计算机；它们有自己的状态，而且可要求它们进行特定的操作。与现实世界的“对象”或者“物体”相比，编程“对象”与它们也存在共通的地方：它们都有自己的特征和行为。

2.对象的接口

当我们进行面向对象的程序设计时，面临的最大一项挑战性就是：如何在“问题空间”（问题实际存在的地方）的元素与“方案空间”（对实际问题进行建模的地方，如计算机）的元素之间建立理想的“一对一”对应或映射关系。

向对象发出的请求是通过它的“接口”（Interface）定义的，对象的“类型”或“类”则规定了它的接口形式。“类型”与“接口”的等价或对应关系是面向对象程序设计的基础。

3.实现方案的隐藏

对类创建者来说，他们的目标则是从头构建一个类，只向客户程序员开放有必要开放的东西（接口），其他所有细节都隐藏起来。为什么要这样做？隐藏之后，客户程序员就不能接触和改变那些细节，所以原创者不用担心自己的作品会受到非法修改，可确保它们不会对其他人造成影响。

“接口”（Interface）规定了可对一个特定的对象发出哪些请求。然而，必须在某个地方存在着一些代码，以便满足这些请求。这些代码与那些隐藏起来的数据便叫作“隐藏的实现”。一种类型含有与每种可能的请求关联起来的
函数。一旦向对象发出一个特定的请求，就会调用那个函数。我们通常将这个过程总结为向对象“发送一条消息”（提出一个请求）。对象的职责就是决定如何对这条消息作出反应（执行相应的代码）。

有两方面的原因促使我们控制对成员的访问。第一个原因是防止程序员接触他们不该接触的东西——通常是内部数据类型的设计思想。进行访问控制的第二个原因是允许库设计人员修改内部结构，不用担心它会对客户程序员造成什么影响。

相关知识点：public private protected friendly

4.方案的重复使用

新建类的时候，首先应考虑“组织”对象；这样做显得更加简单和灵活。利用对象的组织，我们的设计可保持清爽。
继承。

5. 继承：重新使用接口

衍生类具有与基础类相同的类型！为真正理解面向对象程序设计的含义，首先必须认识到这种类型的等价关系。
有两种做法可将新得的衍生类与原来的基础类区分开。第一种做法十分简单：为衍生类添加新函数（功能）
为区分我们的新类，第二个办法是改变基础类一个现有函数的行为。我们将其称作“改善”那个函数。

6. 多态对象的互换使用

将这种把衍生类型当作它的基本类型处理的过程叫作“Upcasting”（向上转型）。
将一条消息发给对象时，如果并不知道对方的具体类型是什么，但采取的行动同样是正确的，这种情况就叫作“多态性”（Polymorphism）。

设计程序时，我们经常都希望基础类只为自己的衍生类提供一个接口。也就是说，我们不想其他任何人实际创建基础类的一个对象，只向上转型成它，以便使用它们的接口。为达到这个目的，需要把那个类变成“抽象”的——使用abstract 关键字。
亦可用abstract 关键字描述一个尚未实现的方法——作为一个“根”使用。

7.对象的创建和存在时间

从技术角度说，OOP（面向对象程序设计）只是涉及抽象的数据类型、继承以及多态性，但另一些问题也可能显得非常重要。
最重要的问题之一是对象的创建及销毁方式。
另外一个问题，亦即对象的“存在时间”或者“生存时间”（Lifetime）。

7.1 集合与继承器

针对一个特定问题的解决，如果事先不知道需要多少个对象，或者它们的持续时间有多长，那么也不知道如何保存那些对象。
在需要的时候，集合会自动扩充自己，以便适应我们在其中置入的任何东西。所以我们事先不必知道要在一个集合里容下多少东西。只需创建一个集合，以后的工作让它自己负责好了。
由于抽象是通过继承器进行的，所以能在两者方便地切换，对代码的影响则显得微不足道。

7.2 单根结构

所有类最终是否都应从单独一个基础类继承。
终级基础类的名字很简单，就是一个“Object”。

单根结构中的所有对象（比如所有Java 对象）都可以保证拥有一些特定的功能。在自己的系统中，我们知道对每个对象都能进行一些基本操作。一个单根结构，加上所有对象都在内存堆中创建，可以极大简化参数的传递（这在C++里是一个复杂的概念）。

利用单根结构，我们可以更方便地实现一个垃圾收集器。与此有关的必要支持可安装于基础类中，而垃圾收集器可将适当的消息发给系统内的任何对象。如果没有这种单根结构，而且系统通过一个句柄来操纵对象，那么实现垃圾收集器的途径会有很大的不同，而且会面临许多障碍。

由于运行期的类型信息肯定存在于所有对象中，所以永远不会遇到判断不出一个对象的类型的情况。这对系统级的操作来说显得特别重要，比如违例控制；而且也能在程序设计时获得更大的灵活性。

7.3 集合库与方便使用集合

单根结构意味着、所有东西归根结底都是一个Object！所以容纳了Object 的一个集合实际可以容纳任何东西。这使我们对它的重复使用变得非常简便。

但由于集合只能容纳Object，所以在我们向集合里添加对象句柄时，它会上溯造型成Object，这样便丢失了它的身份或者标识信息。再次使用它的时候，会得到一个Object 句柄，而非指向我们早先置入的那个类型的句柄。所以怎样才能归还它的本来面貌，调用早先置入集合的那个对象的有用接口呢？

使用“向下转型”（Downcasting）。假如向下转型成错误的东西，会得到我们称为“异常”（Exception）的一种运行期错误。但在从一个集合提取对象句柄时，必须用某种方式准确地记住它们是什么，以保证向下转型的正确进行。

能不能创建一个“智能”集合，令其知道自己容纳的类型呢？

可以采用“参数化类型”，它们是编译器能自动定制的类，可与特定的类型配合。在C++中，用于实现参数化类型的关键字是template（模板）。Java 目前尚未提供参数化类型，因为由于使用的是单根结构，所以使用它显得有些笨拙。

涉及到泛型编程。

7.4 清除时的困境：由谁负责清除？

垃圾收集器“知道”一个对象在什么时候不再使用，然后会自动释放那个对象占据的内存空间。采用这种方式，另外加上所有对象都从单个根类Object 继承的事实，而且由于我们只能在内存堆中以一种方式创建对象，所以Java 的编程要比C++的编程简单得多。我们只需要作出少量的抉择，即可克服原先存在的大量障碍。

8.异常控制：解决错误

由于采用的是独立的执行路径，所以不会干扰我们的常规执行代码。这样便使代码的编写变得更加简单，因为不必经常性强制检查代码。除此以外，抛出的一个异常不同于从函数返回的错误值，也不同于由函数设置的一个标志。那些错误值或标志的作用是指示一个错误状态，是可以忽略的。但异常不能被忽略，所以肯定能在某个地方得到处置。最后，利用异常能够可靠地从一个糟糕的环境中恢复。此时一般不需要退出，我们可以采取某些处理，恢复程序的正常执行。显然，这样编制出来的程序显得更加可靠。

在Java 中，异常控制模块是从一开始就封装好的，所以必须使用它！

9.多线程

Java 的多线程机制已内建到语言中，这使一个可能较复杂的问题变得简单起来。对多线程处理的支持是在对象这一级支持的，所以一个执行线程可表达为一个对象。Java 也提供了有限的资源锁定方案。

10.持久化

可以将信息写入一个文件或者数据库，从而达到相同的效果。

11.J a v a 和因特网

11.1 C/S架构

这里要注意的一个主要问题是单个服务器需要同时向多个客户提供服务。在这一机制中，通常少不了一套数据库管理系统，使设计人员能将数据布局封装到表格中，以获得最优的使用。
除此以外，系统经常允许客户将新信息插入一个服务器。这意味着必须确保客户的新数据不会与其他客户的新数据冲突，或者说需要保证那些数据在加入数据库的时候不会丢失（用数据库的术语来说，这叫作“事务处理”）。
客户软件发生了改变之后，它们必须在客户机器上构建、调试以及安装。所有这些会使问题变得比我们一般想象的复杂得多。
另外，对多种类型的计算机和操作系统的支持也是一个大问题。
最后，性能的问题显得尤为重要：可能会有数百个客户同时向服务器发出请求。所以任何微小的延误都是不能忽视的。为尽可能缓解潜伏的问题，程序员需要谨慎地分散任务的处理负担。一般可以考虑让客户机负担部分处理任务，但有时亦可分派给服务器所在地的其他机器，那些机器亦叫作“中间件”（中间件也用于改进对系统的维护）。

Web 实际就是一套规模巨大的客户机／服务器系统。

11.2 客户端编程

Web 最初采用的“服务器－浏览器”方案可提供交互式内容，但这种交互能力完全由服务器提供，为服务器和因特网带来了不小的负担。服务器一般为客户浏览器产生静态网页，由后者简单地解释并显示出来。基本HTML 语言提供了简单的数据收集机制：文字输入框、复选框、单选钮、列表以及下拉列表等，另外还有一个按钮，只能由程序规定重新设置表单中的数据，以便回传给服务器。用户提交的信息通过所有Web 服务器均能支持的“通用网关接口”（CGI）回传到服务器。包含在提交数据中的文字指示CGI 该如何操作。

今天的许多Web 站点都严格地建立在CGI 的基础上，事实上几乎所有事情都可用CGI 做到。唯一的问题就是响应时间。CGI 程序的响应取决于需要传送多少数据，以及服务器和因特网两方面的负担有多重（而且CGI程序的启动比较慢）。这种方法不仅速度非常慢，也显得非常繁琐。

解决的办法就是客户端的程序设计。运行Web 浏览器的大多数机器都拥有足够强的能力，可进行其他大量工作。与此同时，原始的静态HTML 方法仍然可以采用，它会一直等到服务器送回下一个页。客户端编程意味着Web 浏览器可获得更充分的利用，并可有效改善Web 服务器的交互（互动）能力。

11.2.1 插件

利用插件，程序员可以方便地为浏览器添加新功能，用户只需下载一些代码，把它们“插入”浏览器的适当位置即可。

11.2.2 脚本语言

通过这种脚本语言，可将用于自己客户端程序的源码直接插入HTML页，而对那种语言进行解释的插件会在HTML 页显示的时候自动激活。
脚本语言真正面向的是特定类型问题的解决，其中主要涉及如何创建更丰富、更具有互动能力的图形用户界面（GUI）。然而，脚本语言也许能解决客户端编程中80％的问题。你碰到的问题可能完全就在那80％里面。而且由于脚本编制语言的宗旨是尽可能地简化与快速，所以在考虑其他更复杂的方案之前（如Java 及ActiveX），首先应想一下脚本语言是否可行。

目前讨论得最多的脚本编制语言包括JavaScript（它与Java 没有任何关系；之所以叫那个名字，完全是一种市场策略）、VBScript（同Visual Basic 很相似）以及Tcl/Tk（来源于流行的跨平台GUI 构造语言）。

11.2.3 Java

Java 通过（Applet）巧妙地解决了客户端编程的问题。

11.2.4 ActiveX

在某种程度上，Java 的一个有力竞争对手应该是微软的ActiveX，尽管它采用的是完全不同的一套实现机制。ActiveX 最早是一种纯Windows 的方案。经过一家独立的专业协会的努力，ActiveX 现在已具备了跨平台使用的能力。实际上，ActiveX 的意思是“假如你的程序同它的工作环境正常连接，它就能进入Web 页，并在支持ActiveX 的浏览器中运行。

11.2.5 安全

目前解决的办法是“数字签名”，代码会得到权威机构的验证，显示出它的作者是谁。但我对它能消除恶意因素持怀疑态度，因为假如一个程序便含有Bug，那么同样会造成问题。
Java 通过“沙箱”来防止这些问题的发生。

11.2.6 因特网和内联网

Web 是解决客户机／服务器问题的一种常用方案，所以最好能用相同的技术解决此类问题的一些“子集”，特别是公司内部的传统客户机／服务器问题。

11.3 服务器端编程

如果向服务器发出一个请求，会发生什么事情？大多数时候的请求都是很简单的一个“把这个文件发给我”。浏览器随后会按适当的形式解释这个文件：作为HTML 页、一幅图、一个Java 程序片、一个脚本程序等等。向服务器发出的较复杂的请求通常涉及到对一个数据库进行操作（事务处理）。其中最常见的就是发出一个数据库检索命令，得到结果后，服务器会把它格式化成HTML页，并作为结果传回来。

另外，有时需要在数据库中注册自己的名字（比如加入一个组时），或者向服务器发出一份订单，这就涉及到对那个数据库的修改。这类服务器请求必须通过服务器端的一些代码进行，我们称其为“服务器端的编程”。在传统意义上，服务器端编程是用Perl 和CGI 脚本进行的，但更复杂的系统已经出现。其中包括基于Java 的Web 服务器，它允许我们用Java 进行所有服务器端编程，写出的程序就叫作“小服务程序”（Servlet）。

11.4 一个独立的领域：应用程序

12.分析和设计

12.1 不要迷失

时刻提醒自己注意以下几个问题：
(1) 对象是什么？（怎样将自己的项目分割成一系列单独的组件？）
(2) 它们的接口是什么？（需要将什么消息发给每一个对象？）

12.2 阶段0 ：拟出一个计划

决定在后面的过程中采取哪些步骤。
在整个过程中设置几个标志，或者“路标”，将更有益于你集中注意力。这恐怕比单纯地为了“完成工作”而工作好得多。至少，在达到了一个又一个的目标，经过了一个接一个的路标以后，可对自己的进度有清晰的把握，干劲也会相应地提高，不会产生“路遥漫漫无期”的感觉。

12.3 阶段1 ：要制作什么？

在上一代程序设计中（即“过程化或程序化设计”），这个阶段称为“建立需求分析和系统规格”。

需求分析的意思是“建立一系列规则，根据它判断任务什么时候完成，以及客户怎样才能满意”。系统规格则表示“这里是一些具体的说明，让你知道程序需要做什么（而不是怎样做）才能满足要求”。需求分析实际就是你和客户之间的一份合约（即使客户就在本公司内部工作，或者是其他对象及系统）。系统规格是对所面临问题的最高级别的一种揭示，我们依据它判断任务是否完成，以及需要花多长的时间。由于这些都需要取得参与者的一致同意，所以我建议尽可能地简化它们——最好采用列表和基本图表的形式——以节省时间。可能还会面临另一些限制，需要把它们扩充成为更大的文档。

我们特别要注意将重点放在这一阶段的核心问题上，不要纠缠于细枝末节。

应尽可能总结出自己系统的一套完整的“使用条件”或者“应用场合”。一旦完成这个工作，就相当于摸清了想让系统完成的核心任务。

在这一阶段，最好用几个简单的段落对自己的系统作出描述，然后围绕它们再进行扩充，添加一些“名词”和“动词”。“名词”自然成为对象，而“动词”自然成为要整合到对象接口中的“方法”

12.4 阶段2 ：如何构建？

在这一阶段，必须拿出一套设计方案，并解释其中包含的各类对象在外观上是什么样子，以及相互间是如何沟通的。此时可考虑采用一种特殊的图表工具：“统一建模语言”（UML）。

作出了对对象以及它们的接口的说明后，就完成了第2 阶段的工作。当然，这些工作可能并不完全。

12.5 阶段3 ：开始创建

由于手头上有一个计划——无论它有多么简要，而且在正式编码前掌握了正确的设计结构，所以会发现接下去的工作比一开始就埋头写程序要简单得多。而这正是我们想达到的目的。让代码做到我们想做的事情，这是所有程序项目最终的目标。

全面的思考、周密的准备、良好的构造不仅使程序更易构建与调试，也使其更易理解和维护，而那正是一套软件赢利的必要条件。

12.6 阶段4 ：校订

事实上，整个开发周期还没有结束，现在进入的是传统意义上称为“维护”的一个阶段。

什么时候才叫“达到理想的状态”呢？这并不仅仅意味着程序必须按要求的那样工作，并能适应各种指定的“使用条件”，它也意味着代码的内部结构应当尽善尽美。至少，我们应能感觉出整个结构都能良好地协调运作。没有笨拙的语法，没有臃肿的对象，也没有一些华而不实的东西。除此以外，必须保证程序结构有很强的生命力。由于多方面的原因，以后对程序的改动是必不可少。但必须确定改动能够方便和清楚地进行。这里没有花巧可言。不仅需要理解自己构建的是什么，也要理解程序如何不断地进化。

12.7 计划的回报

不管制订出的计划有多么小，但与完全没有计划相比，一些形式的计划会极大改善你的项目。