术语：类和组件有什么区别？
在 OO 范式中，我们选择使用类，因为它们帮助我们分解系统，并提供很好的附带好处，例如封装、职责分离、继承、模块化等。
如果我们在组件级别查看软件系统，我们是否可以简单地以相同的概念方式对待组件，即组件只是一个“大类”？ 或者还有比这更多的事情吗？
设计组件时必须额外考虑哪些因素？
编辑：
我知道类和组件是不同的东西。 我还了解到，一个组件可能包含很多很多类，每个类都有自己的角色和职责。
我会看看是否可以更好地解释自己。
- 类使我们能够解决更大的问题，因为它们使我们能够更抽象地思考和设计。
- 有规则& 确定如何分解数据和功能并将其分配给类的技术。
这看起来与组件设计的情况非常相似，只是处于更高的抽象级别。 用于确定需要哪些类的技术是否可以扩展到组件，和/或是否存在其他影响高级系统设计但不适用于类抽象级别的因素？
Within the OO paradigm, we choose to use classes because they help us to break the system down, and provide nice side benefits such as encapsulation, separation of responsibilities, inheritance, modularity, etc.
If we look at a software system at the component level, can we simply treat components in the same conceptual way, i.e. a component is simply a "Big Class"? Or is there more to it than that?
What extra considerations must be given when designing components?
EDIT:
I know that a class and a component are different things. I also understand that a component may contain many many classes, each of which have their own roles and responsibilities.
I'll see if I can explain myself better.
- Classes allow us to solve bigger problems because they allow us to think and design more abstractly.
- There are rules & techniques to determine how to break down and assign data and functionality to classes.
This seems like a very similar situation to that of component design, just at a higher level of abstraction. Do the techniques used to determine what classes are needed scale up to components, and/or are there other things that affect a high-level system design that don't apply at the class abstraction level?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
呃？
“文件上传”组件可能由很多类组成：接收文件的页面、保存文件的类等。
Eh?
The "File Uploading" component may consist of lots of classes: Page to receive the file, class to save it, etc.
组件是类的子系统。类提供对象接口的基本低级蓝图，而组件则添加一些功能到它。
components are subsystems of classes.Classes provide the basic low level blueprint of an object interface while components adds some functionality to it.
在这个（假设的）上下文中，一个组件可以被认为是一系列的类。
然而，根据您使用的技术，组件可以不仅仅是一组类。
即它们可能具有附加的属性和功能，这些属性和功能不属于形成它们的类的一部分。
例如 COM+ 组件。
所以这确实取决于具体情况。
In this (hypothethical) context a component can be thought of as a series of classes.
However depending on the technology you use, components can be more then a set of classes.
i.e. They may have additional properties and functionality which is not part of the classes which form them.
e.g. a COM+ component.
So it depends on a specific situation really.
根据 UML v2 规范：
当您使用此定义时，组件似乎都是关于控制反转。
以 .NET 框架为例，
IComponent接口确实提供了 IComponent。网站。GetService 到通过服务提供者模式实现控制反转。 一种更轻量级的替代方案是依赖注入。According the UML v2 specification:
When you use this definition, components appear to be all about Inversion Of Control.
Looking at the .NET framework for an example, the
IComponentinterface indeed provides IComponent.Site.GetService to achieve inversion of control through the service provider pattern. A more light-weight alternative is dependency injection.使用项目阶段或角色来区分它们怎么样？
例如，组件是设计时单元（系统架构师、设计师），而类是实现时单元（程序员）。 因此，设计师谈论组件（或子系统或模块，架构图中的高级框），而程序员谈论组件和类（实现组件）。
在此视图下，组件由一个或多个类实现。
what about using the project phase or role to differentiate them?
For example a component is a design-time unit (system architects, designers) whereas a class is an implementation-time unit (programmers). So designers speak about components (or subsystems or modules, the hight-level boxes in your architecture drawing) whereas programmer speak about components and classes (that implements components).
Under this view a component is implemented by one or more classes.
我经常在 UML 意义上思考组件（参见 Wikipedia 描述），由此它代表“系统的模块化部分”。 从这个意义上说，它往往代表比类更大的功能，并且实际上可以由多个类组成。
我在设计组件时要考虑的是：
希望有帮助。
I often think of Component in the UML sense (see Wikipedia description), whereby it represents a "modular part of a system". In this sense it tends to represent a larger piece of functionality than a class and could in fact be composed from multiple classes.
Considerations I would give to designing components are:
Hope that helps.