|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
28.09.2012, 21:31 | #1 |
Участник клуба
Регистрация: 21.11.2007
Сообщений: 1,692
|
Мысли об обобщенном программировании, шаблонах и UML
Пишу под влиянием лекций про UML, прочтения книги "Современное проектирование на C++" Андрей Александреску и многого другого.
Положим что существует общий стандарт для обобщенного программирования для разных языков поддерживающих интерфейсы и шаблоны. Т.е. существует общий подход к написанию расширяемого кода, кода которому можно задавать разные стратегии. Пример: Список у которого определена стратегия сортировки, по умолчанию список использует сортировку по возрастанию(если определено отношение порядка для элементов списка), мы же хотим чтобы сортировка была произведена по нескольким параметрам и собственному закону, для этого реализовываем свою стратегию сортировки и передаем ее в список. Код:
Конечно код выше не претендует на идеальную модель обобщенного кода. Я бы использовал абстрактную фабрику объектов в которой уже было бы определено несколько стратегий выделения памяти, которые срабатывали бы тоже по определенной стратегии. Например один алокатор заточен на выделение памяти под большие объекты, другой под маленькие. И естественно есть возможность менять эти стратегии. Т.е. можно менять поведение частей программы(кода), не переписывая по несколько раз классы, не шарахаясь по модулям и классам. Но это чревато толстыми строчками кода как примере выше, а если распотрошить класс полностью, то можно и штук 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. |
28.09.2012, 21:41 | #2 |
Участник клуба
Регистрация: 04.04.2010
Сообщений: 1,554
|
Такое ощущение, что ты всё это прочитал залпом.
|
28.09.2012, 21:52 | #3 |
Участник клуба
Регистрация: 21.11.2007
Сообщений: 1,692
|
В течении месяца умял несколько книг ))
Последним толчком к написанию текста что выше толкнула книжка "Исследование операций" В. А. Горелик, И. А. Ушаков На пару сл. месяцев запланированы: "Алгоритмы. Построение и анализ" Томас Кормен, Чарльз Лейзерсон, Рональд Ривест, Клиффорд Штайн "Алгоритмы на C++" Роберт Седжвик "Алгоритмы и структуры данных" Л. Г. Гагарина, В. Д. Колдаев Как бы с ума не сойти ))) |
29.09.2012, 00:06 | #4 | ||||
Старожил
Регистрация: 04.02.2009
Сообщений: 17,351
|
Цитата:
Цитата:
Ваша идея абсолютно бесполезна для моей текущей задачи. Я хочу построить N-мерное дерево, то есть дерево в котором узел может иметь произвольное число узлов. Как Ваша идея может мне помочь? Никак. Только запудрить мозг. Сортировка это студенческая задача. Она нужна очень редко в практических разработках. И обычно вполне хватает готовых библиотек. Цитата:
Цитата:
Маньяк-самоучка
Utkin появился в результате деления на нуль. Осторожно! Альтернативная логика Последний раз редактировалось Utkin; 29.09.2012 в 00:12. |
||||
29.09.2012, 10:44 | #5 | |||||
Участник клуба
Регистрация: 21.11.2007
Сообщений: 1,692
|
Цитата:
Цитата:
Цитата:
Цитата:
Но я же не о написание программы в целом, а о построении ее из кусочков, примерно также вы бросаете на форму кнопочки и др. готовые элементы и настраиваете их под себя. Цитата:
Зачем заново переписывать классы и функции целиком, когда требуется поменять только часть их поведения. Зачем плодить классы одних и тех же виджетов, ради переопределения одной-двух функций? Последний раз редактировалось Kostia; 29.09.2012 в 11:04. |
|||||
30.09.2012, 18:16 | #6 | |||||||
Старожил
Регистрация: 04.02.2009
Сообщений: 17,351
|
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Маньяк-самоучка
Utkin появился в результате деления на нуль. Осторожно! Альтернативная логика |
|||||||
01.10.2012, 11:26 | #7 | ||||
Участник клуба
Регистрация: 21.11.2007
Сообщений: 1,692
|
Цитата:
Цитата:
Цитата:
Цитата:
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/ |
||||
01.10.2012, 11:34 | #8 | |
Старожил
Регистрация: 04.02.2009
Сообщений: 17,351
|
Цитата:
Я с Вами особо еще не спорил, Вы просили комментарии, вот и мое мнение . И если Вам интересно еще мое мнение, касательно С++: там обобщенное программирование это костыль. От строгой типизации. Возьмите к примеру Scheme там все числа являются комплексными (для программиста) и потому легко преобразовываются и сравниваются. И потому детский пример с сравнением любого числа по шаблону там просто не имеет смысла. Я молчу про Лисп и иже с ним. Практически все они имеют набор АТД и тот же вектор в Шеме может содержать любую информацию (в том числе и векторы) и там соответственно нет и половины созданных программистом проблем. Я понимаю у Вас эйфория от новой информации, но не следует особо возлагать надежды - шаблоны существуют давно, однако резких прорывов в программировании нет. Все чем мы пользуемся сейчас (и шаблоны тоже) открыто примерно до 70-х годов. За 40 лет ни одной революционной концепции не создано.
Маньяк-самоучка
Utkin появился в результате деления на нуль. Осторожно! Альтернативная логика Последний раз редактировалось Utkin; 01.10.2012 в 12:05. |
|
01.10.2012, 12:07 | #9 | |||||||
Старожил
Регистрация: 22.05.2007
Сообщений: 9,085
|
Цитата:
Цитата:
Цитата:
Я не догадался. А под UML понимается только диаграмма классов (самая банальная и бесполезная из всего набора)? Цитата:
Цитата:
Цитата:
Почему вот, например, за пересечение непонятно чего, должен отвечать базовый класс? Пусть это самое непонятно что и проверяет себя на пересечение со всем остальным. Цитата:
Красиво звучит, но на деле работать не будет. |
|||||||
01.10.2012, 17:25 | #10 | ||||||
Участник клуба
Регистрация: 21.11.2007
Сообщений: 1,692
|
Цитата:
1. стратегия глубокого копирования(есть и не глубокого xD ) 2. стратегия уничтожающего копирования(auto_ptr) 3. стратегия подсчета ссылок 4. стратегия связных списков По сути у нас всего 1 класс smart_ptr, но мы сами задаем по какой стратегии он будет работать. Идея обобщенного программирования подразумевает отделить логику от данных. т.е. есть у на дерево, мы можем запросто создать дерево деревьев или вообще реализовать процесс авто генерации деревьев-деревьев рекурсивно. Цитата:
Впрочем я уже программировал на C# и на ruby и даже литературу по scheme читал(scheme показался крайне отвратительным). Тем более я существую под Linux, а mono знаете ли ... Я лично не понимаю всех этих разговоров про отсутствие сборщика мусора в C++. Кто кроме студентов в наше время может впиндюрить int *array = new int[50];? И таких моментов полно относительно кодировки приложения, написания велосипедов, костылей и просто выдумывания собственных "парадигм" решения. Все уже придумано, мы ничего придумать точно не сможем, разве что на стыке чего либо. Я же предлагаю систему накопления данных, а именно кода для разных языков, который будет(должен) написан в соответствии с определенной парадигмой для конкретного языка и исходя из этих знаний сформировать системы не для написания программ и для их сборки, удобного визуального представления для максимальной наглядности и возможности строить сложные многопоточные приложения не в одиночку а в команде. С естественной поддержкой расширения возможностей как у себя в локальных хранилищах, так и отправлять в глобальное хранилище.(естественно с премодерацией) Цитата:
Цитата:
Автогенерация кода частично решает эту проблему С UML плохой пример, просто именно он меня и натолкнул на идею проектирования и одновременной реализации программы. Цитата:
Цитата:
|
||||||
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Указатели в шаблонах (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 |