在线游戏基础结构，第 1 部分: 开发高层业务描述并确定模式 - CSDN博客
在线游戏基础结构，第 1 部分: 开发高层业务描述并确定模式
在线游戏行业的业务比较复杂，需要投入并结合许多因素（人员、业务环境、产品目标等等）才能创建、实现和发行一个成功的在线游戏。高级 IT 架构师 Veronika Megler 开启了共分五部分的系列文章的第一篇，这个系列主要关注在线游戏的基础结构提供商。本文将说明在线游戏行业目前的状况，并演示如何开发高层业务描述以及如何确定最重要的业务模式。作者通过八个步骤实现这一目标。
20 年前，当我为了谋生编写计算机游戏时，这个行业还非常简单。我写游戏，公司包装并出售这些游戏（在用于 PC 的 CD-ROM 和 CD-ROM 驱动器出现之前，游戏是用盒式磁带发行的 && 您能相信吗？）。我的老板赚了不少钱，我赚的钱也比大学生用大多数合法手段挣到的钱多，而且我玩过我喜欢的所有计算机和街机游戏。游戏行业中的生活还真不错！
但是我觉得厌倦了，所以加入了 Real Business，开始从事企业应用程序。许多年过去了，我又回到了游戏行业。天哪，这个行业的变化可真大！
这个行业中的主要变化是，每个游戏（或者说几乎每个游戏）现在都可以称为在线游戏了。随着在线访问的大量增加，游戏和游戏基础结构的开发和部署也复杂多了。
无论以怎样的详细程度描述在线游戏行业，都要花费很长时间，而且我希望将重点放在发展问题上，而不是关注其历史。为了给后面的讨论提供一个背景环境，我想花一点儿时间谈谈该行业的状况。
这个开发、发行和运营游戏的行业越来越复杂了。在我以前编写游戏时，代码开发人员执行所有开发任务，而现在，游戏的美术方面越来越多地由美术工作室来承担。游戏开发商的差异也很大，从具有一个好创意的新公司到大型娱乐公司（他们希望通过电影、演员和品牌的综合运用来开发游戏，让现有的媒体资产产生更多的收益）。
游戏可以由开发游戏的公司、专门的游戏发行商或游戏合并者来发行。游戏开发业越来越像电影业了，这个行业中有大型公司，也有小型的独立开发商，他们有时候是合作伙伴，有时候是竞争对手。
计算机游戏有许多不同的类型。游戏内容或游戏风格都有很大的差异：从角色扮演游戏（role-playing games，RPG）到极限运动游戏；从战略游戏到第一人称射击（first-person shooter）游戏，最后到 high-twitch 游戏。（high-twitch 是一种需要快速反应才能得高分或者持续几分钟不被打败的游戏。）
划分游戏类型的一种常用方法是根据玩家的人数：
单玩家游戏（single-player game）需要的游戏时间往往相当短，适合临时的游戏玩家。Patience 和 Tetris（Windows 上的免费版本称为 Tetrus）这样的游戏和纸牌游戏往往属于这一类。它们也可以称为回合制游戏（turn-based game）&& 这些游戏的多玩家版本中的交互常常只是为了获得高分。
在多玩家游戏（multi-player game）中，一个服务器托管了 2 到 64 位玩家。这些游戏一般具有特定长度的游戏时间，常常需要玩家保持一定的紧张程度。一个例子是 Battlefield 1942。
大型多玩家在线游戏（massive multi-player online game，MMOG）在一个服务器托管的游戏环境中有数千位玩家；这些游戏常常不间断地运行。例子包括 Everquest（由于它太容易让人上瘾，有时候被戏称为 Evercrack）和韩国的著名游戏 Lineage（天堂）。
这些类型的游戏的玩法有很大差异，用户界面和支持它们的技术基础结构也很不一样。
本系列将带领您考察所谓的游戏基础结构提供商（game infrastructure provider），这是整个游戏行业的一部分，包括以下几类公司：
开发了自己的游戏的公司，他们现在希望通过托管自己的基础结构公开运营这些游戏。
游戏合并者，比如游戏门户，他们让玩家能够从一个门户访问许多不同的游戏。
发行商，他们与游戏门户相似，可以提供对一个或多个游戏的访问。
在本系列的后面，我主要关注游戏提供商为实现服务目标而必须构建的基础结构。
尽管在单玩家、多玩家和大型多玩家游戏的提供商之间存在差异，但是所有这些类型的游戏提供商所需的主要基础结构是相似的，所以同样的基础结构可以支持所有这些类型的游戏。
在开始介绍规划这样的基础结构所需的步骤之前，我们先看看游戏基础结构提供商所处的环境。
游戏基础结构提供商的生活变得复杂起来。从游戏中赚钱越来越复杂了。为什么呢？
一个主要原因是必须要让订购游戏的客户满意。客户需要一系列服务，如果成功地提供了这些服务，它们会提高游戏提供商的总收入。随着时间的推移，游戏玩家（行话称为 gamer）对服务的数量和复杂性的期望会越来越高。
从游戏中赚钱越来越复杂的另一个原因是技术正在进步，这导致了更多的变化。游戏设备的种类越来越多了，游戏本身也更复杂了，这需要更高质量的图形功能以及更新颖、更复杂的游戏玩法。游戏以前主要是用 CD-ROM 发行的，现在常常以电子方式发行。
游戏行业所需的投资也很大。开发一个大型多玩家在线游戏可能要花费 1200 万美元以上。由于开发大型游戏的投资巨大，投资风险以及为了获得重复收益，早晚会出现 &开发套件&。我们早晚会听到这样的呼吁：
用更少的投入，做更多的事 && 我们不要重新发明轮子 && 可重用的组件&&
目前，在线游戏基础结构的开发与其他电子商务企业很相似。但是，还没有失去乐趣和创造性。可以列出所有企业需求，然后对这些需求进行分类，其中一部分是游戏行业特有的，一些是常见的企业问题，这些问题可以借助行业标准解决方案来处理。
游戏行业正在努力解决快速增长的复杂性。持续的快速变化意味着这个行业正处于过渡期。游戏基础结构提供商正在从无拘无束的公司过渡到电子商务企业，本文要讨论的就是在这个阶段中涉及的基础结构问题。
在本系列中，我将通过几个场景说明这一观点，演示场景包含的功能，并提出可以支持这些场景的架构。先从一个简单的场景开始，在随后的系列文章中会增加更多的功能和场景。
在本文中，将按照 Patterns for e-business: A Strategy for Reuse 一书（参见
）中的描述，使用业务模式方式创建架构。还可以将这种模板作为一种机制来判断哪些功能可以轻松地添加进系统，哪些功能需要重新考虑架构。
模式是可重用的资产，可以帮助加快开发电子商务应用程序的过程。例如，IBM 将这些可重用的资产分成以下几类：
业务模式（business pattern）确定用户、企业和数据之间的交互，用来构建简单的端到端电子商务应用程序。
集成模式（integration pattern）将其他业务模式绑定在一起，创建具有高级功能的应用程序。
复合模式（composite pattern）是业务和集成模式的组合，这些组合是常用的电子商务应用程序类型。
定制的设计（custom design）与复合模式相似（因为它们也将业务和集成模式组合成高级的端到端解决方案），但是它们的应用范围没有复合模式那么大；开发它们是为了解决特定公司的电子商务问题。
应用程序模式（application pattern）和运行时模式（runtime pattern）：这些模式由客户的需求驱动，描述应用程序的形态以及构建电子商务应用程序所需的支持运行时。
通过使用架构模式，无论业务的规模有多大，开发人员都可以更快地创建解决方案。
我将借用 Patterns for e-business: A Strategy for Reuse 一书中的思想，描述如何确定和选择合适的架构模式，从而以最佳方式表示解决业务问题所需的功能：
步骤 1： 开发高层业务描述，指明解决方案中的主要业务功能。
步骤 2： 开发解决方案概况图，从而把文字性的描述转换为图示。
步骤 3： 从现有的模式中确定适合这个解决方案的业务模式。
步骤 4： 确定集成模式。正如业务模式的某些组合常常反复出现，集成模式也非常常见。
步骤 5：确定复合模式，它们用来确定业务功能的主要集合。
步骤 6：确定应用程序模式。
步骤 7：总结所需的所有应用程序模式。
步骤 8：将这些模式和所选的任何包集成进解决方案中。
接下来，我将提供一个简单的场景作为基础，并具体讨论前六步涉及的问题。（在下一篇文章中，我将重新关注游戏本身，将游戏级别作为一个基础结构问题来讨论，讨论最后两步，并讨论是自己构建组件，还是购买现成的组件。）
我们来描述一位目标受众成员和您计划构建的系统之间可能的交互。在为系统需要提供的功能设计架构时，使用这个最初的交互作为指南。我将这个交互过程称为 &场景 1：购买，然后开始玩游戏&。
在最近一期的 The Hip Gamer's Magazine 上，一位潜在玩家 Ken 看到了一个广告，其中列出了最新的基于 PC 的 MMOG HAL 2010: Universe On Demand 的 Web 地址。他访问这个 Web 站点。一个广告条推荐这个游戏，并提供购买它的方法。
Ken 选择 &buy now!& 按钮。站点要求他提供注册信息：一个惟一的用户 ID 和密码。然后，他被重定向到包含这个游戏的购物车。Web 站点询问他是否要购买其他东西，比如游戏的海报、T 恤衫、带徽标的帽子或者咖啡杯 && 当然，这些都要额外付费。他选择了海报。站点让他选择游戏和海报的交付方式。他可以选择下载，也可以选择邮寄（游戏包含在 CD-ROM 上，海报是印刷品）。让他选择交付时间和相关的费用之后，那些无法使用数字交付方式的物品（比如咖啡杯）以及他选择实物交付方式的物品会以实物的方式交到他手上。
然后，Web 站点提供若干选择，可以浏览产品目录、查看新玩家指南或加入服务器托管的聊天会话。
在购买游戏的过程中，Ken 得到了一定程度的免费游戏。当他购买游戏时，游戏商使用 Ken 可以免费游戏的标记更新在他注册时创建的目录记录。还可以在他的记录中添加他下载的游戏实例的注册号，或者寄给他的 CD-ROM 上的注册码。
当 Ken 开始玩游戏之后，您可以收集他的游戏过程的相关信息。一些信息放在数据库中，用来维持游戏的持久性；其他数据放在包含他的配置文件的目录或游戏统计信息数据库中。
站点还提供与客户服务的会话，如果 Ken 无法通过 FAQ 或玩家指南解决他遇到的问题，就可以向客服人员咨询。
当 Ken 用完了免费游戏时间之后，站点自动地向他指定的地址发送一封电子邮件，其中包含更新订购的链接。通过这个链接，他可以在多种订购方式中做出选择（比如，不限使用次数的包月方式，或者以较低费用一次性购买特定的游戏时间）。当他选择了某种方式之后，站点显示他以前使用的信用卡信息，获得他的同意，然后立即进行支付。
从用户的角度来看，这个交互过程似乎很简单，但是您会发现建立这个交互过程并不太容易。
在开发潜在解决方案的大致轮廓或概况时，应该包含这个场景中的哪些功能呢？下面是我列出的功能：
毫无疑问，游戏本身是主要内容 && 玩家访问您的站点就是为了玩游戏。还可能需要将游戏与其他组件集成；例如，在游戏会话之间，要保持每个人的游戏状态。
在注册期间，要求玩家提供惟一的用户 ID 和相关的密码。还要求他提供一个电子邮件地址，这个地址用来发送续订通知、新闻通告、相关的广告和其他信息。
需要存储用来识别用户的基本信息。这种方便的机制也可以存储与用户相关的其他信息，比如游戏的偏好设置或支付信息。
对于任何收费游戏，玩家都应该能够查看自己帐号中剩余的时间或费用，并能够更新帐号信息。
尽管找到访问游戏的入口可能很容易（在这个示例中，是通过站点上的广告条），但是还要让玩家能够选择与这个游戏相关的其他东西，并能够搜索其他产品的目录。还要告诉玩家可以搜索玩家指南；并提供其他信息。
这包括可购买的游戏、杯子、T 恤衫、图书，甚至是游戏音效的手机铃声。
由于 FedEx 和 UPS 的努力，客户现在可以跟踪他们的订单。许多进行网上购物的人希望能够根据交付号链接到发送产品的站点。
一些数字产品可以用电子方式交付，比如海报、屏保和代码。非数字产品（T 恤衫、印刷的海报、杯子和 CD-ROM）需要进行实物运输。
客户服务必须与前面提到的几乎所有功能联系在一起，从而帮助玩家解决问题。如果问题与游戏本身相关，客服代表可能需要重新设置玩家的配置文件、调整他的帐号、检查他的订单，所需的功能可能非常多。提供方便的客户服务可以避免玩家由于失望而放弃游戏。这需要提供各种联系方法，包括网上聊天、电子邮件和电话。
在这个场景中我两次提到了聊天 && 在等待玩游戏的玩家之间的聊天，以及玩家与客户服务人员之间的交流。您还可能希望提供电子邮件，尽管这个场景中没有考虑这个功能。这些功能都归入 &协作& 的范畴。
支付就是您如何收钱 && 这可不是儿戏。第一次购买游戏、购买与游戏相关的其他产品、购买游戏时间、游戏续订以及可以想到的任何事情，这些都需要进行支付。
这包括对所有游戏玩家都有意义的通用信息：游戏指南、常见问题、来自其他玩家的技巧等等。除了提供目录外，还应该提供搜索和选择功能。还可以提供为具体类别的玩家定制的信息，比如新手或有经验的玩家。在理想情况下，用户可以指定他感兴趣的范围或者他所属的玩家群体，然后就会自动地看到为这类用户定制的新信息。这就涉及个性化以及与个人目录的集成。
奇怪的是，在这个列表中，似乎只有第一项是游戏开发人员真正感兴趣的。对于大多数游戏开发人员来说，其他项目都很无聊，是没有创造性的枯燥工作，最好让别人去做。
现在可以创建一个解决方案概况图（见图 1），从而以具体的形式表示解决方案所需的关键功能。下图包含基本版本的所有功能性需求。
现在，主要的功能一目了然了。
显然，在线游戏基础结构具有在线游戏市场特有的一些需求，这是由使用的设备类型和这个行业中常见的业务模型决定的。
但是，许多其他功能看起来很眼熟，因为它们与电子商务基础结构很相似。在过去几年中，许多公司已经实现了这些组件，比如基于互联网的贸易、客户自助服务、基于社区的工具。从 dot-com 时代开始直到现在，大量现成的解决方案已经成熟了，成为经过充分测试的稳定的产品。
在这种情况下，可以把游戏看作具有在线游戏行业特点的业务应用程序。
建立解决方案概况之后，就该执行这种基于模式的方式中的下一步了。
仔细查看解决方案概况图（），就会发现解决方案中存在以下业务模式：
玩家与游戏本身进行交互。在各种模式中，这种交互最适合表示为 Self-Service 模式。（也称为 User-to-Business，这个模式处理内部用户和外部用户与企业事务和数据进行交互的一般情况。）
买家可以搜索并选择产品目录中的产品，以及对所选产品下订单。这些功能涉及用户、后端系统和数据库（产品目录）之间的直接交互。这可以表示为 Self-Service 业务模式。
用户可以通过网上聊天和电子邮件相互交流，或者与客户服务代表交流。这是 Collaboration 业务模式。（也称为 User-to-User，这个模式处理用户之间的交互和协作。）
公司在两个帐号管理中在线接收信用卡信息，一个是游戏的续费，另一个是购买产品时的订单管理。这可以表示为 Extended Enterprise 业务模式。在线使用信用卡这个功能已经很成熟了，已经集成在许多产品中，但是我们目前采用这个模式并考虑它会导致哪些变化和扩展。（也称为 &Business-to-Business，这个模式处理不同企业的业务流程之间的交互和协作。）
履行订单功能是游戏公司和其他组织之间的边界；在这个场景中，送货工作很可能交给 FedEx 这样的快递公司去做。在某些情况下，整个履行订单功能都可以外包，比如与 Amazon 这样的公司合作。
那么，如何将这些功能集成在一起呢？在一般情况下，会使用 Access Integration 模式；实际上，这看起来也很适合这个场景。这个集成模式描述了支持访问一个或多个业务模式的常见设计。尤其是，这个模式支持来自多个渠道（或设备）的访问，并集成支持一致的用户界面所需的常用服务。
对于客户服务人员来说，Access Integration 也是合适的模式，因为在解决客户的问题时他们需要访问许多不同的应用程序。
图 2 给出修改后的解决方案架构图，其中包括集成模式。
既然已经确定了集成模式，现在看一下复合模式。复合模式是常见的集成模式和业务模式组合。
看看解决方案概况中包含的模式，然后与复合模式包含的模式进行对比。注意，其中几个复合模式似乎都适用：Electronic Commerce、Portal 和 Account Access 复合模式都涵盖我们需要的所有模式。
但是，Portal 模式涵盖的范围最大 && 它通常将多个信息源和应用程序聚合起来，向用户提供单一的无缝的个性化访问。它列出以下这些必需的模式，我们的解决方案概况中包含所有这些模式：
Access Integration 模式
Self-Service 模式
Collaboration 模式
Information Aggregation 业务模式（也称为 User-to-Data，它允许用户访问和操作来自多个信息源的数据）
模式描述进一步说明这个模式是合适的。下面引述 Patterns for e-business: A Strategy for Reuse 中 Adams 对这个模式的描述：
设计门户的目的通常是将多个信息源和应用程序聚合起来，向用户提供统一的无缝的个性化访问&&用于门户应用程序的复合模式由一个 Access Integration 模式和至少一个业务模式组成，其中的 Access Integration 模式帮助实现单点登录、多种设备支持和个性化等功能。
这完全适合我们的场景。
图 3 是 Portal 复合模式的图示，直接取自这本书。
另一方面，Electronic Commerce 复合模式将 Information Aggregation、Application Integration（它将多个应用程序和信息源聚合在一起，用户无需直接调用它们）和 Self-Service 列为必需模式，其他模式都是可选的。但是，我们已经知道 Collaboration 是必需的。
在这两个复合模式中，Extended Enterprise 都列为可选模式。对于支付、订单管理和履行订单，显然需要与 Extended Enterprise 相似的功能。
对于 Electronic Commerce 复合模式，可以选择的应用程序模式是 web-up（用来快速启用基于 Web 的商务站点，而不需要与后端系统紧密集成）或 enterprise-out（将现有的订单处理系统扩展为新的基于 Web 的商务渠道，这涉及紧密集成和重用现有的后端系统），具体的选择取决于是否存在遗留系统。因为我们正在从头构建基础结构，所以 web-up 模式更合适。
请关注 Electronic Commerce 模式和 Runtime 模式，研究是否能够利用其中的实现建议。
选择了业务模式之后，研究这些应用程序模式来实现业务模式。
在研究 Portal 应用程序模式时，您会找到下面这张图，它总结了每个业务和集成模式中的各种功能。同样，这些功能也分为必需的功能（在这个业务模式中必须存在的功能）和可选的功能（可有可无的功能）两类。
对 Portal 应用程序模式的必需/可选模式和解决方案所需的功能进行对比，就会发现以下需求：
访问集成（Access integration）：为了方便玩家，绝对有必要跨这些不同的功能提供单点登录。您还希望个性化交付面向群体和团队的信息。对于这个场景，目前还不需要 Pervasive device access。
自助服务（Self-service）：为了减少基础结构的总服务成本，需要使用 Directly integrated single channel 模式。
聊天和电子邮件功能：Store and Retrieve 协作（电子邮件）和 Directed Collaboration（聊天）有助于减少客户服务成本。它们还可以提供额外的功能，比如通过提供面向团队或交互性的活动，提高门户的 &亲合力&。
信息集成（Information aggregation）：用户希望能够搜索各种信息源。由于我们的场景不太复杂，所以可能不需要 Population Crawl and Discovery，但是对于具有大量信息源的门户站点来说，这个功能可能是有意义的。在目前的阶段，不太可能需要多步信息聚合，所以使用单步聚合，这是最简单的实现起点。随着时间的推移，会把来自内部信息源（比如会谈、文章、新闻以及对常见问题的回答）的数据添加进信息数据库中。在大多数情况下，最初会以手工方式将这些信息添加进信息数据库中，而不是用一个自动的过程来进行管理。
扩展的企业（Extended enterprise）：信用卡的确认和支付以及送货等外包业务是非常常见的电子商务功能。在开发过程中，还要注意研究电子商务模式。
如果研究一下 Portal 应用程序模式可用的 Runtime 模式选项，就会注意到所需的每个必需模式使用相同的 Runtime 模式。因此，使用这个 Portal 复合的 Runtime 模式就行了。不需要在多个相互冲突的模式中做出选择。它包含实现访问集成和其他功能的所有组件。
Portal 复合模式还包含来自 Self-Service 模式的 Runtime 组件，所以 Portal 复合模式提供了这两方面的基础结构组件。单点登录功能是由应用服务器使用目录提供的。
图 5 显示 Portal Runtime 模式。
为了进行对比，图 6 显示 Electronic Commerce 模式所用的 Runtime 模式。
看看 Electronic Commerce Runtime 模式的组件，您会发现它们与 Portal Runtime 模式在基本结构和常用组件方面有一些重叠，比如 Web 服务器和防火墙。还会看到 Portal 中没有的一些组件，比如 Commerce Application。为了构建完整的 Runtime 架构，需要结合这两个 Runtime 模式。
在本系列第一篇文章中，我尤其针对游戏提供商（游戏提供商是本系列关注的重点）解释了在线游戏行业中复杂性渐增的原因。这个行业正处于过渡时期，正在跨越企业业务和游戏艺术之间的鸿沟。
我介绍了模式，解释了它们在设计和实现在线游戏环境时的价值。我描述了一个典型的真实的交互过程，从而帮助您开发高层业务描述，确定开发方向。我演示了如何开发业务描述、提取关键的元素并使用这些元素构建项目的解决方案概况。
然后，以解决方案概况为基础，讨论了如何确定开发在线游戏基础结构所需的业务、集成、复合和应用程序模式。
中，我将重新关注游戏本身，按照基于模式的视角考察它。我将讨论可伸缩性选项，并通过将运行时模式集成进解决方案中，完成基于模式的解决方案建模的最后两步。您将使用运行时模型做出购买、自行构建和外包决策。
试用 （PDK Lite），这是一个自配置的端到端 Web 应用程序骨架，采用自解压的形式，它用于实现各种 Self-Service 解决方案设计。
访问 ，这里提供许多模式参考资料，包括一个帮助您为设计选择合适的模式的练习。
阅读本系列中的其他文章：
在 && 中，主要讨论可伸缩性选项以及基于模式的解决方案建模的最后两步（将在线游戏基础结构的运行时模式集成进解决方案中），并讨论外包是否是最佳方法（developerWorks，2004 年 6 月）。
在 && 中，主要讨论如何将新的设备支持功能集成进现有的在线游戏基础结构中，并满足电子商务和设备连接需求（developerWorks，2004 年 7 月）。
在 && 中，学习用基于模式的解决方案处理社区交互需求、在游戏环境中添加新内容以及在用户需要时提供帮助（developerWorks，2004 年 7 月）。
中，回顾游戏基础结构设计过程，讨论修改后的 build-buy-borrow 模板，并说明其中的一些额外功能（developerWorks，2004 年 8 月）。
访问 ，这是一个非盈利性的成员组织，其目标是帮助解决与数字游戏开发相关的问题。
通过 && 了解模式的使用方法（developerWorks，2000 年 6 月）。
通过 && 详细了解这个架构的工作原理（developerWorks，2004 年 2 月）。
阅读 &&，了解在线游戏系统的业务和收入模型背后的技术解决方案（developerWorks，2003 年 10 月）。
阅读 Mulligan 和 Patrovsky 所写的 （O'Reilly & Associates；1996 年），这本书描述了运行在线游戏基础结构的业务需求。
阅读 developerWorks
中讨论各种基于 Web 的解决方案的文章。
在 20 世纪 80 年代早期，Veronika Megler 作为 Melbourne House Publisher 的第一位职员在澳大利亚参与创建了最早的计算机游戏行业。她编写了畅销的计算机游戏，包括传奇文学游戏 The Hobbit，这个游戏在 Spectrum 64 家用计算机上非常流行。在 20 年的职业生涯中，她从事过操作、应用程序开发、系统编程、系统管理科学、项目管理和 IT 管理咨询。2003 年，她花费了很长时间研究如何将 IBM 产品应用于新兴的在线游戏行业。现在，她作为 IBM Sales & Distribution 的高级 IT 架构师从事 Offerings for Emerging & Competitive Accounts，帮助客户和消费者使用 IBM 解决方案和技术。她热衷于为实际的业务问题开发架构解决方案，并在实践中验证这些解决方案。
本文已收录于以下专栏：
相关文章推荐
详细内容参看《3D游戏编程大师技巧》或更专业的数学书籍。1.很多图形算法都以这样的方式进行优化：在第一象限中解决问题，根据对称性将解决方案反射到其他象限。2.2D笛卡尔坐标(Cartesian Coo...
什么是外观模式？
外观模式也叫门面模式（Facaed Pattern）。
要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。从而提供一个统一的高层接口，使得子系统更易于应用。其实外观模...
设计业务对象你可以通过很多途径实现model层。以checkout为例，表2展示如何进行代码实现。以下是实现checkout的三种方法，三种方法都是通过浏览器提交命令调用checkout代理来实现，但...
&#####本文为菜鸟窝作者蒋志碧的连载。
&#####菜鸟窝是专业的程序猿在线学习平台，提供最系统的 Android 项目实战课程
&#####“从 0 开始开发一款直播 APP ”系列来聊聊时下最...
这个分为两个部分的系列文章将研究 Apache Tomcat 的系统架构以及其运用的很多经典设计模式。本文是第
1 部分，将主要从 Tomcat 如何分发请求、如何处理多用户同时请求，还有它的多级容...
一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五之一：关于统一过程UP的讨论陈勇-创业-北京(**910753...
一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五以下，是的现场交流文字及图片，请参考。下一...
一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五回顾及普通用户故事（功能）的写法陈勇-创业-北京(**9107...
他的最新文章
讲师：何宇健
讲师：董岩
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)}