所有多视图方法，【分而治之】和【水平思考】是思维关键，我将专文论述。

作为一种著名多视图方法，RUP 4+1视图区别于其他多视图方法的特点有三：倚重OO、倚重用例、倚重建模。

本次谈谈OO与4+1视图的关系。

4+1视图倚重OO

80年代到90年代OO技术是大有作为，例如许多人都知道C++是1985年横空出世的。4+1视图方法根植于Philippe Kruchten的一线架构设计实践，所以4+1视图方法倚重OO并不令人奇怪。

另一方面，几个问题很有价值：

• 4+1视图方法，是OO方法的分支吗？
• OO高手，就想当然的是架构师了吗？
• 难道大量采用C语言编程的嵌入式领域不需要多视图？
• ……

于是，在每个人的心里留下了一个大大的问号：OO方法 与 多视图的架构设计方法到底什么关系？

观察：网上如是说

言外之意，架构师只需要OO技能？

放眼业界，还有人认为OO涵盖了需求工程、甚至业务工程……

不一而足。

反思：OO的作用被夸大了

提问：F r a m e w o r k技术是OO的分支，对吗？

回答：不对。

F r a m e w o r k本质上和面向对象无关，用C语言也可编写F r a m e w o r k。更切近本质的F r a m e w o r k的定义是：可以通过某种回调机制进行扩展的软件系统或子系统的半成品。

……的确，OO方法太流行了，以至于很多技术都“变成”了OO的分支。

回归主题：OO与4+1视图

认为OO方法已完整涵盖了架构设计的所有方法和技巧，这种看法是相当片面的。

若OO方法已涵盖架构设计的全部，那么多视图方法所涉及的逻辑架构、物理架构、开发架构、运行架构、数据架构，都应全面受到OO方法的指导，然而实际上并不是这样。

因为，物理架构、开发架构、运行架构和数据架构这4个架构视图，分别是面向节点、面向文件、面向控制流和面向Table（或文件）的——也就是说，一般认为这4个架构视图主要的思维并非OO思维。

另一方面，即使是逻辑架构的设计，也未必都是以OO方法为指导的。例如，大量嵌入式软件和系统软件还是以C语言为主要开发语言，其逻辑架构设计还会以结构化方法为指导。如此看来，倒是将逻辑架构设计总结为“面向职责”更切近本质。

一图总结：多“面”手

• 多视图方法，不是OO方法的分支。
• 无论是OO方法，还是结构化方法，都远未涵盖架构设计的全部。
• 只具有OO技能对架构师而言是不够的。