Как вы определяете программный компонент?

Question

Как вы определяете программный компонент и какие отношения существуют между ООП и компонентным программированием? Каковы плюсы и минусы и каково «золотое сечение» этих парадигм?

Answer 1

Мне кажется, что Компонент - это концепция организации более высокого уровня, чем Объект.

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

Если вы разрабатываете компонент на каком-либо языке ОО, вы затем распределяете обязанности и получаете дизайн ОО для этого компонента.

Answer 2

Я думаю, что компонентное программирование - это, по сути, переосмысление oo.

оо, стремился быть черным ящиком ... но не так, компонентное программирование пытается быть черным ящиком.

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

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

Таким образом, вы бы обеспечили поддержку потоков и асинхронности. Вы бы опубликовали интерфейсы, документацию и юнит-тесты. Иметь четкую структуру событий и поведение.

Практически все, что вы можете, чтобы позволить кому-то повторно использовать его и помочь ему в этом.

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

Answer 3

Степень детализации программного компонента должна соответствовать степени повторного использования. Если кусок программного обеспечения повторно используется в другом месте, то его следует создавать и выпускать как его собственный компонент. Если он не используется повторно в другом месте, это добавляет мало значения.

Было бы удивительно, если бы что-либо меньшее, чем полный класс, считалось компонентом и ожидало, что набор классов сформирует компонент.

Answer 4

Я бы подумал о Компоненте как о подсистеме приложения, которую вы можете рассматривать как Черный ящик.
Таким образом, в OOD это группа классов и интерфейсов с четкой спецификацией, целью которой является ОДИН ОЧИСТКА, которая позволяет вам выполнять некоторые вычисления, не зная, из чего состоит коробка.

Ввод -> [BlackBox] -> Выход

Что дальше определяет компонент:

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

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