有哪些信誉好的足球投注网站- 1、本文档共12页，可阅读全部内容。
- 2、有哪些信誉好的足球投注网站（book118）网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。
- 3、本站所有内容均由合作方或网友上传，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务；查看《如何避免下载的几个坑》。如果您已付费下载过本站文档，您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“版权申诉”（推荐），也可以打举报电话：400-050-0827(电话支持时间：9:00-18:30)。
1.设计与架构
软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。
一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量。如果该成本很低，且在系统的生命周期内始终很低，那么这个系统的设计就是优良的。反之，就是不好的设计。
胡乱编写代码的工作速度，其实比循规蹈矩更慢。要想跑得快，先要跑得稳。
2.两个价值维度
行为价值：程序按照需求文档要求的方式工作
架构价值：软件的“软”，即软件的灵活性
艾森豪威尔矩阵
重要且紧急
重要不紧急
不重要但紧急
不重要且不紧急
紧急的事情往往没那么重要，而重要的事情似乎永远也排不上优先级。
第一个价值维度：系统行为，是紧急的，但是并不总是特别重要。
第二个价值维度：系统架构，是重要的，但是并不总是特别紧急。
应有的排序：
重要且紧急
重要不紧急
不重要但紧急
不重要且不紧急
常犯的错误：将第三优先级的事情提到第一优先级去做。导致重要的事情被忽略。
平衡系统架构的重要性与功能的紧急程度，是软件研发人员自己的职责。
建议：为好的软件架构而持续斗争
研发团队必须从公司长远利益出发，与其他部门抗争，公司内部的抗争本来就是无止境的。
软件的可维护性需要由你来保护，这是你的职责，公司雇你的很大一部分原因就是需要有人来做这件事。
3.编程范式
编程范式指的是程序的编写模式。一共只有三种编程范式，而且未来几乎不可能再出现新的（理由是，编程范式都是增加限制，Bob大叔的理解）。
一本谈软件架构的书，为什么要设计编程范式呢？Bob大叔如是说：
多态是我们跨越架构边界的手段，函数式编程是我们规范和限制数据存放位置与访问权限的手段，结构化编程则是各模块的算法实现的基础。
这和软件架构的三大关注重点不谋而合：功能性、组件独立性、数据管理。
结构化编程
可推导性：可以用代码将一些已证明可用的结构串联起来，只要证明额外的代码是正确的，就可以推导出整个程序的正确性
goto语句的某些用法会导致某个模块无法被递归拆分成更小的、可证明的单元。
如果某个结论经过一定的努力无法证伪，则认为它在当下是足够正确的。
测试只能展示bug的存在，并不能证明不存在bug。
软件架构师需要定义可方便证伪（测试）的模块、组件及服务。为了达到这个目的，要将类似结构化编程的限制方法应用在更高的层面上。
面向对象编程
以多态为手段来对源代码中的依赖关系进行控制的能力。这种能力让软件架构师可以构建出某种插件式架构，让高层策略组件与底层实现组件相分离。
函数式编程
架构设计良好的程序，应该将状态修改的部分与不需要修改状态的部分隔离成单独的组件，然后用合适的机制来保护可比量。
4.设计原则
SRP：单一职责原则
人们对单一指责原则的理解，是逐步发展的
每个模块都应该只做一件事。
任何一个软件模块都应该有且仅有一个被修改的原因。
任何一个软件模块都应该只对某一类行为者负责。
OCP：开闭原则
设计良好的计算机软件系统应该易于扩展，同时抗拒修改。换句话说，在不需要修改的前提下就可以轻易被扩展。
一个好的软件架构设计师会努力将旧代码的修改需求量降至最小，甚至为0。如何做到呢？可先将满足不同需求的代码分组（即SRP），然后再来调整这些分组之间的依赖关系（即DIP）。
LSP：里氏替换原则
任何基类可以出现的地方，子类一定可以出现。
在架构上的意义，可以理解为插件式的架构，插件之间、子服务之间的可替换性。
ISP：接口隔离原则
任何层次的软件设计如果依赖了它并不需要的东西，就会带来意料之外的麻烦。
DIP：依赖反转原则
如果想要设计一个灵活的系统，在源代码层次的依赖关系中就该多引用抽象类型，而非具体实现。
相对而言，接口比实现更稳定。如果想要在软件架构设计上追求稳定，就必须多使用稳定的抽象接口，少依赖多变的具体实现。
应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类。
不要在具体实现类上创建衍生类
在静态类型的编程语言中，继承关系是所有源代码依赖关系中最强的、最难被修改的，所以应该格外小心。
不要覆盖（override）包含具体实现的函数
应避免在代码中写入与任何具体实现相关的名字，或者是其他容易变动的事物的名字。
5.组件构建原则
组件聚合
REP：复用/发布等同原则
软件复用的最小粒度应等同于其发布的最小粒度。
一个组件内的类和模块之间，应该有一个共同的主题或大方向。
一个组件内的类和模块还应该可以同时发布。
CCP：共同闭包原则
单一职责原则在组件层面上的再度阐释。
要将所有可能被一起修改的类集中在一处。
将由于相同原因而修改，且需要同时修改的东西放在一起。
CRP：共同复用原则
接口隔离原则的一个普适版本。
不要强迫一个组件的用户依赖他们不需要的东西。
将经常共同复用的类和模块放在同一个组件中。
组件聚合原则张力图（TO
文档评论（0）