《架构之美》阅读笔记06

一、阅读内容

第五部分

第十三章 软件架构:面向对象与面向函数

第十四章 重读经典

二、笔记总结

(1)面向对象与面向函数

函数式编程能够更好的实现模块化设计。在面向对象的编程方式出现之后,我们发现面向对象的程序设计,特别是支持高级例程对象或者代理的现代形式包含了函数式编程,在保留了函数式编程的同时也提供了高层的抽象,更好的支持了扩展和复用。下面具体分析一下这两种软件架构。首先是函数式的编程方法。显然,这样的编程方式的伸缩性不好,对于较大型的项目而言,必然需要将这个项目分在不同的模块中。那么现在的扩展性问题就变成了如何使这样的修改影响到的模块尽可能的少。在模块之外很难对模块的行为进行修改。但是函数式编程依然有着十分重要的优点。第一个是简洁的定义。这和常见的命令式编程语言中的例程声明相比,语法负担要小得多。第二个优点是定义对象的组合子表达式的优雅型。另外两个优点则更显基础性。首先是能让操作成为最能够被高效处理的部分,另一个是延迟计算,能够描述一个可能无限大的计算,当然该计算的任何具体执行过程都将是有限的。面向对象编程的好处就太多了,毕竟这时当前主流的编程思想,相关的介绍已经很多了。比如维护简单。模块化是面向对象编程中的一个特征。实体被表示为类和同一名字空间中具有相同功能的类,我们可以在名字空间中添加一个类而不会影响该名字空间的其他成员。再比如可扩充性。面向对象编程从本质上支持扩充性。如果有一个具有某种功能的类,就可以很快地扩充这个类,创建一个具有扩充的功能的类。更重要的是代码重用。由于功能是被封装在类中的,并且类是作为一个独立实体而存在的,提供一个类库就非常简单了。事实上,任何一个.NET Framework编程语言的程序员都可以使用.NET Framework类库,.NET Framework类库提供了很多的功能。更令人高兴的是,我们可以通过提供符合需求的类来扩充这些功能。

(2)关于本书的思考

通过对本书的阅读,我更加认识到了软件开发和建筑物的构造过程有着异曲同工之妙。软件架构重点关注的是软件的整体,如何用一种适合系统功能需求以及非功能需求的结构方式去构建系统中的各个组件以及它们的交互过程。从一开始,软件架构从一开始就关注了整个系统的功能需求和非功能需求,在全局层面上对系统软件进行规划。一个很明显例子,如建造一个新的城市,要考虑城市建造的要求,同时还要考虑到城市与周边和地形的关系,从而决定采用什么样的架构,决定建造一个什么样的城市,如园林式还是其它式的。值得一提的是:一个具体的系统,由于系统很大,还可以划分成很多个小的子系统,那么子系统同样也需要规划的,也即同样要进行架构设计。如上述例子中具体的一个房子,要看它的功能需求是什么,如果一个办公大楼,它的局部设计架构与一个私人住宅肯定是不同的。

时间: 2024-10-13 22:15:20

《架构之美》阅读笔记06的相关文章

用户故事与敏捷方法阅读笔记二

第8章 估算用户故事 使用故事点 我们用“速率”(velocity)来代表一个团队在一轮迭代中完成(或期望完成)的故事点数.因此,务必保证每次迭代的故事点的度量是一致的. 如果用结对编程呢? 团队用不用结对编程,对故事点估算并没有影响.团队可以采用理想结对日或理想个人日来估算故事点,区别会表现在速率值上. 一些提醒 一个故事(可能是一个史诗故事)分解成一些小故事后,这些小故事估算的总和不需要与开始那个故事或史诗故事的估算相等. 类似地,一个故事分解成一些任务.这些任务估算的总和不需要与故事的估算

用户故事与敏捷方法阅读笔记三

第12章:故事是什么 用户故事有别于IEEE 830软件需求规格.用例和家傲虎设计场景. 考虑用户的目标比列出方案的特性更重要. 用户故事与用例场景类似.他们的完整性和寿命不同.他们以不同的目的编写. 第13章:用户故事的优势 用户故事促使我们重视口头交流,这一转变提供了迅速的反馈周期. 用户故事的典例范围比用例及场景小.他适合于迭代开发.鼓励延迟细节,鼓励应变的开发. 第14章 用户故事不良症兆一览 故事太小:故事相互依赖:镀金:故事中包含太多的细节:过早包含用户界面细节:想的太原:故事划分太

用户故事与敏捷方法读书笔记02

开发软件可以通过编写用户故事来确立开发的目标和方向.而在编写故事前首先要对所有用户进行分类,根据角色的不同属性进行分类.步骤为:1.通过头脑风暴,列出初始的用户角色集合:(要坚持‘已确认的角色代表的是单一用户’的原则)2.整理最初的角色集合:(确认角色之间的关系:用户角色定义的是人而不是外部系统)3.整合角色:(对于完全重叠的用户进行重新定义,舍弃对系统成功作用不大的角色)4.提炼角色(根据角色特征来建立角色的模型). 编写故事之前需要搜集故事,通过与用户沟通来发现故事.可以像用渔网捕鱼一样获取

《用户故事与敏捷方法》阅读笔记01

用户故事与敏捷方法第一章是对用户故事的概览.      首先第一个问题用户故事是什么?用户故事描述了对用户.系统或软件购买者有价值的功能.用户故事由三个方面组成,包括1 .一份书面的故事描述,用来做计划和作为提示.2.有关故事的对话,用于具体化故事细节.3.测试,用于表达和编档故事细节且可用于确定故事何时完成.      然后第二个问题细节,故事的细节可以用另外的用户故事来描述,多个小故事远远胜于一个庞大的故事.书上将大的故事成为史诗故事,那些史诗故事可以分为多个小故事.例如将"用户可以搜索工作

《用户故事与敏捷方法》读书笔记

1.采用用户故事这一方法,是从写下两条信息开始的:每一个系统需要实现的目标和实现那个目标所需要的大致成本. 2.3C原则:"card.conversation.confirmation",任务卡片.交流.确认 3.大量预先的需求收集和文档会议很多方式导致项目失败.最常见的是需求文档变成软件开发的目的.应当只在对交付软件有用时才写需求文档. 4.对用户故事的最佳诠释:卡片包含故事的文字描述,然后需求细节要在"对话"中获得,并在"确认"部分得以记录.

《用户故事与敏捷方法》阅读笔记06

第八章 估算用户故事 故事点有一个很好的特性是团队可以定义自己认为合适的故事点,一个团队可能定义一个故事点为一个理想日的工作,也可能定义为一个理想周的工作.故事点有很多意义,所以故事点代表时间的模糊单位. 故事估算应该由整个团队集体来完成.故事估算属于团队集体有两个原因,第一个,还不确定团队中谁负责完成这个故事,第二个,团队决定的估算可能比个人估算更有用.在估算时,作者介绍了他所用的方法迭代的方式进行估算.在初步估算好后,成员进行讨论,然后进行下一轮的讨论,最终达成一致. 三角测量.估算一个故事

《用户故事与敏捷方法》阅读笔记05

第13章 用户故事的优势 从上一章我们得知,处理需求的方法多种多样,但是我们为什么要选择用户故事?因为它会带来多种好处: ①用户故事强调口头沟通:自古以来,口头表达是十分重要的.而且相比于书面书写的易产生歧义,口头表述更见简单明了,需求文档也是如此. ②人人都可以理解用户故事:相比于一些墨守成规的软件需求里的技术术语,用户故事使用的语言更容易使用户理解,简洁明了,同时更能增强用户对故事的记忆. ③用户故事的大小适合做计划:其他类型的需求分析关联性太强,并且还比较笼统,大小不能称得上是易实现的适合

《用户故事与敏捷方法》阅读笔记03

第10章 迭代计划 制定出上一章的成果发布计划,我们可以顺利地将粗细度的故事分配到多伦迭代中.多伦迭代是发布计划的进一步激化,但只在迭代即将开始的时候才开始做迭代计划.为此,迭代计划会议必不可少,客户以及团队的所有人员都要参与其中.在这一过程,各个人员仔细讨论每个故事,从故事中分解出任务,开发人员承担每个任务的职责.这个会议是客户为团队调整故事的最佳时机,但是切记项目团队不要随意被客户打乱开发计划. 任务的大小没有强制的范围(例如:3小时到5小时).相反,从故事中分解任务,用来帮助估算或鼓励多个

读《用户故事与敏捷方法》有感(五)

今天,读到了次本书的第三部分--经常讨论的话题,用户故事不是什么,用户故事的优势与不良征兆. 第一,用户故事不是软件需求规格的指南,这种需求规格指南强调的是"系统应该--",而且对于需求规格指南而言,在写下需求之前,每个需求的成本是不可见的.典型的情况是,一个或几个分析师花两三个月时间(通常更长时间)编写出冗长的需求文档.随后把文档交付给程序员.这时程序员告诉分析师(消息会被转告给用户),完成项目要24个月,而不是分析师所希望的6个月.在这种情况下,分析师在编写团队没有时间开发的四分之

用户故事与敏捷方法①

在读这本书之前,自己觉得有点好奇,用户故事指的是什么呢,读完之后,有了体会:用户故事描述了对用户.系统或者软件购买者有价值的功能.它由3方面组成:1>一份书面的故事描述,用来做计划和作为提示:2>有关故事的对话,用于具体化故事细节:3>测试,用于表达和编档故事细节且可用于确定故事何时完整. 它总共分为了五大部分来介绍: 第一部分是一些简单的概念或者使用故事的细节方面,比如如何编制用户故事,有哪些细节要求:在故事中找出用户角色模拟使用情节:怎样搜集到用户故事,通过各种途径:如何找到用户代理