OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 21 Октябрь, 2019 16:33

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




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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3096
Откуда: Астрахань
В связи с исследованиями по семантическому редактору возник вопрос: А можно ли в Компонентном паскале промоделировать интерфейсы, как они сделаны в Яве и Додиезе.
Там они были придуманы, чтобы избавиться от множественного наследования классов. Зато класс может реализовать множество интерфейсов.
Мне пришла в голову мысль, что, может быть, модуль можно использовать в семантике интерфейса?


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

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Валерий Лаптев писал(а):
А можно ли в Компонентном паскале промоделировать интерфейсы, как они сделаны в Яве и Додиезе.
Интерфейс - это абстрактная запись с набором опубликованных методов и скрытой ссылкой на экземпляр объекта.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Валерий Лаптев писал(а):
Мне пришла в голову мысль...
Лучше скажите какую задачу Вам решить надо.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3096
Откуда: Астрахань
Александр Ильин писал(а):
Валерий Лаптев писал(а):
А можно ли в Компонентном паскале промоделировать интерфейсы, как они сделаны в Яве и Додиезе.
Интерфейс - это абстрактная запись с набором опубликованных методов и скрытой ссылкой на экземпляр объекта.

Это понятно. Но в КП нету ж множественного наследования. А интерфейсы в Яве и Додиезе решают проблему множественного наследования.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3096
Откуда: Астрахань
Сергей Губанов писал(а):
Валерий Лаптев писал(а):
Мне пришла в голову мысль...
Лучше скажите какую задачу Вам решить надо.

Как смоделировать множественное наследование?


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Валерий Лаптев писал(а):
Сергей Губанов писал(а):
Лучше скажите какую задачу Вам решить надо.

Как смоделировать множественное наследование?
Это всё?


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

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Валерий Лаптев писал(а):
Александр Ильин писал(а):
Валерий Лаптев писал(а):
А можно ли в Компонентном паскале промоделировать интерфейсы, как они сделаны в Яве и Додиезе.
Интерфейс - это абстрактная запись с набором опубликованных методов и скрытой ссылкой на экземпляр объекта.

Это понятно. Но в КП нету ж множественного наследования. А интерфейсы в Яве и Додиезе решают проблему множественного наследования.
Не понял. В Яве тоже нет множественного наследования, и что?
Вы спросили, как промоделировать. Я вам ответил, как промоделировать. В терминах КП.


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

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Код:
MODULE Interface;

(* Данный модуль содержит общее для системы определение интерфейса Writer.
 Для простоты интерфейс предоставляет единственный метод Write. *)

   TYPE
      Writer* = POINTER TO ABSTRACT RECORD
      END;

   PROCEDURE (w: Writer) Write* (), NEW, ABSTRACT;

END Interface.


MODULE Class;

(* Модуль Class содержит объект Object, поддерживающий интерфейс Interface.Writer. *)

   IMPORT
      Interface;

   TYPE
      Object* = POINTER TO RECORD
         writer-: Interface.Writer;
      END;

      ObjectWriter = POINTER TO RECORD (Interface.Writer)
         this: Object;
      END;

   PROCEDURE (ow: ObjectWriter) Write ();
      (** Реализация интерфейса Interface.Wirter для объекта Class.Object. *)
   BEGIN
      (* TODO: сохранить данные ow.this *)
   END Write;

   PROCEDURE NewObject* (): Object;
      (** Конструктор для типа Object. *)
      VAR
         ow: ObjectWriter;
         res: Object;
   BEGIN
      NEW(ow);
      NEW(res);
      ow.this := res;
      res.writer := ow;
      RETURN res
   END NewObject;

END Class.
Что обычно требуется от интерфейса:
- чтобы можно было включать объект (Object) в список разнородных объектов (не обязательно унаследованных от одного общего предка), по признаку поддержки интерфейса (Writer);
- чтобы при компиляции выдавалась ошибка, если не все методы интерфейса реализованы.

Первое возможно благодаря опубликованному полю writer. Можно создать массив или список объектов типа Interface.Writer, при этом скрытые поля this будут указывать на реальные объекты произвольных типов, с которыми далее можно вести работу через методы интерфейса - например, в цикле вызвать для всех сохранение в файл.
Второе тоже поддерживается, так как КП требует реализации всех абстрактных унаследованных методов при объявлении не-абстрактного наследника.

Отличие от Java также заключается в том, что для каждого экземпляра объекта Object мы вынуждены создавать экземпляры ObjectWriter для всех поддерживаемых интерфейсов. Ведь у нас роль интерфейса берёт на себя отдельный самостоятельный объект. Насколько я знаю, в Java все проверки интерфейсов проводятся во время компиляции, и во время исполнения везде используется ссылка на сам объект Object, без дополнительной нагрузки на динамическую память для создания посредников. Как вариант, вместо поля writer можно использовать методы типа GetWriter(): Interface.Writer, и создавать экземпляры ObjectWriter только когда и если они потребуются.

Ещё интерфейсы используются для маркировки объектов. Заводится пустой интерфейс (без методов и полей) с говорящим названием, например, Serializable, и во время выполнения система ищет объекты, реализующие такой интерфейс, и воспринимает это как знак того, что с объектом нужно сделать что-то особенное (например, сохранить его поля в БД при выгрузке программы). В ББ это тоже можно сделать средствами модуля Meta, при этом, наверное, не нужно даже создавать экземпляр интерфейсного объекта, достаточно объявить поле соответствующего типа.

PS: можно в Вики.
UPD: Вспомнил про абстрактные методы и заменил в определении метода Interface.Writer.Write ключевое слово EMPTY на ABSTRACT.


Последний раз редактировалось Александр Ильин Понедельник, 31 Октябрь, 2011 13:49, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Понедельник, 31 Октябрь, 2011 12:43 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3096
Откуда: Астрахань
0. Спасибо!
1. В Вики - обязательно!
2. Именно это я и предполагал. Получается, моделируем множественность интерфейсов с помощью модулей - на счет раз! Отлично!


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Александр Ильин писал(а):
КП не требует реализации всех пустых унаследованных методов абстрактного класса. Вместо этого получим ошибку времени выполнения при попытке вызова EMPTY-метода (насколько я знаю).
Не так, её тушка-пустышка сгенерится автоматом (синтаксический сахар). Вызывай её сколько хочешь.
Валерий Лаптев писал(а):
Получается, моделируем множественность интерфейсов с помощью модулей
Модули тут не при чём.


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

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 573
Откуда: Россия, Санкт-Петербург
А можно пример для объекта, который наследуется от другого объекта и реализует три интерфейса?
Типа:
Код:
class MyData extends SomeData implements Observable, Drawable, Serializable {
...
}

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


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4520
Откуда: Россия, Орёл
Александр Ильин писал(а):
Второе не поддерживается, так как КП не требует реализации всех пустых унаследованных методов абстрактного класса. Вместо этого получим ошибку времени выполнения при попытке вызова EMPTY-метода (насколько я знаю).
Language Report писал(а):
10.2 Methods
...
Abstract methods are never called... Calling an empty method has no effect.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Madzi писал(а):
Вся идея интерфейсов в том, что это контракт объекта с системой на обязательную реализацию определённых методов, и система проверяет этот контракт на этапе компиляции.
Вот пожалуйста:
Код:
TYPE
  ObserDrawSeri = POINTER TO ABSTRACT RECORD
    PROCEDURE (x: ObserDrawSeri) as_Observable(): Observable, NEW, ABSTRACT;
    PROCEDURE (x: ObserDrawSeri) as_Drawable(): Drawable, NEW, ABSTRACT;
    PROCEDURE (x: ObserDrawSeri) as_Serializable(): Serializable, NEW, ABSTRACT;
  END;

  MyData = POINTER TO RECORD (ObserDrawSeri)
    ...
  END


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

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Madzi писал(а):
Вся идея интерфейсов в том, что это контракт объекта с системой на обязательную реализацию определённых методов, и система проверяет этот контракт на этапе компиляции. В вашем случае - контракт не проверяется, а нарушается по факту (т.е. контракта нет). Т.е. это не совсем интерфейс в идеологическом смысле. Контракты вещь архиполезная, особенно для доказательного программирования.
Если мы ведём речь о том, что EMPTY-методы не отсигналятся как нереализованные на этапе компиляции, то в моём случае скорее есть пустая реализация интерфейса. Хорошо это или плохо - вопрос отельный и зависит от потребностей системы и смысла самого интерфейса. Факт, однако, заключается в том, что в Яве и других языках тоже можно сделать пустую реализацию, успешно пройти компиляцию и, в результате, не соблюдать контракт. В полном смысле проверить соблюдение контракта не возможно. Единственное отличие моего примера от поведения Явы - отсутствие сообщения компилятора "не реализован метод <MethodName>".

В этом месте я прошу прощения. Я забыл, что процедуры в КП тоже можно пометить как ABSTRACT, и тогда компилятор всё-таки требует их реализации, поимённо, как только мы объявляем унаследованную не-ABSTRACT запись. Поправил исходное сообщение.
Madzi писал(а):
А можно пример для объекта, который наследуется от другого объекта и реализует три интерфейса?
Типа:
Код:
class MyData extends SomeData implements Observable, Drawable, Serializable {
...
}
Конечно:
Код:
TYPE MyData = POINTER TO RECORD (SomeData)
   PROCEDURE AsObservable* (): Observable.Interface;
   PROCEDURE AsDrawable* (): Drawable.Interface;
   PROCEDURE AsSerializable* (): Serializable.Interface;
   ...
END;


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Да, композиция позволяет что угодно.
Если какая-то система выступает в двух ролях, то значит, в ней есть подсистемы, ответственные за эти роли. Делим на части.

Вообще, наличие у класса больше 6-7 методов (не считая банальных Get-Set) позволительно только для классов очень широкого применения. А уж больше 10 (как правило) - признак нездорового проектирования. Когда недоделана декомпозиция.


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

Зарегистрирован: Воскресенье, 03 Февраль, 2008 12:50
Сообщения: 245
Подробности озвученного подхода от, так сказать, отцов-основателей тут. :wink:


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3096
Откуда: Астрахань
Илья Ермаков писал(а):
Да, композиция позволяет что угодно.
Если какая-то система выступает в двух ролях, то значит, в ней есть подсистемы, ответственные за эти роли. Делим на части.

Вообще, наличие у класса больше 6-7 методов (не считая банальных Get-Set) позволительно только для классов очень широкого применения. А уж больше 10 (как правило) - признак нездорового проектирования. Когда недоделана декомпозиция.

1. При использовании композиции вместо наследования не выполняется принцип подстановки.
2. Когда "стряпается" новый тип данных, то операций бывает довольно много. Вон деньги: почти все операции, кроме умножения.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3096
Откуда: Астрахань
kemiisto писал(а):
Подробности озвученного подхода от, так сказать, отцов-основателей тут. :wink:

Спасибо! Почитаем.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8185
Откуда: Троицк, Москва
Валерий Лаптев писал(а):
Илья Ермаков писал(а):
Да, композиция позволяет что угодно. ...
1. При использовании композиции вместо наследования не выполняется принцип подстановки.
Надо различать
-- наследование интерфейса (что подразумевает И.Е.), где с принципом подстановки всё в порядке;
-- наследование реализации -- именно вместо него композиция.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Валерий Лаптев писал(а):
не выполняется принцип подстановки
Подставляйте y.as_X() в процедуру требующую X.

Объявление: PROCEDURE F(x: X);

Вызов: F(y.as_X())

Здесь y: Y и
Код:
TYPE
  Y = POINTER TO RECORD
    PROCEDURE (y: Y) as_X (): X, NEW;
  END


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

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


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

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


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

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