OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 26 Март, 2019 17:37

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 101 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Вторник, 01 Ноябрь, 2011 18:36 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2560
Откуда: Россия, Ярославль
на примере простого графического движка "с механикой".
моя реализация требовала объект, который бы поддерживал два разнородных контракта - рисование и движение.

в яве я делал так
в той части, что отвечает за отрисовку сцены описывал
Код:
interface Drawable {
   public abstract void draw();
}


в той части, что отвечает за механику объектов
Код:
interface Movable {
   public abstract void moveTo(int dx, int dy)
}


затем, в части, которая предоставляла собой "движок"
Код:
public class Frame implements Drawable, Movable {
   // здесь реализуем draw и moveTo
}


прикладная же часть состояла из реализаций
Код:
public abstract class View{
   public abstract void paint (Frame f);
}



Но теперь я понял, что всё это фигня. Так как у меня в ББ не было возможности реализовать такое решение, я выбрал другое
Код:
Object* = POINTER TO ABSTRACT RECORD END

PROCEDURE (o: Object) HandleMsg(m: Msg), NEW, ABSTRACT;


Если бы Meta в ББ могла вызывать методы - было бы совсем просто. Но, так как она не умеет методы, пришлось сделать так:
Реализация Manager будет заниматься рассылкой объектов-сообщений зарегистрированным в своём внутреннем списке, объектам.
Код:
Msg* = POINTER TO ABSTRACT RECORD;

Manager* = POINTER TO ABSTRACT RECORD END;

Link* = POINTER TO ABSTRACT RECORD;

PROCEDURE (m: Manager) Register(link: Link), NEW, ABSTRACT;

PROCEDURE (l: Link) Handle(m: Msg), NEW, ABSTRACT;


и в реализации прикладной логики делаю так:
Код:
MyFrame* = POINTER TO RECORD(Object) END;

PROCEDURE (o: MyFrame) HandleMsg(m: Msg);
BEGIN
   WITH m: MyEngine.MoveToMsg DO
   
   |m: MyEngine.DrawMsg DO

   ELSE END;
END HandleMsg;

MyLink* = POINTER TO RECORD (Link) (* решаем задачу неполноты Meta *)
   o: MyFrame
END;

PROCEDURE (m: MyLink) Handle (m: Msg);
BEGIN
   m.o.HandleMsg(m);
END Handle


Если уж совсем конкретно, то при использовании шины AbfBus и широковещания не нужен даже тип Link, его роль играет модуль.
но тогда придётся всюду таскать за собой идентификатор объекта, подлежащего обработке. Конкретно этим подходом пользуюсь в своей повседневной деятельности. Недавно предпринял попытку расширить схему до вышеизложенной (где хэндлер уже у объекта), вроде пока работает.

Вообщем-то, физический смысл "тело, которое видно и которое двигается" одинаково передают оба подхода.
Задача решена, множественные интерфейсы не нужны.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Вторник, 01 Ноябрь, 2011 23:18 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 572
Откуда: Россия, Санкт-Петербург
Ну фактически вы множественный интерфейс заменили единственным Observer/Obervable.
Интерфейсы нужны в части большей читаемости кода. Когда мы не плодим десяток объектов с объединением, а можем сделать всё в одном объекте, но по контрактам.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Вторник, 01 Ноябрь, 2011 23:30 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2560
Откуда: Россия, Ярославль
Суть в построении интерфейса на типах-сообщениях. "Забыли" про методы/поля, работаем с объектами-сообщениями. Основная мысль в этом.
Обсервер этого не учитывает/не предусматривает (в каноничной форме).
Да и какой он обсервер... он скорее environment, среда для взаимодействия слабосвязанных объектов...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Четверг, 03 Ноябрь, 2011 10:28 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1173
Вариант в духе классического Оберона.
Код:
TYPE
Interface = RECORD END;

IDrawable = RECORD(Interface) 
  draw: PROCEDURE(o:Object);
END;

IMovable = RECORD(Interface) 
  moveTo: PROCEDURE(o:Object;dx,dy:INTEGER);
END

MyObject = RECORD(Object) 
   idraw:IDrawable;
   imove:IMovable;
   ...
END

PROCEDURE DoDraw(o:Object; idraw:IDrawable);
PROCEDURE DoMove(o:Object; imove:IMovable);

  DoDraw(o, o.idraw);
  DoMove(o, o.imove);


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Четверг, 03 Ноябрь, 2011 10:59 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Как всегда, есть случаи, когда декомпозиция на части будет как раз лучшим дизайном (а попытка наследовать множественные интерфейсы - недопроектированием), и случаи, когда она уже будет "эмуляцией", а более естественным было бы второе.

Некоторые считают, что при таких раскладах средство нужно включать в язык.
Однако "естественные" случаи для подобных средств далеко не так часты. Стоит ли на это ориентироваться?
А если средство включить, то получается "эффект заполнения степеней свободы языка" (упоминаемый часто Info21). Будут использовать дело не по делу во всех случаях, где только есть на это намёк. Так создаётся потом иллюзия, что средство "ну очень важное".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Четверг, 03 Ноябрь, 2011 12:48 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 572
Откуда: Россия, Санкт-Петербург
Язык и так избыточен. Например, можно убрать RETURN, и тем самым решить проблему выхода из середины процедуры:
Оформлять код таким образом:
Код:
PROCEDURE Sqr(x : LONGINT) : LONGINT;
END Sqr : x * x;

Т.е. процедура возвращает выражение после END ident : <expr> ;
В простых процедурах не потребуется даже писать BEGIN.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Четверг, 03 Ноябрь, 2011 14:10 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2292
Откуда: Россия, Санкт-Петербург
Madzi писал(а):
Язык и так избыточен. Например, можно убрать RETURN, и тем самым решить проблему выхода из середины процедуры:
Оформлять код таким образом:
Код:
PROCEDURE Sqr(x : LONGINT) : LONGINT;
END Sqr : x * x;

Т.е. процедура возвращает выражение после END ident : <expr> ;
В простых процедурах не потребуется даже писать BEGIN.
Тогда уж ":=", а не ":".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Четверг, 03 Ноябрь, 2011 14:13 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Подскажите, ICloneable можно реализовать через декомпозицию?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Четверг, 03 Ноябрь, 2011 14:38 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2560
Откуда: Россия, Ярославль
а зачем?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Четверг, 03 Ноябрь, 2011 14:58 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4488
Откуда: Россия, Орёл
Madzi писал(а):
Язык и так избыточен. Например, можно убрать RETURN, и тем самым решить проблему выхода из середины процедуры
В Оберон-07 проблема решена именно так. И, по-моему, выглядит лучше.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Четверг, 03 Ноябрь, 2011 16:39 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8000
Откуда: Троицк, Москва
Илья Ермаков писал(а):
"эффект заполнения степеней свободы языка" (упоминаемый часто Info21).
"насыщения".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Четверг, 03 Ноябрь, 2011 23:17 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 572
Откуда: Россия, Санкт-Петербург
Евгений Темиргалеев писал(а):
Madzi писал(а):
Язык и так избыточен. Например, можно убрать RETURN, и тем самым решить проблему выхода из середины процедуры
В Оберон-07 проблема решена именно так. И, по-моему, выглядит лучше.

Что-то я пропустил, когда это из Оберона-07 убрали ключевое слово RETURN ?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Пятница, 04 Ноябрь, 2011 09:55 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Madzi писал(а):
Язык и так избыточен. Например, можно убрать RETURN, и тем самым решить проблему выхода из середины процедуры:


В Оберон-07 RETURN связан с концом процедуры.

А лексическая избыточность - это вообще другая тема. Проблем она создать не способна (сложность ей не порождается).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Пятница, 04 Ноябрь, 2011 09:56 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Александр Шостак писал(а):
Подскажите, ICloneable можно реализовать через декомпозицию?


Через HandleMsg.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Пятница, 04 Ноябрь, 2011 11:18 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2560
Откуда: Россия, Ярославль
Тут подсказывают, что решение с сообщениями затрудняет понимание, сопровождение, и не проверяется компилятором.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Пятница, 04 Ноябрь, 2011 11:43 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Скажите это смоллтокерам или питонистам :)

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Пятница, 04 Ноябрь, 2011 14:10 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2560
Откуда: Россия, Ярославль
Trurl писал(а):
Вариант в духе классического Оберона.

и ещё в примере использования ББ-подсистемы COM - ComAggregate примерно то же самое и описано (если я не ошибаюсь, конечно).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Воскресенье, 06 Ноябрь, 2011 17:37 

Зарегистрирован: Среда, 04 Июль, 2007 16:43
Сообщения: 233
Если интересует "точка зрения ETH" на проблему интерфейсов, множественного наследования, композиции и т.п., то, может быть, имеет смысл изучить Зоннон: http://www.zonnon.ethz.ch/archive/znnLanguageReportv04y090606draft.pdf, раздел 11.2.1.


Последний раз редактировалось QWERTYProgrammer Воскресенье, 06 Ноябрь, 2011 18:26, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Воскресенье, 06 Ноябрь, 2011 17:54 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Что такое "точка зрения ETH"? и как она (даже если примем такую формулировку) связана с точкой зрения Евгения Зуева, который теперь уже давно работает в другом месте?

Зуев сделал свой эксперимент - некое развитие средств Оберонов и Ады. Под .NET, под финансирование Microsoft (те хотели в пару к C# какой-то оригинальный язык паскалеподобный, видимо). В такой форме, чтобы MS оценила - чтобы оригинально и достаточно обильно. Кстати, заинтересовалась - спецификации протоколов они стали применять в Синулярности и ядре 7-ки уже после работ Зуева.

Зоннон любопытен некоторыми вещами, но никакой фундаментальности в нём нет. Модульность там плохая.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Воскресенье, 06 Ноябрь, 2011 18:27 

Зарегистрирован: Среда, 04 Июль, 2007 16:43
Сообщения: 233
ОК, взял точку зрения в кавычки:-)


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 101 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB