Коллеги, я почитал ваши мнения (Vlad2, IT, old->*Plutonia_Experiment() ), добавил своих измышлизмов и кое-чего, почерпнутого из сайтов. Теперь попробую обоснованно вывести определения (В конце постинга). Если оппоненты согласны, то дальше будем дискутировать, опираясь на эти определения. Если нет, то попрошу аргументированно оспорить предложенные определения и предложить свои формулировки.

Компонентное программирование

VD> Компонентного программирования — программирование основанное на компонентах, т.е. сборка ПО из готовых блоков. Нечто вроде сборки компьютеров из комплектующих, но для ПО.
IT> Компонентом можно упрощённо считать набор связанных классов, реализованных как функционально законченный модуль.
OE> Это уже другие компоненты.
OE> Функционально законченный — это необходимо, но еще недостаточно.
VD> В компонентах главное, что это отчуждаемые модули. Т.е. они должны быть самодостаточны и не требовать наличия исходного кода для своего использования.

OK, так или иначе, но определение компонента есть. ИМХО, не сказали только, что компонент без компонентной инфраструктуры – суть ноль без палочки.

Попробую пояснить свою мысль и сделать кое-какие выводы.

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

Инфраструктура может, например, обеспечить скрытие деталей реализации обмена информацией между компонентами (в частности — межпроцессного и межмашинного обмена), предложив свои соглашения, которыми будут пользоваться разработчики модулей. (Аналогия с "железом" — прозрачна. Предлагается, скажем, разъём и параметры напряжения на отдельных штырьках, а откуда эти напряжения берутся — дело разработчиков, например, блоков питания). Также, инфраструктура может обеспечить относительно прозрачный интерфейс для модулей, написанных на разных языках программирования (как в компьютер вставляются блоки от разных производителей), эмулировав тем самым их бинарную совместимость. Возможны и другие функции инфраструктуры.

Модуль, который реализует требования, накладываемые инфраструктурой (а они неизбежно есть), называется компонентом, а сама инфраструктура — компонентной инфраструктурой.

Компонент, удовлетворяющий требованиям инфраструктуры, тем не менее может предъявлять определённые требования к другим компонентам, с которыми он взаимодействует. (Как это справедливо заметил old->*Plutonia_Experiment() )

Другой аспект — отчуждаемость компонента, т.е., компонент, в принципе, может быть помещён в любое окружение, отвечающее спецификации компонентной инфраструктуры. (Приблизительный “железячный”аналог – установка платы на исптытательный стенд).

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

Теперь о компонентно-ориентированном программировании (собственно, о нём, первоначально речь и была).

В сухом остатке, получается, что компонентно-ориентированное программирование – это, прежде всего, подход, ориентированный на использование разных языков программирования, но ограниченный при этом одной-единственной компонентной инфраструктурой. Подход, в основном, упирает на независмый deployment компонентов.

Атрибутное (декларативное) программирование

VD> Атрибутное (декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов. В Шарпе это выглядит так:


VD>

VD>[MyAtrybut(MyValue)]
VD>void MyMethod(){}
VD>

VD> Вообще атрибуты — это методанные которые могут анализироваться неким кодом (от компилятора, до утилит регисрации) и на базе них можно принимать те или иные решиния.

OK. Значит, атрибуты – суть данные, которые могут анализироваться какими-то внешними средствами, будь то компилятор, утилиты регистрации, браузеры (вероятно) всех мастей и т.п. Атрибуты, вероятно, характеризуются именем, и типом значения. Кстати, о декларативном программировании – декларативное программирование подразумевает наличие какой-то системы, интерпретирующей декларации. SQL, Prolog – это тоже декларативные языки, подразумевающие наличие системы, обрабатывающей декларации.

Так что, важнейшая деталь, ИМХО, это система интерпретации семантики атрибутов. Внешние средства обязаны располагать информацией о семантике атрибутов, чтобы адекватно их использовать. Иначе, атрибуты – ноль без палочки, как и компоненты. Поэтому в определении я убрал слово "декларативное", оставив только "атрибутное".

Итак, сухой остаток – атрибутное программирование, суть программирование в терминах какой-либо инфраструктуры, которая располагает информацией об использовании атрибутов.

Аспектно-ориентированное программирование

IT> Этот термин ещё толком не сформулировался. Основная идея заключается в отделении мух от котлет. Если алгоритм занимается вычислением логарифма, то ему желательно ничего не знать о транзакциях, модели синхронизации и/или обработки исключений. К тому же эти операции как правило повторяются от раза к разу в различных алгоритмах. Аспектный подход позволяет отделить подобные служебные функции и выделить их в отдельный класс задач. Одним из способов реализации AOP являются атрибуты. К тому же в .NET существует механизм создания классов, все публичные методы которых будут перехватываться специальными обработчиками, которые могут выполнять определённые служебные функции.

OK. На мой взгляд, твоё определение достаточно ясно выделяет главное – “подход”. Я покопался на aosd.net и пришёл к тому, что аспектное программирование (если точнее – то software design) можно в каком-то смысле назвать «гиперкомпонентным» программированием.

Вот ещё, интересный, на мой взгляд, фрагмент введения к документу "Declarative aspect-oriented programming", взятый с сайта:

Aspect-oriented programming addresses the problem that the implementation of some properties such as error handling and optimization tends to cross-cut the basic functionality. To overcome that problem special languages are used to specify such properties---the so-called aspects---in isolation. The software application is obtained by weaving the aspect code and the implementation of properties corresponding to basic functionality---the so-called components. This paper investigates the suitability of functional meta-programs to specify aspects and to perform weaving. The proposal focuses on the declarative paradigm (logic programming, attribute grammars, natural semantics, constructive algebraic specification etc.) as far as components are concerned, whereas aspects are represented by program transformations. Weaving is regarded as a program composition returning a combination of the components satisfying all the aspects. The computational behaviour of the components is preserved during weaving. The proposal improves reusability of declarative programs. The approach is generic in the sense that it is applicable to several representatives of the declarative paradigm. Several roles of aspect code are defined and analysed.

AOP нацелено на проблему реализации таких свойств как обработка ошибок и оптимизация, пронизывающих основную функциональность [программы]. Для решения этой проблемы используются специальные языки, независимо определяющие эти свойства (так называемые — аспекты). Прикладная программа обрабатывается «сшиванием» [weaving] аспектного кода и реализаций указанных свойств в соответствии с базовой функциональностью (т.н. — компоненты). Настоящий документ исследует пригодность функционального метапрограммирования для специфицирования аспектов и выполнения «сшивания». Предложение фокусируется на декларативной парадигме (логическое программирование, атрибутные грамматики, естественные семантики, конструктивные алгебраические спецификации и т.п.) и компонентах, тогда как аспекты представлены трансформацией программы. «Сшивание» представляется композицией, являющейся комбинацией компонентов, удовлетворяющих всем аспектам. Вычислительное поведение компонента после «сшивания» сохраняется неизменным. Предложение повышает степень повторного использования декларативных программ. Подход, по сути является обобщённым, поскольку применим к разным представлениям [representatives] декларативной парадигмы. Определён и проанализирован ряд ролевых функций аспектного кода.

Значит, таким образом, цепочка замыкается – от AOP (цель) к атрибутам и компонентам(средство).

*****************************************************************
Итак, попробую дать определения для различных «программирований».
*****************************************************************

Компонентно-ориентированное программирование.

Подход к разработке, ориентированный на использование разных языков программирования, в рамках какой-либо компонентной инфраструктуры. Подход, в основном, нацелен на реализацию независмого распространения компонентов.
Примеры инфраструктур: COM, Corba Component Model (CCM), Любые plug-ins – тоже, в сущности, компоненты.

Атрибутное программирование.

Атрибутное программирование – описание свойств в терминах какой-либо инфраструктуры (атрибутах), располагающей информацией об использовании атрибутов.

Аспектно-ориентированное программирование.

Совокупность подходов и средств, предусматривающих независимую реализовацию различной, например — прикладной и инфраструктурной [часто встречающийся термин "cross-cutting" я перевёл как «пронизывающей»] функциональности системы. Такие реализации называются аспектами. Подразумевает наличие средства, компонующего [weaving] аспекты в единое целое. Наличие такого средства требует, чтобы аспекты были снабжены определёнными декларациями, на основе которых выполняется компоновка.

Ну вот так или примерно так. Теперь жду ваших мнений.