Как вы определяете программный компонент и какие отношения между ООП и программированием компонентов? Каковы плюсы и связи и что такое «золотое соотношение» этих парадигм?Как вы определяете программный компонент?
Я думаю, что программирование компонентов - это, по сути, переосмысление оо.
оо предназначено быть черным ящиком ... но нет, компонентное программирование пытается быть черным ящиком.
В результате я думаю, что программирование компонентов подразумевает конструкцию (положительно) - потому что для того, чтобы быть черным ящиком, вы должны предвидеть будущие варианты использования и уже обслуживали их.
Это также подразумевает психологию документации тщательного тестирования, которая, по моему опыту, в любом случае, кажется, занимает заднее место в оо-кодировании.
Таким образом, вы предоставили бы поддержку потоков и асинхронную поддержку. Вы будете публиковать интерфейсы, документацию и модульные тесты. Имеют четкие структуры событий и их поведение.
По существу все, что вы можете позволить кому-то повторить его использование и помочь им сделать это.
Дело в том, что компонент имеет четко определенный интерфейс и четко определенную функцию. Реальные детали реализации не являются частью этого, потому что они не входят в сферу применения при рассмотрении вопроса о том, как использовать компонент. Т.е. компонент может быть довольно сложным набором объектов.
Гранулярность компонента программного обеспечения должна соответствовать степени детализации повторного использования. Если кусок программного обеспечения используется повторно в другом месте, он должен быть версией и выпущен как его собственный компонент. Если он не используется повторно в другом месте, это добавляет мало значения.
Было бы удивительно, если бы что-то меньшее, чем полный класс, считалось компонентом и ожидало, что набор классов будет составлять компонент.
Я думаю о Компонента как о более организованной концепции более высокого уровня, чем о объекте.
Компоненты часто являются единицами выпуска и развертывания. Вы ожидаете определить как интерфейсы, которые они выставляют, так и их зависимости от других компонентов и аспектов инфраструктуры. Различные компоненты в системе могут быть хорошо разработаны с использованием самых разных технологий, и, действительно, один компонент не обязательно должен быть однородным.
Если вы разрабатываете компонент на каком-то языке OO, вы затем разложите обязанности и приступите к разработке OO для этого компонента.
Теоретически можно полностью создать систему как иерархию OO без каких-либо компонентов. Я должен согласиться с Говардом, что зернистость повторного использования, по-видимому, определяет, какой и какой должен быть компонент. – citn
Я бы подумал о компоненте как подсистеме приложения, которую вы можете рассматривать как черный ящик.
Таким образом, в OOD группа классов и интерфейсов с четкой спецификацией является ОДНОЙ ЧИСТОЙ целью, которая позволяет выполнять некоторые вычисления, не зная, из чего сделан ящик.
Input -> [BlackBox] -> Выход
Что Furter идентифицировать компонент не является:
Компонентное программирование Я думаю, что на самом деле собираются компоненты для создания более крупных приложений.
В очень «утопическом» представлении должны быть общедоступные хранилища, где вы можете найти компонент, который заполняет вашу спецификацию. Как только вы найдете компонент, вы можете интегрировать его в свое приложение.
Я бы сказал, что класс - это черный ящик (один надеется), который работает в контексте программы, тогда как компонент будет черным ящиком, который работает в контексте нескольких разных программ, в том числе некоторых, которые еще не написаны. –
да, согласился. Я думал об этом, но так и не получил слов;) –