正版新书]Live软件开发面面谈潘俊9787302501565

目录

第1章接口

1.1使用接口编程

1.2依赖反转原则

1.3如何实现

1.3.1工厂模式

1.3.2服务定位器模式

1.3.3依赖注入

1.4真的实现了吗

1.4.1依赖的传递性

1.4.2依赖的形式

1.5真正实现

1.5.1配置文件

1.5.2配置代码

1.5.3惯例先于配置

1.5.4元数据

1.5.5实现消除依赖的方法的本质

1.6有必要针对接口编程吗

1.6.1针对接口编程的成本

1.6.2接口的意义

1.6.3何时针对接口编程


第2章事件

2.1控制反转

2.2观察者模式

2.3Java中的事件编程

2.3.1通用的事件发布者和收听者

2.3.2通用事件收听者的问题

2.3.3Swing用户界面里的事件编程

2.3.4专用事件收听者的问题

2.3.5彻底地面向对象

2.3.6Java 8带来的福音

2.3.7这一切背后仍然是对象

2.4C#中的事件编程

2.4.1代理

2.4.2事件

2.5JavaScript中的事件编程

2.6事件编程的其他细节

2.6.1收听者的执行顺序

2.6.2收听者是否在单独的线程执行

2.6.3控件层次中的事件传播


第3章MVC

3.1输入、处理和输出

3.1.1冯·诺依曼架构

3.1.2矩阵运算器和IPO

3.1.3矩阵运算器和IPO的升级版

3.2程序与用户的交互

3.2.1三类应用程序

3.2.2持续交互带来的变化

3.2.3图形用户界面带来的变化

3.3设计理念

3.3.1关注点分离

3.3.2模型

3.3.3模型和视图的分离

3.3.4控制器

3.3.5模型视图

3.3.6事件发布者与收听者之间的依赖

3.3.7合作方式

3.4桌面应用程序与移动App

3.4.1控制器和视图在代码单元上独立

3.4.2控制器、视图和模型之间的相互引用

3.4.3控制器和视图合一

3.4.4移动App

3.5Web应用程序

3.5.1Web应用程序简史

3.5.2服务器端的MVC

3.5.3前端控制器与控制器

3.5.4视图

3.5.5模型

3.5.6依赖注入

3.5.7浏览器端的MVC

3.6类型转换、校验和数据绑定

3.7MVC的意义


第4章界面

4.1以用户界面为中心VS以业务逻辑为中心

4.2设计视图VS源代码视图

4.3自定义控件VS复合控件

4.4命令式语言VS声明式语言

4.5内容与外观的分离

4.6基于请求的框架VS基于组件的框架

4.7极简主义

4.7.1用户界面上的极简主义

4.7.2删减的对象

4.7.3方法和特征

4.7.4防止过度


第5章数据库

5.1多值与复合属性

5.1.1关系型数据库模式的第一范式和第二范式

5.1.2范式与复合、多值属性

5.1.3关系型数据库中的多值和复杂数据类型

5.2数据库模式

5.3数据建模

5.3.1抽象的数据建模

5.3.2针对具体数据库的建模

5.4视图

5.4.1索引

5.4.2关系型数据库中的视图

5.4.3文档型数据库中的视图

5.5可伸缩性

5.6可得性与BASE

5.7编程接口

5.8总结


第6章权限

6.1身份验证

6.1.1验证类型

6.1.2验证属性

6.1.3知识要素验证

6.2Web应用的验证

6.2.1验证与会话

6.2.2第三方身份验证

6.3授权

6.4基于角色的存取控制

6.4.1用户与权限

6.4.2群组与角色

6.4.3权限与操作

6.4.4实现

6.5基于属性的存取控制

6.5.1资源与存取方式

6.5.2从权限到属性


第7章异类

7.1快速开发

7.2Lotus Notes是什么

7.3技术架构

7.3.1数据库

7.3.2客户端与服务器

7.4应用程序开发

7.4.1两种路径

7.4.2用户界面驱动的快速开发

7.4.3事件驱动编程

7.4.4直接使用文档对象编程

7.4.5权限模型

7.4.6角色和隐藏公式

7.4.7三类应用程序

7.4.8多种编程语言

7.5Lotus Notes的衰亡及其教训

7.5.1对用户主观体验重视不够

7.5.2快速开发的缺陷

7.5.3嵌入式开发的缺陷

7.5.4数据库和应用程序合一

7.5.5创新乏力

7.6给现有Lotus Notes客户的建议


第8章兴衰

8.1软件的更新和生命

8.1.1兼容性

8.1.2兼容性与创新

8.2客户端的兴衰

8.2.1客户端与服务器

8.2.2远程过程调用和数据传输协议

8.2.3客户端的胖瘦趋势

8.2.4客户端与浏览器

8.2.5浏览器与App

8.2.6理想的客户端应用程序

8.2.7开发人员体验VS用户体验

8.3Lotus Notes的历史

8.3.1前身

8.3.2青少年： 版本1~3

8.3.3中年： 版本4~6

8.3.4老年： 版本7~9

参考文献

第3章MVC假如问一群程序员，谁是最有价值厨师？他们大概会在短暂的茫然后给出五花八门的答案，男朋友、老婆、老妈或者某家快餐连锁店的幕后大厨。显然他们对这个概念还不太熟悉，但是如果把它翻译成英文MostValuableCook，有些人或许就明白了。假如还不知道，说出它的简称，他们就一定很熟悉——MVC。
MVC可谓是图形用户界面软件设计的标准模式。无论采用哪种编程语言，设计的是桌面端、Web还是移动端应用程序，采用的是流行的或冷门的开发框架，遵行MVC都几乎是必然的。然而另一方面，就像一千个人眼中有一千个哈姆雷特，当人们谈论MVC时，也像谈论爱情一样，所指千变万化。
视图没有直接从模型获得更新，而是由控制器修改视图，这违背了MVC的设计原则。控制器应该对视图的细节一无所知。事件响应程序可以直接写在视图内。控制器负责系统的业务逻辑。诸如此类都是关于MVC的断言。但在其他地方，又可以看到截然相反的论断。这些被我当成反面教材列出来的话语可不是初学者的臆想，它们都是来自Google相关关键字搜索的结果前列，有的是Oracle官方网站上对MVC的介绍文章，有的是俄亥俄州立大学计算机科学与工程系的主题讲义，有的是编程社区网站的热门和高票文章。代码样例是程序员学习的重要来源。不幸的是，同样来自Google搜索结果排名前列的MVC的样例代码却良莠不齐。很难相信这些代码的作者会以他们对MVC那样的理解和代码风格在实际项目开发中应用MVC模式。
【注：上述部分论断和代码样例的出处www.oracle.com/technetwork/articles/javase/index142890.htmlhttp://web.cse.ohiostate.edu/~rountev/421/lectures/lecture23.pdfhttp://www.austintek.com/mvc/http://www.codeproject.com/Articles/613682/YourfirstprogramusingMVCpatternwithCsharpWhttp://www.codeproject.com/Articles/383153/TheModelViewControllerMVCPatternwithCsharp】平心而论，会有这样的现象，部分原因是MVC不像Singleton之类的设计模式那样具体，没有精确的代码对应形式，而且在广泛的应用中，根据环境要求和不同编程语言的特点也产生了不少变体，如MVP(ModelViewPresenter)，从而令得不同情况下三个组件所负责的功能和实现方式有所出入。这样的弹性和变化进一步让MVC在传播过程中，像故事的流传一样衍变出形形色色的版本，又像娱乐节目上经常出现的接力猜谜，每一个人从上一个人的动作中猜出在模拟什么东西，再以自己的方式表演给下一个人看，到最后一个人猜出的结果往往和最初风马牛不相及。要应对这样的困境，最好的方法是不仅知其然，还要知其所以然。本章将从简单程序的结构入手，逐步分析一个自然合理的架构随着程序的演变，如何发展成MVC。从分析MVC架构体现的设计理念辨清它的真相，理解在它的种种变体中哪些不变的部分是逻辑要求的必然结果，又有哪些部分可以适应需求、环境和实现技术做出灵活的选择。这之后再讨论桌面、移动和Web环境下MVC的具体实现。
3.1输入、处理和输出输入、处理和输出是早在计算机出现之前就可以从人类发明的很多机器抽象出来的模式。对蒸汽机来说，输入的是煤，处理是燃烧产生蒸汽，输出的是机械动力；电灯输入的是电流，处理是灯丝通电升高到足够的温度，输出的是光。而最典型的可能莫过于一台全能猪利用机，输入的是活猪，处理是在一个闪闪发光的密封金属舱中轰隆隆地进行，输出的是香肠、皮鞋、毛刷和骨头汤。所以从计算机的架构中也能看出这种模式，是毫不奇怪的。这种抽象的模式不仅适用于硬件，对我们关心的程序开发而言也是一种很自然的结构。本节将探讨它在命令行程序中的表现形式。
3.1.1冯·诺依曼架构1936年英国数学家图灵(AlanTuring)提出了一种想象中的机器——图灵机。这种机器的构造十分简单，只包括一条无限长的带子、一个读写头和一个状态存储器，然后机器根据读写头读取到的符号和当前状态以及有限条规则操作。图灵表明任何一项具体的计算，都可以由一台特定的图灵机完成。再进一步，将描述如何进行一项具体计算的规则也记录在带子上，由一台特殊的图灵机读取，那么它就可以完成那台特定的图灵机的计算。这样一台可以模拟所有图灵机，也就是可以进行任何计算的特殊的图灵机就被称为通用图灵机，它是现在所有计算机理念上的先驱。
1945年，出生于匈牙利的数学家、物理学家和科学全才约翰·冯·诺依曼(JohnvonNeumann)在美国的宾夕法尼亚大学参与埃尼阿克研制工作时向美国军方提交了FirstDraftofaReportontheEDVAC(电子离散变量自动计算机报告初稿，EDVAC即ElectronicDiscreteVariableAutomaticComputer)。这份报告虽然只有个不起眼的名称“初稿”，却和其他奠基性的文献一样，完整地建立了一台电子计算机的架构。冯·诺依曼首先描述了作为主题对象的“计算机”，它是一台能高速计算的电子设备，胜任求解物理和工程中常见的多变量偏微分方程，把要解决的问题的参数和描述求解方法及步骤的命令以某种方式输入后，它就能在没有任何人工辅助的条件下将结果计算出来并以某种方式输出。接着冯·诺依曼将计算机从逻辑上分成五个部分，分别完成特定的功能。这台机器被设计的主要用途是进行数学计算，所以自然有一个部分专职于此，即中央算术组件(CentralArithmeticalPart，简称为运算器)，它负责进行加减乘除等基本运算。第二部分叫作中央控制组件(CentralControlPart，简称为控制器)，负责执行指令，指挥运算器所做计算的次序，协调计算机的所有组件统一工作。第三部分称为存储器(Memory)，用于保存计算过程中用到的各种信息，包括要解决的问题和计算产生的中间数据等。冯·诺依曼列举了计算机可能解决的各种数学问题，分别估计它们需要多大的存储空间。第四部分是输入设备，计算机的操作员通过它将待解决的问题和计算机执行的命令输入计算机，冯·诺依曼提到了当时可用于此的几种技术：在打孔卡或电传打字机纸带上打孔，在钢带或钢线上用磁记录，在电影胶卷上用摄影技术记录，通过插接板的连线配置……不过在这个人类发明的长长清单里键盘还没有出现。第五部分与第四部分相对，是输出设备，用于将计算结果传导到某种人可以直接或间接读取的载体上，也是利用上面列举的技术。
这份报告不仅指导建成了一台电子计算机，而且其中的很多讨论和分析对以后世世代代的计算机都有效，原因就是它一方面体现了最一般的自动计算机模型——图灵机的思想，另一方面又将通用图灵机的模型用更贴近实际制造和操作的方式设计出来，并且以当时的电子技术为基础，对计算机的各个部分做了具体的分析。报告将计算机从逻辑上分解成运算器、控制器、存储器、输入和输出设备五大部分，也被后人称为冯·诺依曼架构。计算机已经经历了从“埃尼阿克”的庞然大物到如今人手一部的智能手机的沧桑巨变，然而五大部分的分类仍然有效。
将冯·诺依曼架构和通用图灵机模型作比较，计算器、控制器和存储器三者的组合已经实现了通用图灵机的功能，输入和输出设备则是人类与机器交互的手段。我们再从机器转向程序的视角，每个具体的软件都具备一个或一组特定的功能，计算机读取和执行该软件的代码，就变成了一台特定用途的图灵机。软件的用户以某种渠道输入数据，软件进行处理，完成后再以用户能理解的方式输出。这样类比于冯·诺依曼架构，一个软件就可以被划分为输入、处理和输出三部分。这个划分看上去平凡无奇，但接下来的讨论将让我们看到它是怎样逐渐演变成MVC模式的。另外为了和MVC对应，我们给输入处理输出结构也起了一个很酷的简称IPO(即英文Inputter、Processor和Outputter的简称)。
3.1.2矩阵运算器和IPO先来看看图形用户界面产生之前的命令行应用程序。假设现在要开发一个简单的矩阵运算器，可以求矩阵的转置。我们的思路很自然地就集中在怎样设计出一个能代表矩阵的数据结构，并在它上面实现转置的算法。对于这个简单的问题，既可以采用过程式编程，也可以应用面向对象编程。为了与以后讨论的问题保持一致，这里以面向对象的范式来思考。这样得到的结果是一个矩阵类型Matrix，包含一个求转置的方法Transpose(这里径直采用面向对象编程中基于类型的途径，但选择基于原型等其他途径并不影响我们的分析)。这时候我们就会发现，矩阵运算器的核心虽已完成，但要成为一个可使用的软件，还需要增添其他一些部分。从矩阵类型的视角来看，在进行转置运算前，要先为矩阵的元素提供数据，也就是初始化一个矩阵对象。从软件用户的视角来看，他要解决的是求一个个矩阵个体的转置，因此先要将这些个体告诉矩阵运算器。在命令行应用程序的环境下，告诉的方式便是在控制台(Console)上将矩阵的元素以某种格式用键盘输入。可以设想很多种格式，例如先输入两个数字，表明矩阵的阶数，然后输入空格分隔的所有矩阵元素；或者直接输入矩阵元素，每行元素输入完成后换行；还可以用括号将每行元素包括起来，这样就不用换行。等到运算器完成计算后，用户也要能在屏幕上看到结果。转置后的矩阵既可以以与输入相同的格式输出，也可以按照矩阵的行列分布以直观的形式打印出来。这些需求对应到矩阵运算器上，就意味着两项新的功能：一是读取用户在控制台上以某种格式输入的字符，利用其要传递的信息，初始化一个矩阵对象；二是将转置后的矩阵以用户能理解的形式打印到控制台上。至此，我们对软件抽象划分出的三部分在矩阵运算器上就有了对应物。处理的部分对应矩阵类型，输入和输出的部分分别对应上述两项新功能。为了简便，我们不妨把三者分别称为输入部分、处理部分和输出部分。我们为输入部分和输出部分也分别创建一个类型：Inputter和Outputter。这样程序的运行顺序就大致如下。