OberonCore
https://forum.oberoncore.ru/

Смысл ООП
https://forum.oberoncore.ru/viewtopic.php?f=8&t=3925
Страница 3 из 4

Автор:  Info21 [ Четверг, 17 Май, 2012 14:36 ]
Заголовок сообщения:  Re: Смысл ООП

Про упор на композицию было понято еще в 1997 г., когда появился Компонентный Паскаль как новый диалект.
Одновременно с книжкой Клеменса Шиперского.

Наследование нужно применять там и только там, где непременно нужно расслоить функциональность записи между модулями.

Автор:  Валерий Лаптев [ Четверг, 17 Май, 2012 17:14 ]
Заголовок сообщения:  Re: Смысл ООП

Насчет композиции - согласен. Композицию нужно применять везде, где не требуется наследование.
А наследование требуется там, где требуется динамизация типа и вызов процедур по динамическому типу.

Автор:  Сергей Прохоренко [ Четверг, 17 Май, 2012 17:16 ]
Заголовок сообщения:  Re: Смысл ООП

А что Вы называете упором на композицию?

Автор:  Info21 [ Четверг, 17 Май, 2012 18:10 ]
Заголовок сообщения:  Re: Смысл ООП

Сергей Прохоренко писал(а):
А что Вы называете упором на композицию?
Народ он как. Сказали -- наследование, и сразу огроменные деревья наследования, куда всё запихнуто. Наследование ради наследования.

А надо с тонким пониманием :)

Автор:  Валерий Лаптев [ Пятница, 18 Май, 2012 11:44 ]
Заголовок сообщения:  Re: Смысл ООП

Сергей Прохоренко писал(а):
А что Вы называете упором на композицию?

Композиция - ЕСТЕСТВЕЕННЫЙ метод реализации многофункциональности в одном классе.
Без всяких дополнительных фич, типа наследования.
ИМХО, множественное наследование скорее вредно, чем полезно.
Одиночное наследование + композиция - это хороший вариант.

Автор:  Владислав Жаринов [ Пятница, 18 Май, 2012 11:44 ]
Заголовок сообщения:  Re: Смысл ООП

Из объяснений Сергея всё больше впечатление, что он предлагает сборочно-конкретизирующий синтез реально. А не ООП - хотя определение элементов и схем их сборки может базироваться на объектно-ориентированном анализе.
Как мне кажется, важно, чтобы метод анализа-синтеза обеспечивал это:
Валерий Лаптев в viewtopic.php?p=72052#p72052 писал(а):
...
3. Что хорошо: пацаны получают реальный опыт большой разработки. Я там у них с одной стороны - главный идеолог, с другой - программист-юниор... :)
Причем в процессе разработки начинают понимать на практике, что такое хорошая архитектура, а какая - не очень. Сейчас уже у них в башке сидит главный принцип: система должна быть закрыта для модификаций и открыта для расширений. В уже реализованные вещи практически не залезаем, а только дополняем новыми функциями.
...
И вот хорошо бы выйти на то, как анализировать с соблюдением этого.

Автор:  Владислав Жаринов [ Пятница, 18 Май, 2012 11:47 ]
Заголовок сообщения:  Re: Смысл ООП

Валерий Лаптев писал(а):
Композиция - ЕСТЕСТВЕЕННЫЙ метод реализации многофункциональности в одном классе.
...
Одиночное наследование + композиция - это хороший вариант.
Т.е. композиция здесь понимается не в смысле структурности - конкатенации структур с одним входом и одним выходом (ну или как в математике - цепочки функций)?.. Или как?

Автор:  Валерий Лаптев [ Пятница, 18 Май, 2012 11:48 ]
Заголовок сообщения:  Re: Смысл ООП

То, что предлагает Сергей - это просто накопление в среде реализованных компонент.
Только еще среда должна вести полный учет того, что накоплено.
Кстати, пока ни в одной среде я этого не видал... :)

Автор:  Валерий Лаптев [ Пятница, 18 Май, 2012 11:50 ]
Заголовок сообщения:  Re: Смысл ООП

Владислав Жаринов писал(а):
Валерий Лаптев писал(а):
Композиция - ЕСТЕСТВЕЕННЫЙ метод реализации многофункциональности в одном классе.
...
Одиночное наследование + композиция - это хороший вариант.
Т.е. композиция здесь понимается не в смысле структурности - конкатенации структур с одним входом и одним выходом (ну или как в математике - цепочки функций)?.. Или как?

Композиция - это прямо в лоб: объект уже реализованного класса включается как поле в новом классе. Тем самым новый класс получает всю функциональность реализованного класса. Только не по наследству, а через объект реализованного класса.

Автор:  Владислав Жаринов [ Пятница, 18 Май, 2012 11:53 ]
Заголовок сообщения:  Re: Смысл ООП

Вообще это странно... :) Т.е. нигде невозможно, скажем, вывести что-то типа каталога графит-областей, какие есть в базе?.. Когда я предлагал это - думал, что уже было как-то реализовано...

Автор:  Валерий Лаптев [ Пятница, 18 Май, 2012 14:36 ]
Заголовок сообщения:  Re: Смысл ООП

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

Автор:  Сергей Прохоренко [ Суббота, 19 Май, 2012 10:23 ]
Заголовок сообщения:  Re: Смысл ООП

Валерий Лаптев писал(а):
То, что предлагает Сергей - это просто накопление в среде реализованных компонент.

Плюс раннее связывание, благодаря которому устраняется проблема совместимости версий фреймворков.
Плюс визуализация - табличная форма представления.

Автор:  Владислав Жаринов [ Суббота, 19 Май, 2012 10:26 ]
Заголовок сообщения:  Re: Смысл ООП

Валерий Лаптев писал(а):
Владислав Жаринов писал(а):
Вообще это странно... :) Т.е. нигде невозможно, скажем, вывести что-то типа каталога графит-областей, какие есть в базе?.. Когда я предлагал это - думал, что уже было как-то реализовано...
Если я правильно понимаю, то вы говорите о метаинформации. Это реализуется посредством рефлексии, то есть получения на этапе выполнения некоей информации о живущих объектах. В том числе и об их типе.
Не, я о "времени сочинения". :) Т.е. какие вещи, определяемые в среде как "сборочные единицы", доступны для использования в проектах.

Автор:  Владислав Жаринов [ Суббота, 19 Май, 2012 15:29 ]
Заголовок сообщения:  Re: Смысл ООП

Исходя из конструктивной идеи этой ветки:
Info21 в viewtopic.php?p=72009#p72009 писал(а):
... нет уголка с табличкой, куда ткнуть любого желающего. (Или я уже забыл?)
...
- возникают некоторые вопросы. Как-то:

1. Эта формулировка:
Info21 в viewtopic.php?p=72601#p72601 писал(а):
В обсуждении WITH созрело некое, вроде бы, подтверждение (моего любимого) тезиса, что интерпретация ООП в Оберонах выявляет фундаментальный смысл ООП как способа расслоения функциональности между модулями в настоящей модульной системе.

Когда управление списком -- в одном модуле, а наполнение элементов списка конкретным смыслом -- в других.
...
- означает ли, что ООП используется в ситуациях, как задача "Гетерогенная очередь" у Свердлова? И что должно использоваться всегда именно так? Или можно сформулировать "строчки для таблички" вида: "если анализ даёт такую-то структуру сущностей задачи - используй расслоение такое-то (как у Свердлова)"; "если этакую - используй расслоение эдакое (скажем, с каким-то множественным наследованием - или его эмуляцией через одиночное)". Причём способы эмуляции д.б. рассмотрены где-то рядом с табличкой...
И также - как она соотносится с этим:
Сергей Прохоренко в viewtopic.php?p=72597#p72597 писал(а):
...
Например, возможен такой вариант. В каждом модуле должна быть создана сводная для всех классов интерактивная таблица виртуальных методов, в которой программист непосредственно и в явном виде указывает связи между классами и методами. При внесении изменений в эту таблицу происходит автоматический рефакторинг всего кода модуля, при котором имена абстрактных методов заменяются на имена реализаций методов. Необходимость в позднем связывании отпадает.
- противоречит? альтернативно?

2. Альтернативная организация, как сформулирована здесь:
Валерий Лаптев в viewtopic.php?p=72716#p72716 писал(а):
Владислав Жаринов писал(а):
Валерий Лаптев писал(а):
Композиция - ЕСТЕСТВЕЕННЫЙ метод реализации многофункциональности в одном классе.
...
Одиночное наследование + композиция - это хороший вариант.
Т.е. композиция здесь понимается не в смысле структурности - конкатенации структур с одним входом и одним выходом (ну или как в математике - цепочки функций)?.. Или как?

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

3. Инициирующий пост ветки вроде бы располагает поставить и такой вопрос - не дать ли также закономерности отображения ООП-1 на ООП-0 ("фантазийных схем" в базис реализации). Но тут возможен ещё путь, коего уже коснулся: viewtopic.php?p=72010#p72010.
Теперь уточню. Не нужно ли на математической стадии формализации задачи уже заботиться об ограничении фантазий? Т.е. чтобы уже спецификация, как правило, соответствовала ООП-0?
    О такой возможности задумывался в связи с "графитизацией" Оберонов "как положеноо" (в "базисе трёх абстракций" Кауфмана - ну или четырёх по Вирту-Бадду). Т.е. с выделением структур всех компонент базиса - а не только потока управления с "притыканием" остальных к нему. И окончательно это оформилось после знакомства в "АиСД-Оберон" с мыслями Вирта о соответствии сущностей структур данных и управления.
А отсюда такая мысль появилась. В теории структур данных, как известно, определены закономерности нормализации. Не значит ли такое соответствие, что пора искать аналогичные закономерности и для структур управления?.. И не это ли д.б. приоритетным предметом здесь:
Евгений Темиргалеев в viewtopic.php?p=72041#p72041 писал(а):
Валерий Лаптев писал(а):
Налицо необходимость конкретного исследования.
Хорошо бы фундаментального, лет на 20-30. И чтобы исследователь попался не просто теоретик, но и практик...

viewtopic.php?p=71865#p71865
...
Возмоожно, природа сама подскажет нам, как получать естественное для конкретного аналитического выражения задачи отображение на уровень реализации (с непременным учётом "абстракции исполнения" - в форме хоть "связывания" у Кауфмана, хоть "систематического представления об архитектуре" у Вирта) - вместо того, чтобы пытаться обманывать природу исполнителя?.. :wink:

Автор:  Сергей Прохоренко [ Суббота, 19 Май, 2012 18:53 ]
Заголовок сообщения:  Re: Смысл ООП

Нашел ссылку, разъясняющую, что такое композиция в ООП.

Автор:  Владислав Жаринов [ Воскресенье, 20 Май, 2012 12:36 ]
Заголовок сообщения:  Re: Смысл ООП

Возможно, Ваши мысли также иллюстрируют делегирование и обобщённое программирование?..
В любом случае есть вопрос с оптимальным представлением создаваемых структур. Его ставил (в несколько иной плоскости - от исполнения) Илья: viewtopic.php?p=43186#p43186. Я потому и возвращаюсь к схемам и их топологиям. Что всё, что в тексте, должно иметь изоморфное представление как размеченного графа (ну и таблицы, как Вы для ряда случаев рекомендуете).

Автор:  Сергей Прохоренко [ Воскресенье, 20 Май, 2012 13:11 ]
Заголовок сообщения:  Re: Смысл ООП

Владислав Жаринов писал(а):
всё, что в тексте, должно иметь изоморфное представление как размеченного графа


Я надеюсь, что дерево классов - это не то, к чему Вы стремитесь.

Автор:  Владислав Жаринов [ Воскресенье, 20 Май, 2012 14:48 ]
Заголовок сообщения:  Re: Смысл ООП

Да в том-то и дело, что нет... скорее, как уже сказал, "схемы сборки" из кубиков. Но д.б. и законы, по которым собирать... вот в ГРАФКОНТе-то этим озаботились...

Автор:  Сергей Прохоренко [ Воскресенье, 20 Май, 2012 21:51 ]
Заголовок сообщения:  Re: Смысл ООП

Владислав Жаринов писал(а):
Да в том-то и дело, что нет... скорее, как уже сказал, "схемы сборки" из кубиков. Но д.б. и законы, по которым собирать... вот в ГРАФКОНТе-то этим озаботились...


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

Автор:  Владислав Жаринов [ Понедельник, 21 Май, 2012 21:22 ]
Заголовок сообщения:  Re: Смысл ООП

Да, согласен. Потому и сказано о схемах сборки. Т.е. соединений/подключений - в данном случае областей и отдельных вершин. Кстати, и таблицу спецификации давно мыслил как одну из форм представления - см. опять же эту задачу...

Страница 3 из 4 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/