一、面向对象软件架构设计思想
a)面向对象范式
i.面向对象范式的核心是“对象”的概念
ii.所有的东西都聚焦于对象
iii.围绕对象-而非函数-组织代码
b)对象从不同视角观察
i.概念层：一个对象是一系列责任
ii.规格层：一个对象是一系列可以被其他对象或该对象自己调用的方法
iii.实现层：一个对象是一些代码和数据
c)设计原则
i.“开闭”原则(OCP)
ii.里氏代换原则(LSP)
iii.依赖倒转原则(DIP)
iv.接口隔离原则(ISP)
v.组合/聚合复用原则(CARP)
vi.迪米特法则(LoD)
二、使用UML进行软件架构设计
a)最小UML建模技术
i.对于大多数问题而言，只需使用20%的UML，就可以完成80%的建模工作。
ii.实际中，好像总是没有足够的时间来完成建模、分析和设计工作，总是过早地进入到编码阶段。
iii.足以很好地完成软件项目工作所需的、最小的UML和建模技术子集。
b)类图规定了代码的结构
c)时序图将操作分配给类。时序图是非常重要的一种图，它能直观地展现各个类和用例如何运作。能使模糊的组织运作变得清晰。
三、设计模式的本质论
a)模式是从解决具体问题抽象出来的，这种具体问题在特定的上下文中重复出现。也就是说，每个具体形式都对一种重复的问题采用重复的解决方案。
b)理解设计模式的结果和代价
i.对象过多：设计模式的精髓之一是将可变部分封装为对象，带来的好处是系统更加灵活，易于维护，但也大量增加了对象。如果不恰当地使用设计模式，会使系统难以调试。
1.命令模式：将行为封装为对象，这样原来一个对象中的若干方法变成了若干命令对象。如果将命令模式应用在一个GUI用户界面上，每一个菜单项就要生成一个命令对象，原来由一个对象完成的工作现在可能需要十几个对象来完成。
2.状态模式：将不同的状态封装为对象，原来可能是通过判断语句完成的工作分散到各个对象中完成。由于状态是动态决定的，因此在设计测试用例时有难度。
ii.更复杂的装配关系：很多设计模式依赖对象之间的关系，因此在初始化时需要执行相应的装配工作，需要装配对象的模式有如下几种。
1.生成器模式：需要装配生成器和导航器。
2.桥接模式：需要将代表逻辑的对象和代表实现的对象进行装配。
3.观察者模式：需要将不同的观察者对象关联在一起。
4.职责链模式：需要组装整条职责链。
iii.测试难度加大：这是前面两个结果导致的，由于对象的增多和对象间关系的复杂，因此测试用例的设计难度增大。特别是很多逻辑上的错误可能由装配关系不当造成，并且在编译时很难发现。解决测试难度大的方法是将测试用例文档化，即绘制测试用例的对象图。这个话题超出了本书的范围，有兴趣的读者可参考相关书籍。
iv.程序结构复杂：设计模式关注的是如何使软件更具可维护性，因此从结构上已经与原始的需求完全不同。加上很多功能是通过对象的动态组合实现的，程序的动态结构变得与静态结构同样重要。从单纯的静态结构(例如类图)已经很难理解实现的方式和最终的意图了，这也是经常是使用设计模式的代价之一。
c)设计模式不能做什么
i.设计模式不是法则
模式理论的精髓之一就是模式的使用是有前提和代价的，模式是在某种前提下，综合各方面因素后考虑得出的结果。即在使用模式时总是要付出一定的代价，当然这种代价是可以接受的。如果某个模式在所有场合中的使用都是必然的，那么它就不能叫做模式了，而是一种必须遵守的法则。例如“面向接口，而非实现编程”，是法则而非模式。
ii.不能提高开发速度或者形象开发速度
如果以一个开发周期作为考核标准，恐怕没有人会使用设计模式。设计模式并不能提高目前的开发速度，至少其关注的目标并不是开发速度。很多情况下甚至会降低开发速度，即使是正确地选择了设计模式。
这是因为设计模式可能会引入更多的对象和更复杂的对象装配关系，从而使得程序有更多的动态状态，从局部看来变得结构复杂，难以理解并且测试困难。如果仅仅关注于形象进度，或者能够百分之百地确定需求没有变化，那么设计模式并不是很好的选择。
iii.不是万能的
设计模式的使用是自然而然的事情，很多情况下不使用设计模式是因为不需要，问题还没有复杂到非用不可的程度。我们是为了设计而使用设计模式，而不是为了使用设计模式而设计。
当你的项目发现有如下问题之一时，就需要考虑重构代码，可能会有某种模式适合。
(1)代码无法进行单元测试。
(2)需求的变动总是导致代码的变动。
(3)有重复代码存在。
(4)继承层次过多。
(5)隐藏的依赖过多。
四、设计模式与架构模式
a)主要架构模式
i.流程处理模式
ii.客户/服务器模式、
iii.模型—视图—控制器模式(MVC)
iv.分层模式
b)确立软件架构考虑的因素
i.架构中包的数量
ii.架构中包之间的耦合度
iii.软件元素的稳定性软件开发网
iv.软件元素的分类
v.作为软件系统运行环境的物理网络拓朴
vi.软件元素的安全、保密级别
vii.开发团队的技术专长
viii.调整软件架构，支持并行开发
看了这里之后才了解MVC模式与GOF那些设计模式有什么区别，
MVC模式属于架构模式，特别适合应用于分布式应用系统。
大型软件的顶层架构往往需要使用多种架构样式。如，整个目标软件系统采用分层结构，在系统的不同层次内再分别使用适宜的其他类型的架构模式。