Когда в программировании идёт речь о компонентной архитектуре, разработчики обычно начинают представлять себе какие-то сложные технологии, наподобие COM, EJB, SOA, CORBA и соответствующие громоздкие решения. Действительно, если посмотреть на статью в Википедии, "Component-based software engineering", то становится понятно, откуда берутся подобные представления.
Особо вредной является ситуация, когда менеджер проекта, поверив в эффективность какой либо из компонентных технологий, например EJB, начинает её внедрять повсеместно, ожидая положительного результата. В итоге сложность разрабатываемой системы возрастает, а прогресс разработки замедляется.
Поэтому, идея компонентно-ориентированного программирования обычно воспринимается разработчиками без особого энтузиазма.
На самом деле, подавляющее большинство вопросов контроля сложности, весьма эффективно решается применением компонентно-ориентированного программирования в его простейшем виде.
Начнём с определения компонента:
Компонент – это объектная конструкция, представляющая собой черный ящик, реализующий заданный интерфейс при помощи классов, находящихся в этом черном ящике.
Важные моменты:
Если внутренности компонента не инкапсулированы или компонент имеет слишком сложный интерфейс, то применение подобных "компонентов" не даёт никаких преимуществ. Это даже не компоненты, поскольку не соблюдены два главных правила компонента – простой интерфейс, скрытая реализация.
В идеальном случае, программист-клиент компонента, вообще не должен знать о том, что он имеет дело с компонентом! Он должен думать, что это просто класс из библиотеки. Вот почему в удачных фреймворках, таких как Qt вы не найдёте компонентов. Они там есть, но этот факт полностью скрыт от пользователя Qt. И не потому что, разработчики Qt не хотят, чтобы пользователь знал об устройстве Qt, а потому, что разработчики Qt хотят оградить пользователя от ненужной сложности, позволив ему тем самым сконцентрироваться на решении своих задач. Мы (пользователи) просто создаём новый класс QMainWindow и манипулируем им как обычным объектом, не задумываясь о том, что это на самом деле компонент, имеющий отдельную, весьма нетривиальную реализацию для каждой платформы.