《实现模式(修订版)》—第1章1.2节那么,现在……

1.2 那么,现在……
该言归正传了。如果你打算按部就班地读下去,请翻到下一页(我猜这用不着特别提醒)。如果想快速浏览所有的模式,请从第5章开始。

本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

时间: 2024-08-22 12:05:58

《实现模式(修订版)》—第1章1.2节那么,现在……的相关文章

《设计模式解析(第2版•修订版)》—第2章 2.1节概览

第2章 UML2.1 概览设计模式解析(第2版•修订版)本章内容 本章将简单概述UML(统一建模语言),这是面向对象界主要使用的一种建模语言.如果你还不知道UML,阅读本章将使你具备阅读本书模型图所需的最低限度的知识. 本章中,我们将: 叙述"什么是UML"和"为什么使用UML": 阐述本书中的基本UML图,即 类图: 交互图. 本文仅用于学习和交流目的,不代表异步社区观点.非商业转载请注明作译者.出处,并保留本文的原始链接.

《设计模式解析(第2版•修订版)》—第2章 2.6节小结

2.6 小结设计模式解析(第2版•修订版)本章内容 UML既能够充实设计,又能够用于设计的交流.不要太担心要"正确地"画图.要考虑的是什么方式最有利于交流设计中的概念.换句话说,如果你认为有什么东西需要说,可以用注释来表达. 如果你对一个图标或符号不太确定,必须查手册才能确定其意义,还是加一条注释来解释.毕竟,其他人有可能也不清楚它的意义.清晰为好.当然,这也意味着你应该以规范的方式使用UML--那样无法正常交流.在画图的时候,只考虑要传达的思想即可. 本文仅用于学习和交流目的,不代表

《设计模式解析(第2版•修订版)》—第1章 1.1节概览

1.1 概览设计模式解析(第2版•修订版)本章内容 本章将通过与大家都熟悉的范型--标准结构化程序设计比较异同的方式,来介绍面向对象范型. 当年,面向对象范型正是为了应对使用标准结构化程序设计遇到的诸多挑战才应运而生的.弄清楚这些挑战,我们才能够更好地看到面向对象程序设计的优点,并更好地理解这一机制. 本章无法使你成为面向对象方法的专家,甚至不会介绍所有基本的面向对象概念.但是,本章将使你为阅读本书其他部分做好准备.本书其他部分将阐释如何像专家所做的那样正确使用面向对象设计方法. 本章中,我们将

《设计模式解析(第2版•修订版)》—第1章 1.9节小结

1.9 小结设计模式解析(第2版•修订版)本章内容 本章中我说明了面向对象技术是怎样帮助我们最大程度地减少系统需求变更带来的影响,以及面向对象与功能分解的异同. 我还讨论了面向对象程序设计的许多基本概念,介绍和描述了主要术语.表1-3总结了这些概念,表1-4总结了面向对象程序设计的主要术语. 本文仅用于学习和交流目的,不代表异步社区观点.非商业转载请注明作译者.出处,并保留本文的原始链接.

《软件工程(第4版?修订版)》—第2章2.1节过程的含义

第2章 过程和生命周期的建模软件工程(第4版•修订版)本章讨论以下内容: 过程的含义:软件开发的产品.过程和资源:软件开发过程的若干模型:过程建模的工具和技术.我们在第1章中看到,软件工程既是一个创造的过程,又是一个逐步进行的过程,它涉及很多人员,这些人员生产不同类型的产品.在这一章,我们会详细分析这些步骤,讨论各种活动的组织方式,以便我们能够协调所做的各种活动以及决定什么时候进行这些活动.本章首先定义什么是过程,以便我们能够理解对软件开发建模时必须包含哪些内容.接着讨论几种软件过程模型.在理解

《团队软件过程(修订版)》—第2章2.1节项目为何失败

第2章 团队软件过程的基本原理团队软件过程(修订版)本章主要介绍TSPi,解释它如何工作以及为何有效.另外,本章还介绍了团队的概念,解释了团队如何工作,并讨论了常见的团队协作问题. 有关团队协作的资料很多,优秀团队和表现不佳的团队的例子也很多.本章不可能涵盖所有资料,只对主要问题做重点介绍.有关团队协作的进一步讨论,可以参考第16章和第17章.本章只是一个简介,在使用TSPi的过程中,你应该仔细阅读本书的每个章节,以深入了解你面对的工作所涉及的主题.本章内容安排如下. 项目为何失败.学习如何处理

《团队软件过程(修订版)》—第2章2.7节小结

2.7 小结团队软件过程(修订版)本章简要介绍了TSPi的基本原理,涵盖了团队的概念.团队的工作原理.解决团队问题的方法等内容.TSPi的设计是为了充分发挥团队的优势,尽量避免团队的弱点及其所造成的影响.TSPi过程使用了明确定义的角色.过程脚本和标准. 软件项目的失败一般是因为团队协作问题,而不是技术问题.一个重要的人员问题涉及工程师处理紧迫的进度压力的能力.TSPi通过制定详细的计划并提供结构化的开发过程,来帮助团队处理这些压力. 成功团队的标准是:团队界定清晰,任务清晰明确,团队成员能控制

《UML用户指南(第2版.修订版)》—第1章1.1节建模的重要性

第一部分 入门UML用户指南(第2版.修订版) 第1章 为什么要建模UML用户指南(第2版.修订版)本章内容建模的重要性建模的4项原理软件系统的基本蓝图面向对象建模成功的软件组织应该总是能够交付满足其用户需要的软件.如果一个软件组织能够及时并可预测地开发出这样的软件,并能够有效地利用人力和物力资源,那么这个软件组织就是可持续发展的. 在上段话里有一个重要的含义:一个开发队伍的主要产品不应该是一堆漂亮的文档.世界级的会议.伟大的口号或者几行获得普利策奖金的源代码,而应该是满足不断发展的用户及其业务

《Google软件测试之道》—第2章2.2节测试认证

本节书摘来自异步社区<Google软件测试之道>一书中的第2章2.2节测试认证,作者[美]James Whittaker , Jason Arbon , Jeff Carollo,更多章节 2.2 测试认证 Patrick Copeland在本书的序中强调了让开发人员参与测试的难度.招聘到技术能力强的测试人员只是刚刚开始的第一步,我们依然需要开发人员参与进来一起做测试.其中我们使用的一个 关键方法就是被称为"测试认证"(译注:Test Certified)的计划.现在回过头

《重构与模式(修订版)》—第1章1.4节测试驱动开发和持续重构

1.4 测试驱动开发和持续重构 重构与模式(修订版) 测试驱动开发[Beck, TDD]和持续重构,是极限编程诸多优秀实践中的两个,它们彻底改进了我开发软件的方式.我发现,这两个实践能够帮助我和公司降低过度设计和设计不足的几率,将时间用在按时地构造出高质量.功能丰富的代码上. 通过测试驱动开发(TDD)和持续重构,我们将编程变成一种对话1,从而高效地使可以工作的代码不断演变. 问:编写一个测试,向系统提问. 答:编写代码通过这个测试,回答这一提问. 提炼:通过合并概念.去芜存菁.消除歧义,提炼你