Терминология: В чем разница между классом и компонентом?

Question

В парадигме ОО, мы решили использовать классы, потому что они помогают нам сломать систему вниз, и обеспечивают приятные побочные выгоды, такие как инкапсуляция, разделение обязанностей, наследование, модульность и т.д.

Если мы посмотрим на программную систему на уровне компонентов, можем ли мы просто рассматривать компоненты одним и тем же концептуальным образом, т. е. компонент является просто «большим классом»? Или это еще не так?

Какие дополнительные соображения следует учитывать при проектировании компонентов?

EDIT:

Я знаю, что класс и компонент разные вещи. Я также понимаю, что компонент может содержать много классов, каждый из которых имеет свои собственные роли и обязанности.

Я посмотрю, смогу ли я объяснить себя лучше.

• Классы позволяют нам решать большие проблемы, потому что они позволяют нам мыслить и проектировать более абстрактно.
• Существуют правила & техники для определения того, как разбивать и назначать данные и функции классам.

Это похоже на очень похожую ситуацию с конструкцией компонентов, только на более высоком уровне абстракции. Используются ли методы, используемые для определения того, какие классы необходимы для масштабирования до компонентов, и/или существуют ли другие вещи, которые влияют на дизайн системы высокого уровня, которые не применяются на уровне абстракции класса?

Answer 1

Что делать с использованием фазы или роли проекта для их дифференциации?

Например компонент представляет собой дизайн-единица времени (системные архитекторы, конструкторы) в то время как класс является реализацией-единица времени (программисты). Поэтому разработчики говорят о компонентах (или подсистемах или модулях, ящиках верхнего уровня в вашем графическом чертеже), тогда как программист говорит о компонентах и ​​классах (которые реализуют компоненты).

В этом представлении компонент реализуется одним или несколькими классами.

Answer 2

Eh?

Компонент «Загрузка файла» может состоять из множества классов: Страница получить файл, класс, чтобы сохранить его и т.д.

Answer 3

Я часто думаю о компоненте в смысле UML (см Wikipedia описание), в результате чего он представляет собой «модульную часть системы». В этом смысле он имеет тенденцию представлять большую функциональность, чем класс, и на самом деле может состоять из нескольких классов.

соображения я бы дать к проектированию компонентов являются:

• Как это может быть использована повторно. В частности, каковы предпосылки использования чего-то как компонента, а не кода на заказ (как град, который я использовал, чтобы сделать все повторно используемым!)
• Предоставление разумных интерфейсов, а в некоторых случаях и дополнительных упрощенных интерфейсов, возможно, используя шаблон Facade.

Надеюсь, что это поможет.

Answer 4

В этом (гипотептическом) контексте компонент можно рассматривать как серию классов.

Однако в зависимости от используемой технологии компоненты могут быть более набором классов. т. Е. Они могут иметь дополнительные свойства и функциональные возможности, которые не являются частью классов, которые их образуют. , например. компонент COM +.

Так что это зависит от конкретной ситуации.

Answer 5

В соответствии с UML v2 specification:

8.3.1 Компонент (от BasicComponents, PackagingComponents)

Компонент представляет собой модульную часть системы , который инкапсулирует его содержание и которых проявление сменный в его среде.

Компонент определяет его поведение в терминах прилагаемых и требуемых интерфейсов. В качестве такой компонент служит типом , соответствие которого определяется этими прилагаемыми и необходимыми интерфейсами (охватывающих как их статические как так и динамическую семантику). Таким образом, один компонент может быть заменен другим, только если оба типа соответствуют типу . Большие куски функциональности системы могут быть собраны за счетом повторного использования компонентов, как частей в качестве охватывающего компонента или сборки компонентов и проводка вместе их необходимых и при условии интерфейсов.

Когда вы используете это определение, компоненты выглядят примерно Inversion Of Control.

В качестве примера для интерфейса .NET для интерфейса IComponent действительно предоставляется IComponent. Site. GetService, чтобы добиться инверсии управления через шаблон поставщика услуг. Более легкая альтернатива - инъекция зависимости.

Answer 6

компоненты являются подсистемами классов. Классы обеспечивают основную низкий уровень светокопию интерфейса объекта, а компоненты добавляет некоторые функциональные возможности.