Илья Ермаков писал(а):
[01:14:11] <wlad_los@jabber.ru> Мы же "отсоединяем" функции - ЧТО остаётся? :о)
[01:14:39] <wlad_los@jabber.ru> отсоединяем-от объектов
Отсоединив экспортируемые функции/методы от класса/типа получим просто класс/тип глобальной переменной..
Объект получившегося класса/типа м.б. использован для хранения состояния.
НО!, должны ли остаться методы для обращения к полям класса. Ведь эти методы обязаны быть экспортируемыми?..
Илья Ермаков писал(а):
[01:19:49] <wlad_los@jabber.ru> Но что такое РОЛЬ?Это - НЕ "набор" функций! "Играть роль" - это ДЕЙСТВИЕ, последовательность прохождения состояний в ответ на внешние события.
А "РОЛЬ", по всей видимости - описание последовательности прохождения состояний
в ответ на внешние события
) Это будет справедливо в терминах функциональной схемы проектируемой
системы.
Думается, что для начала, РОЛЬ надо бы определить относительно языка программирования.
Причем, вне зависимости от класса/типа:
Илья Ермаков писал(а):
http://forum.oberoncore.ru/viewtopic.php?f=6&t=692&start=0"RECORD "пролезают" в архитектуру - и служат уже далеко не "для представления данных".
Функции свои они прекрасно выполняют, но некоторая смысловая путаница таки возникает
(хотя намнооого меньшая, чем в языках, эмулирующих понятие модуля через классы).
Когда запись является типом данных, когда - интерфейсом, когда - реализацией интерфейса...
Да ещё приходится налагать устные запреты на "смешивание" этих
Р_О_Л_Е_Й - например,
на наследование реализации (потому что это ведёт к ломке компонентной идеологии и всякого
рода тонким проблемам).
Поэтому РОЛЬ претендует на статус надклассовый. Метакласс, хотя бы.
К слову:
S.Yu.Gubanov писал(а):
http://www.progz.ru/forum/lofiversion/index.php/t189-200.htmlКод:
var
q: Queue of double;
l: List of string;
t: BinaryTree of byte;
am: Map of string to double;
Тогда уж и
Код:
IQueue = ABSTRACT INTERFACE OF Queue; (* описание интерфейса *)
IQueueImpl = INTERFACE OF Queue; (* его реализация *)
имеют право появиться.
В виде тех самых ролей.
Вход
FAQ
Поиск
