既然类和组件有着这么多类似的地方，那么传统的面向对象编程和面向组件编程有什么区别呢？简单的说，面向对象关注的是组合在一个二进制可执行文件中的各个类的关系，而面向组件的编程关注的是在彼此独立的基础上模块之间的交互性，这种交互性使得你并不需要熟悉它们内部的工作原理。
分而治之 VS 集大成
这两种方法最基本的不同在于它们对最终的应用程序的观点。在传统的面向对象编程中，尽管你可以精心的把所有的商业逻辑分布在不同的类中，一旦这些类被编译，它们就被固化成了一个巨大的二进制代码。所有的类共享同一个物理单元（通常是一个可执行文件）、被操作系统认为是同一个进程，使用同一个地址空间以及共享相同的安全策略等等。如果多个开发者在同一份代码上进行开发，他们甚至还要共享源文件。在这种情况下，修改一个类可能会让整个项目被重新链接，并重新进行必要的测试，更严重的，还有可能要修改其他的类。但是，在面向组件开发中，应用程序是由一系列可以互相交互的二进制模块组合而成的。
一个具体的二进制组件可能并不能完成什么工作。有些组件是为了提供一些常规服务而编写的，例如通信的封装或者文件访问组件。也有一些是为了某些特定应用而专门开发的。一个应用程序的设计者可以通过把这些不同的组件提供的功能粘合在一起来实现他们需要的商业逻辑。很多面向组件的技术——例如：
COM
、
J2EE
、
CORBA
和
.NET
都为二进制组件提供了的无缝链接的机制。而唯一的不同就是你需要在组件通信上花费的力气。
把一个二进制应用程序分解成不同的二进制组件的动机和把不同的类放到不同的文件中是类似的。后者使得不同的类的开发人员可以彼此独立的工作，尽管即时修改了一个类也要重新链接整个应用程序，但是你只需要重新编译被修改的部分就可以了。
但是，面向组件的开发还是和简单软件项目的管理更复杂一些。因为一个面向组件的应用程序是一个二进制代码块的集合，你可以把组件当作是
LEGO
的积木块一样，随心所欲的拆装它们。如果你需要修改一个组件的实现，只需要修改那个组件就可以了，而组件的客户机不需要重新编译也不需要重新开发。对于那些不常用到的组件，组件甚至可以在一个程序运行的时候被更新。这些改进和增强使得组件可以立即进行更新，而所有该组件的客户都将立即受益。无论是在同一台机器上还是通过网络远程访问。
面向组件的应用程序也更易于扩展。当你需要实现新的需求的时候，你可以提供一个新的组件，而不去影响那些和新需求无关的组件。这些特点使得面向组件的开发降低了大型软件项目长期维护的成本，这是一个最实际的商业问题，也正是如此，组件技术才如此迅速的被接受。
面向组件的应用程序通常可以更快的响应市场，因为你可以有很大的选择空间，不仅仅是自己开发的组件，还可以从第三方厂商来购买某些组件，从而避免了重复制造轮子。这里，
VB
就是一个很好的例子，丰富的
ActiveX
控件使得很多人在快速开发中得到了享受。
接口还是继承
面向对象和面向组件另一个重要的不同在于这两种技术在继承和重用模型上的侧重点不同。
在面向对象的分析和设计中，应用程序通常被分解成复杂的类继承结构。类的设计和要解决的商业问题紧密结合。你可以从已有基类继承并特化其行为来实现代码重用。问题在于，这是一种很糟糕的重用的方法。当你从一个基类派生一个子类的时候，你必须对基类的实现有透彻的理解才可能保证不出问题。例如：修改一个成员变量会不会带来副作用？这会对基类中的代码有什么影响？重载基类的方法会不会破坏那些想使用基类版本的客户的行为？等等。
这种形式的重用被称为白盒重用（White-box reuse）,因为当你重用的时候你就需要去了解基类实现的细节。显然。白盒重用在可扩展性较高的大型应用中并不经济，也很难得到第三方Framework厂商的支持。
面向组件的开发采用了黑盒重用（Black-box reuse）的方法，它可以让你对组件内部全然不知的情况下来使用组件公开的接口。这样，你就可以远离那些复杂的继承关系。而面向组件的开发者也可以把更多的精力放在制定组件和客户的沟通的接口上了。
最后，面向对象编程提供了有限的工具和设计模式来处理和应用程序运行时相关的问题，例如多线程、并发管理、安全、分布式应用和版本控制等。面向对象的开发者当面对这些“公共需求”的时候，或多或少的需要自己来解决问题。但是面向组件的开发方式却使你在这方面要灵活的多。