Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > IT форум > Общие вопросы по программированию, компьютерный форум
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 28.09.2012, 21:31   #1
Kostia
Участник клуба
 
Аватар для Kostia
 
Регистрация: 21.11.2007
Сообщений: 1,691
По умолчанию Мысли об обобщенном программировании, шаблонах и UML

Пишу под влиянием лекций про UML, прочтения книги "Современное проектирование на C++" Андрей Александреску и многого другого.

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

Код:
List<myClass, mySortStrategic, myMemoryAllocator, doublyLinkedList> data;
По сути это список который использует определенную пользователем стратегию сортировки, выделения памяти и является двусвязным списком.(последний является стандартной уже реализованной в стд библиотеке стратегией).

Конечно код выше не претендует на идеальную модель обобщенного кода. Я бы использовал абстрактную фабрику объектов в которой уже было бы определено несколько стратегий выделения памяти, которые срабатывали бы тоже по определенной стратегии. Например один алокатор заточен на выделение памяти под большие объекты, другой под маленькие. И естественно есть возможность менять эти стратегии.

Т.е. можно менять поведение частей программы(кода), не переписывая по несколько раз классы, не шарахаясь по модулям и классам. Но это чревато толстыми строчками кода как примере выше, а если распотрошить класс полностью, то можно и штук 20 стратегий вытащить.
Хотелось бы иметь возможность не перелопачивать все стратегии добираясь до нужной, а задавать только те, которые меняем, но даже так код становится громоздким и не читаемым.

Думаю уже догадались каким боком я приплел сюда UML. Предположим у нас есть база данных шаблонов, стратегий и функторов, мы можем создать объект шаблона задав ему определенный стратегии поведения, которые являются свойствами шаблона, если требуется то передали параметры конструктору(например размер вектора), затем применили к этому объекту функтор for_each, для которого либо написали свою функци, которая бы применялась к каждому объекту, либо передали туда лямбда функцию, либо примени существующий функтор(например Zero).
Естественно, в последнем случае, если тип элемента вектора не поддерживает присвоение нуля, то еще на моменте компиляции получи соответствующую ошибку.

Еще смею заметить проблему UML, это единый стандарт не привязанный к какому любо языку, это и хорошо и плохо. С одной стороны мы не зависим от конкретного языка, с другой мы не можем пользоваться вещами специфичными конкретному языку. Например атрибуты видимости +-#(public, privat, protected), а где published, и другие которые могут быть в других языках? Поэтому считаю что разработка модели multiUML (multi от multimethods) является очень даже правильным направлением.

Небольшой уже классический пример:
Есть у нас базовый класс shape и его потомки circle, rectangle, triangle. Естественно в программе мы работаем с массивом shape*. Нам требуется закрасить области пересечений фигур. Естественно писать общий метод работающий непосредственно с пикселями будет сильно толстый, а например набор (rectangle, rectangle), (rectangle, triangle), (circle, rectangle) и т.д. на самом деле не обязательно писать все определения, можно написать общий подход и несколько частных(например тех, которые чаше всего встречаются, или просто реализовать, или работаю во много раз быстрее чем общий). Эти конкретные реализации и есть мультиметоды.

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

Естественно что эти блоки можно объединять, задавать им атрибуты и получать новые, таким образом постоянно наращивая уровень абстракции кода и при этом имея возможно спуститься в самый низ и произвести asm вставку куда требуется.

Спасибо. Комментарии.

Последний раз редактировалось Kostia; 29.09.2012 в 11:32.
Kostia вне форума Ответить с цитированием
Старый 28.09.2012, 21:41   #2
the_deer_one
Участник клуба
 
Аватар для the_deer_one
 
Регистрация: 04.04.2010
Сообщений: 1,554
По умолчанию

Такое ощущение, что ты всё это прочитал залпом.
the_deer_one вне форума Ответить с цитированием
Старый 28.09.2012, 21:52   #3
Kostia
Участник клуба
 
Аватар для Kostia
 
Регистрация: 21.11.2007
Сообщений: 1,691
По умолчанию

В течении месяца умял несколько книг ))
Последним толчком к написанию текста что выше толкнула книжка "Исследование операций" В. А. Горелик, И. А. Ушаков
На пару сл. месяцев запланированы:
"Алгоритмы. Построение и анализ" Томас Кормен, Чарльз Лейзерсон, Рональд Ривест, Клиффорд Штайн
"Алгоритмы на C++" Роберт Седжвик
"Алгоритмы и структуры данных" Л. Г. Гагарина, В. Д. Колдаев
Как бы с ума не сойти )))
Kostia вне форума Ответить с цитированием
Старый 29.09.2012, 00:06   #4
Utkin
Старожил
 
Аватар для Utkin
 
Регистрация: 04.02.2009
Сообщений: 18,136
По умолчанию

Цитата:
Есть у нас базовый класс shape и его предки circle, rectangle, triangle.
Ничего не перепутали? Может потомки, а не предки?

Цитата:
Идея multiUML, а именно как возможность строить код из уже имеющихся кусочков позволяет видеть программу в более наглядной форме и при необходимости спускаться до уровня написания кода.
Еще чуть-чуть и Вы откроете структурное программирование.

Ваша идея абсолютно бесполезна для моей текущей задачи. Я хочу построить N-мерное дерево, то есть дерево в котором узел может иметь произвольное число узлов. Как Ваша идея может мне помочь? Никак. Только запудрить мозг. Сортировка это студенческая задача. Она нужна очень редко в практических разработках. И обычно вполне хватает готовых библиотек.

Цитата:
Положим что существует общий стандарт для обобщенного программирования для разных языков поддерживающих интерфейсы и шаблоны.
Шаблоны вроде поддерживает только С++. Даже в С # вроде концепция немного отличается, в Дельфи уже есть некотрые серьезные различия.

Цитата:
с другой мы не можем пользоваться вещами специфичными конкретному языку
Можем. Дельфя вроде умеет переводить большую часть UML в код. Правда я сам этим никогда не пользовался.
Маньяк-самоучка
Utkin появился в результате деления на нуль.
Осторожно! Альтернативная логика

Последний раз редактировалось Utkin; 29.09.2012 в 00:12.
Utkin вне форума Ответить с цитированием
Старый 29.09.2012, 10:44   #5
Kostia
Участник клуба
 
Аватар для Kostia
 
Регистрация: 21.11.2007
Сообщений: 1,691
По умолчанию

Цитата:
Сообщение от Utkin
Ничего не перепутали? Может потомки, а не предки?
Да, именно так.
Цитата:
Сообщение от Utkin
Можем. Дельфя вроде умеет переводить большую часть UML в код. Правда я сам этим никогда не пользовался.
Языков в моем редакторе UML штук 20, но у UML нет готовых решений для реализации стратегического программирования, например. И я уже привел пример с published.
Цитата:
Сообщение от Utkin
Шаблоны вроде поддерживает только С++. Даже в С # вроде концепция немного отличается, в Дельфи уже есть некотрые серьезные различия.
Нужно было написать шаблоны или интерфейсы. И есть еще язык D, в нем шаблоны на весьма высоком уровне.
Цитата:
Сообщение от Utkin
Ваша идея абсолютно бесполезна для моей текущей задачи. Я хочу построить N-мерное дерево, то есть дерево в котором узел может иметь произвольное число узлов. Как Ваша идея может мне помочь? Никак. Только запудрить мозг. Сортировка это студенческая задача. Она нужна очень редко в практических разработках. И обычно вполне хватает готовых библиотек.
Все очень просто, допустим в базе готовых шаблонов(паттернов) уже есть обобщенная реализация деревьев и вы дописываете только те стратегии поведения/построения дерева которые вам нужны.
Но я же не о написание программы в целом, а о построении ее из кусочков, примерно также вы бросаете на форму кнопочки и др. готовые элементы и настраиваете их под себя.
Цитата:
Сообщение от Utkin
Сортировка это студенческая задача. Она нужна очень редко в практических разработках. И обычно вполне хватает готовых библиотек.
Часто встречаюсь с сортировкой, но действительно, правильно построенный запрос к базе и своих сортировок писать не нужно. Это я привел как простой и наглядный пример обобщенного программирования.
Зачем заново переписывать классы и функции целиком, когда требуется поменять только часть их поведения. Зачем плодить классы одних и тех же виджетов, ради переопределения одной-двух функций?

Последний раз редактировалось Kostia; 29.09.2012 в 11:04.
Kostia вне форума Ответить с цитированием
Старый 30.09.2012, 18:16   #6
Utkin
Старожил
 
Аватар для Utkin
 
Регистрация: 04.02.2009
Сообщений: 18,136
По умолчанию

Цитата:
И есть еще язык D, в нем шаблоны на весьма высоком уровне.
Угу, только он еще недостаточно распространен. И неизвестно повторит ли он судьбу с++ или его ждет участь Оберона?
Цитата:
уже есть обобщенная реализация деревьев
Я своей модели не нашел. Че дальше?
Цитата:
примерно также вы бросаете на форму кнопочки
Я уже давно не бросаю на форму кнопочки. Большую часть времени занимает именно проектирование и только потом написание программы. А уже кнопкокидательством также занимаются в основном только студенты.

Цитата:
и др. готовые элементы и настраиваете их под себя.
Поздравляю Вас - структурное программирование вновь открыто. Вам осталось еще открыть для себя ДЛЛ и жизнь наладится.

Цитата:
Это я привел как простой и наглядный пример обобщенного программирования.
В том то весь и замес, что дальше учебных задач дело продвигается туго.
Цитата:
Зачем заново переписывать классы и функции целиком, когда требуется поменять только часть их поведения.
Затем, что они не удовлетворяют моим требованиям.
Цитата:
Зачем плодить классы одних и тех же виджетов, ради переопределения одной-двух функций?
А причем здесь вообще виджеты?
Маньяк-самоучка
Utkin появился в результате деления на нуль.
Осторожно! Альтернативная логика
Utkin вне форума Ответить с цитированием
Старый 01.10.2012, 11:26   #7
Kostia
Участник клуба
 
Аватар для Kostia
 
Регистрация: 21.11.2007
Сообщений: 1,691
По умолчанию

Цитата:
Я уже давно не бросаю на форму кнопочки. Большую часть времени занимает именно проектирование и только потом написание программы. А уже кнопкокидательством также занимаются в основном только студенты.
И каким же образом вы проектируете? Я использую UML, а Вы?
Цитата:
В том то весь и замес, что дальше учебных задач дело продвигается туго.
Цитата:
Затем, что они не удовлетворяют моим требованиям.
Цитата:
А причем здесь вообще виджеты?
Не вижу смысла дальше спорить.
http://ru.wikipedia.org/wiki/%D0%9E%...BD%D0%B8%D0%B5
http://ru.wikipedia.org/wiki/%D0%90%...80%D0%B5%D0%B9
http://www.ozon.ru/context/detail/id/3829080/
Kostia вне форума Ответить с цитированием
Старый 01.10.2012, 11:34   #8
Utkin
Старожил
 
Аватар для Utkin
 
Регистрация: 04.02.2009
Сообщений: 18,136
По умолчанию

Цитата:
Я использую UML, а Вы?
Листочек в клеточку и ручку. Иногда Ворд.
Я с Вами особо еще не спорил, Вы просили комментарии, вот и мое мнение .
И если Вам интересно еще мое мнение, касательно С++: там обобщенное программирование это костыль. От строгой типизации.
Возьмите к примеру Scheme там все числа являются комплексными (для программиста) и потому легко преобразовываются и сравниваются. И потому детский пример с сравнением любого числа по шаблону там просто не имеет смысла. Я молчу про Лисп и иже с ним. Практически все они имеют набор АТД и тот же вектор в Шеме может содержать любую информацию (в том числе и векторы) и там соответственно нет и половины созданных программистом проблем. Я понимаю у Вас эйфория от новой информации, но не следует особо возлагать надежды - шаблоны существуют давно, однако резких прорывов в программировании нет. Все чем мы пользуемся сейчас (и шаблоны тоже) открыто примерно до 70-х годов. За 40 лет ни одной революционной концепции не создано.
Маньяк-самоучка
Utkin появился в результате деления на нуль.
Осторожно! Альтернативная логика

Последний раз редактировалось Utkin; 01.10.2012 в 12:05.
Utkin вне форума Ответить с цитированием
Старый 01.10.2012, 12:07   #9
pu4koff
Старожил
 
Аватар для pu4koff
 
Регистрация: 22.05.2007
Сообщений: 9,520
По умолчанию

Цитата:
Сообщение от Kostia Посмотреть сообщение
Пишу под влиянием лекций про UML, прочтения книги "Современное проектирование на C++" Андрей Александреску и многого другого.
Бросайте плюсы и переходите на шарп, на край жабу или еще чего. Там уже многие вкусности есть "из коробки".
Цитата:
Сообщение от Kostia Посмотреть сообщение
Положим что существует общий стандарт для обобщенного программирования для разных языков поддерживающих интерфейсы и шаблоны. Т.е. существует общий подход к написанию расширяемого кода, кода которому можно задавать разные стратегии.
Проблема в том, что его нет и не будет. Люди до сих пор не придут к общему мнению по поводу обработки исключений, а тут такой серьезный стандарт.
Цитата:
Сообщение от Kostia Посмотреть сообщение
Конечно код выше не претендует на идеальную модель обобщенного кода. Я бы использовал абстрактную фабрику объектов в которой уже было бы определено несколько стратегий выделения памяти, которые срабатывали бы тоже по определенной стратегии. Например один алокатор заточен на выделение памяти под большие объекты, другой под маленькие. И естественно есть возможность менять эти стратегии.
Всё это есть уже в тех же плюсах. В чём проблема? Хочется, чтобы класс списка был написан на С++, а половина объектов создана на делфях?
Цитата:
Сообщение от Kostia Посмотреть сообщение
Думаю уже догадались каким боком я приплел сюда UML.
Я не догадался. А под UML понимается только диаграмма классов (самая банальная и бесполезная из всего набора)?
Цитата:
Сообщение от Kostia Посмотреть сообщение
Предположим у нас есть база данных шаблонов, стратегий и функторов, мы можем создать объект шаблона задав ему определенный стратегии поведения, которые являются свойствами шаблона, если требуется то передали параметры конструктору(например размер вектора), затем применили к этому объекту функтор for_each, для которого либо написали свою функци, которая бы применялась к каждому объекту, либо передали туда лямбда функцию, либо примени существующий функтор(например Zero).
Диаграмма классов не содержит реализацию и идёт в разрезе классов, а не объектов. Я себе смутно представляю как всё это должно работать (разве что все объекты делать без состояний, а данные хранить в структурах).
Цитата:
Сообщение от Kostia Посмотреть сообщение
Еще смею заметить проблему UML, это единый стандарт не привязанный к какому любо языку, это и хорошо и плохо.
UML не подразумевает под собой реализацию. Он просто не создан для воплощения на конкретном языке. Неправильно впихивать в него невпихуемое. Если нужно графическое воплощение иерархии классов для конкретных реализаций, то тут уже по идее не к UML.
Цитата:
Сообщение от Kostia Посмотреть сообщение
Есть у нас базовый класс shape и его потомки circle, rectangle, triangle. Естественно в программе мы работаем с массивом shape*. Нам требуется закрасить области пересечений фигур. Естественно писать общий метод работающий непосредственно с пикселями будет сильно толстый, а например набор (rectangle, rectangle), (rectangle, triangle), (circle, rectangle) и т.д. на самом деле не обязательно писать все определения, можно написать общий подход и несколько частных(например тех, которые чаше всего встречаются, или просто реализовать, или работаю во много раз быстрее чем общий). Эти конкретные реализации и есть мультиметоды.
Мультиметоды - полезная вещь для криворуких архитекторов. Когда спроектировали систему так, что в ООП оно нормально не вписывается и на виртуальные методы не ложится, тогда спасаются мультиметоды. Как по мне, так в 99% задач эта вещь не нужна, а её необходимость с большой вероятностью вытекает из плохой архитектуры.
Почему вот, например, за пересечение непонятно чего, должен отвечать базовый класс? Пусть это самое непонятно что и проверяет себя на пересечение со всем остальным.
Цитата:
Сообщение от Kostia Посмотреть сообщение
Идея multiUML, а именно как возможность строить код из уже имеющихся кусочков позволяет видеть программу в более наглядной форме и при необходимости спускаться до уровня написания кода. Также можно моделировать разветвления потоков выполнения программ простым вырисовыванием схемы. Генерация кода в реальном времени.
Ага. Создатели ООП тоже говорили что-то про повторное использование кода... Где оно это повторное использование на деле и почему не взлетело?
Цитата:
Сообщение от Kostia Посмотреть сообщение
Естественно что эти блоки можно объединять, задавать им атрибуты и получать новые, таким образом постоянно наращивая уровень абстракции кода и при этом имея возможно спуститься в самый низ и произвести asm вставку куда требуется.
Красиво звучит, но на деле работать не будет.
pu4koff вне форума Ответить с цитированием
Старый 01.10.2012, 17:25   #10
Kostia
Участник клуба
 
Аватар для Kostia
 
Регистрация: 21.11.2007
Сообщений: 1,691
По умолчанию

Цитата:
Сообщение от pu4koff
Всё это есть уже в тех же плюсах. В чём проблема? Хочется, чтобы класс списка был написан на С++, а половина объектов создана на делфях?
Нет конечно, это высшая форма изврата, на мой взгляд. Идея состоит в том чтобы менять поведение класса. Например те же умные указатели, есть несколько стратегий поведения:
1. стратегия глубокого копирования(есть и не глубокого xD )
2. стратегия уничтожающего копирования(auto_ptr)
3. стратегия подсчета ссылок
4. стратегия связных списков
По сути у нас всего 1 класс smart_ptr, но мы сами задаем по какой стратегии он будет работать.
Идея обобщенного программирования подразумевает отделить логику от данных. т.е. есть у на дерево, мы можем запросто создать дерево деревьев или вообще реализовать процесс авто генерации деревьев-деревьев рекурсивно.
Цитата:
Сообщение от pu4koff
Бросайте плюсы и переходите на шарп, на край жабу или еще чего. Там уже многие вкусности есть "из коробки".
У меня под плюсами гораздо больше ^^
Впрочем я уже программировал на C# и на ruby и даже литературу по scheme читал(scheme показался крайне отвратительным).
Тем более я существую под Linux, а mono знаете ли ...

Я лично не понимаю всех этих разговоров про отсутствие сборщика мусора в C++. Кто кроме студентов в наше время может впиндюрить int *array = new int[50];? И таких моментов полно относительно кодировки приложения, написания велосипедов, костылей и просто выдумывания собственных "парадигм" решения.
Все уже придумано, мы ничего придумать точно не сможем, разве что на стыке чего либо.

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

Цитата:
Сообщение от pu4koff
Диаграмма классов не содержит реализацию и идёт в разрезе классов, а не объектов. Я себе смутно представляю как всё это должно работать (разве что все объекты делать без состояний, а данные хранить в структурах).
Лично я этого тоже до конца не представляю, но цель сделать все максимально просто и прозрачно.

Цитата:
Сообщение от pu4koff
Ага. Создатели ООП тоже говорили что-то про повторное использование кода... Где оно это повторное использование на деле и почему не взлетело?
Многим просто лень копаться и пишут свои велосипеды
Автогенерация кода частично решает эту проблему

С UML плохой пример, просто именно он меня и натолкнул на идею проектирования и одновременной реализации программы.

Цитата:
Сообщение от pu4koff
Мультиметоды - полезная вещь для криворуких архитекторов. Когда спроектировали систему так, что в ООП оно нормально не вписывается и на виртуальные методы не ложится, тогда спасаются мультиметоды. Как по мне, так в 99% задач эта вещь не нужна, а её необходимость с большой вероятностью вытекает из плохой архитектуры.
Цитата:
Почему вот, например, за пересечение непонятно чего, должен отвечать базовый класс? Пусть это самое непонятно что и проверяет себя на пересечение со всем остальным.
Система становится жесткой и не расширяемой. При добавлении нового непонятно чего придется переписывать все предыдущие классы.
Kostia вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Указатели в шаблонах (C++) streimer Помощь студентам 4 25.09.2012 00:07
проблемы с operator = в шаблонах monnzz Общие вопросы C/C++ 6 11.05.2012 20:58
PHP код в шаблонах CMS MrakSPb PHP 7 03.08.2010 15:16
Мысли Elm0 Свободное общение 0 23.06.2007 21:42