М. Безверхов

Определение компоненты

Допустим, компонентное программирование это - программирование из компонент. Что компонентным программированием вы именуете? Хороший вопрос:

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

В моем понимании, на самом верхнем уровне 'компонентное программирование' это - подход. Примерно такое же явление, как 'объектное программирование'. Только вот, 'объект' - понятие больше философского и модельного качества, а 'компонента' - конструкторского. Всякий, кто перед тем, как начать писать программы на С++ писал перед этим программы на С должен меня очень хорошо понять в этом определении. Ведь С++ не сильно от С и отличается. Синтаксис похож, компилятор - один и тот же... а какие разные языки! Разные, прежде всего тем, что для эффективного их использования программист должен мыслить разными категориями. Процедурный подход (С) кристаллизует 'чистое действие', а объектный (С++) - 'взаимодействие', т.е. C++ явно и формально вводит понятие 'объекта, в отношении которого совершается действие'. И переход в собственной голове от одной парадигмы мышления к другой - не такая и простая задача. Зато потом, когда парадигма моделирования взаимодействия объектов становится естественной и привычной обнаруживается, что эта парадигма намного больше, чем сам язык С++, что С++ - всего-навсего частная реализация 'средства моделирования'. А сам подход может быть назван не меньше, чем 'философией взгляда' и реализуется он исключительно в голове программиста - написать на C++ ужасную, непонятную и абсолютно ненадёжную программу намного легче, чем, скажем, на Visual Basic!

Всё то же можно сказать и про 'компонентное программирование' - это философия взгляда программиста на конструирование своих изделий. Конечно, сейчас существуют технологии и средства, которые построены на этой философии, но всё равно это остаётся философией, а не 'способом производства'. Которая, кстати, может быть реализована с использованием совершенно различных средств и в очень даже разных областях. И сведение компонентного программирования только к использованию специальных средств и технологий представляется мне не просто искусственным сужением взгляда, а даже и некоторой его неадекватностью. Почему?

Несколько ранее говорилось, что объектно-компонентный способ решения проблем - очень человеческий способ, соответствующий психологии восприятия человека. Но это ещё и очень человеческий способ в сугубо экономическом смысле - удачно спроектированные компоненты имеют высокую степень повторной используемости, т.е. очень существенно экономят труд программиста. Ведь создание программы есть не только 'написание кода', но и выдумывание её внутренней конструкции, отладка, тестирование, создание документации, обучение других людей приёмам её использования. Создание повторноиспользуемой компоненты экономит труд всех упомянутых людей. В том числе и труд программистов, которые используют компоненту - они могут использовать свои знания о ней во многих и многих случаях своей работы. Такая концептуальная ёмкость компонентного похода и заставляет говорить о нем как о прежде всего инженерной философии, а не о технологии или методе.

Поэтому здесь и ниже 'компонентное программирование' понимается как стремление программиста-конструктора углядеть существование компонент всюду, где только возможно. В машиностроении существует строгое определение детали: 'деталь - это изделие, изготовленное из однородного материала без применения сборочных операций'. Аналогичным образом можно определить понятие программной компоненты: программная компонента - это относительно самостоятельная часть программного комплекса, на которые вся конструкция может быть легко разъята, а отдельные части одного и того же назначения могут быть заменены между собой без применения операций повторной сборки модуля. Использование библиотек динамической компоновки в составе проекта - очень характерный пример этого.

Понятие 'компонента', как видно, не тождественно ни понятию 'процедура', ни понятию 'объект'. Она может ими быть, но компоненты есть то, на что готовая конструкция 'может быть разобрана в процессе эксплуатации'. Поэтому библиотечная процедура компонентой не является, компонентой является вся библиотека. Правда, тут надо сделать небольшую оговорку - всё это зависит от того, что считать 'готовой конструкцией', а это уже зависит от того, о каком изделии говорить. Если вы создаёте нечто, поставляемое в исходных текстах, то 'компонентой' может оказаться уже и процедура в составе библиотеки. Важно при этом понимать, что характерное отличие компоненты - свойство лёгкой взаимной заменяемости. Поэтому процедура в составе библиотеки - компонента, а вот класс - нет. И 'библиотека классов' (как пример - Microsoft Foundation Classes) не есть конструкция из компонент.

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