привет.
есть некий интерфейс IElement. В иерархии есть класс IGroup, который имеет все свойства интерфейса IElement, но отличается лишь тем, что может внутри хранить другие элементы и группы (некое дерево).
вопрос в том, какой паттерн используется для работы с такой иерархией?
Как это описать так, чтобы с одной стороны я всегда знал, какой тип у m_children[i], и с другой стороны мог работать с группой, как с элементом?
Пока в голову пришел только Посетитель (GoF): создать итератор на основе посетителя всей иерархии.
есть какие-то стандартные приемы, примеры?
Здравствуйте, sax0n, Вы писали:
S>есть какие-то стандартные приемы, примеры?
Обычно в таких случаях элемент сразу делается группой, т.е. не создают два класса — Элемент и Группа, а используют один. В качестве примера могу сослаться на объект Окно в Win32 API. Оно имеет указатель на родителя, входит в список сиблингов и хранит указатель на список чайлдов.
Другой вариант — сделать, как сделали Вы. Тогда смотрите в сторону паттерна Компоновщик.
P.S.: А для чего Вам нужна иерархия элементов? За выполнение каких обязанностей будет отвечать класс Элемент?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Обычно в таких случаях элемент сразу делается группой, т.е. не создают два класса — Элемент и Группа, а используют один. В качестве примера могу сослаться на объект Окно в Win32 API. Оно имеет указатель на родителя, входит в список сиблингов и хранит указатель на список чайлдов.
скиньте, пожалуйста, пример. для ГУИ тоже очень интересно посмотреть пример.
кстати, в примере из вики по ссылке ниж, по сути, элемент и есть группа (по интерфейсу).
КЛ>Другой вариант — сделать, как сделали Вы. Тогда смотрите в сторону паттерна Компоновщик.
В том примере компоновщик делает проверку во время выполнения. такое и я могу сделать. а я хочу во время компиляции, а лучше вообще без доступа к группирующим методам
КЛ>P.S.: А для чего Вам нужна иерархия элементов? За выполнение каких обязанностей будет отвечать класс Элемент?
В целом, у меня есть набор элементов (IElement) в пределах определенной области.
В этой области я могу создавать свои объекты (IObject), свойства которых могут быть основаны на свойствах 1+ IElement.
в иерархии IObject есть такие, которые могут хранить в себе другие IObject (IGroup).
В итоге у меня есть дерево IObject, по которому я могу пройтись, но я так же хочу иметь возможность сохранить информацию о типе, т.е. знать, что конкретный IObject есть IGroup или его наследник.
Возможно, я в корне неправильно составил иерархию.
Примером аналогии могут быть теги из HTML, например, <div> — сам по себе это ITag, но у него есть children()
вот что-то типа такого нужно сделать.
Здравствуйте, sax0n, Вы писали:
S>Как это описать так, чтобы с одной стороны я всегда знал, какой тип у m_children[i], и с другой стороны мог работать с группой, как с элементом? S>Пока в голову пришел только Посетитель (GoF): создать итератор на основе посетителя всей иерархии. S>есть какие-то стандартные приемы, примеры?
Здравствуйте, Ikemefula, Вы писали:
I>"итератор на основе посетителя" — это сильно
это не самое худшее, что приходило в голову
нужно еще разок GoF перечитать.. как-то не собирается воедино все.
Здравствуйте, sax0n, Вы писали:
I>>"итератор на основе посетителя" — это сильно S>это не самое худшее, что приходило в голову S>нужно еще разок GoF перечитать.. как-то не собирается воедино все.
Для паттернов, возьми книгу например Джошуа Кериевски, "Рефакторинг с использованием шаблонов".
В ней паттерны расписываются гораздо лучше и понятнее, автор злоупотребил Фаулером, но в целом очень, очень сильно.
Кроме того, есть книга Кента Бека "Экстремальное программирование. Разработка через тестирование" — просто адская вещь.
GoF это вобщем то словарь, что бы можно было читать книги вроде перечисленых. Без них она смысла в ней мало.
Здравствуйте, Ikemefula, Вы писали:
I>Кроме того, есть книга Кента Бека "Экстремальное программирование. Разработка через тестирование" — просто адская вещь.
Это не та книжка, в которой Кент Бек объяснял пользу юнит-тестирования на примерчиках:
Здравствуйте, sax0n, Вы писали:
S>скиньте, пожалуйста, пример. для ГУИ тоже очень интересно посмотреть пример.
Посмотрите здесь.
S>В том примере компоновщик делает проверку во время выполнения. такое и я могу сделать. а я хочу во время компиляции, а лучше вообще без доступа к группирующим методам
Зачем?
S>Возможно, я в корне неправильно составил иерархию.
ИМХО, слишком сложно. Да и непонятно, зачем нужны разные типы. Создайте один объект — Узел дерева. Он может быть и листом, и поддеревом. И в любой момент преобразоваться из листа в поддерево, а из поддерева — в лист (путём добавления или удаления дочерних элементов).
Если уж такое решение кажется некрасивым, то создайте два класса — Элемента и Группа и преобразуйте один к другому в ран-тайме.
А вообще, дизайн сильно зависит от того, какие операции Вы будете выполнять над этим деревом. Пока что Вы описали его в статике, а чтобы посоветовать что-то конкретное хорошо бы знать динамику.
Здравствуйте, Кирилл Лебедев, Вы писали:
I>>Кроме того, есть книга Кента Бека "Экстремальное программирование. Разработка через тестирование" — просто адская вещь. КЛ>Это не та книжка, в которой Кент Бек объяснял пользу юнит-тестирования на примерчиках:
КЛ>
Здравствуйте, Ikemefula, Вы писали:
I>Да, она. Только там не про пользу юнит-тестирования, а про решение задачи с использованием юнит-тестирования.
В таком случае, я бы не стал рекомендовать эту книгу по двум основаниям.
Во-первых, соотношения курсов валют определяют финансовые площадки, а не непонятный класс Money.
Во-вторых, дизайн, в котором названия валют зашиты в виде функций, ни к чему хорошему не приведёт: код придётся изменять при желании поддержать новую валюту.
Резюме: подход к проектированию, который не позволяет вовремя просечь эти вещи, ИМХО, не является работоспособным.
Здравствуйте, sax0n, Вы писали:
S>Книжку многие рекомендуют, так что почитать стоит. но конкретно этот вырванный из контекста код выглядит немного некрасиво ( Money.dollars )
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Посмотрите здесь.
WinAPI в теме про ООП — не особо хороший пример ИМХО. C-style со своими плюшками. Или я не туда посмотрел?
S>>В том примере компоновщик делает проверку во время выполнения. такое и я могу сделать. а я хочу во время компиляции, а лучше вообще без доступа к группирующим методам КЛ>Зачем?
Александреску начитался =)
а вообще, почему Зачем?! для легкости и однозначности использования, типобезопасности и т.д.
КЛ>ИМХО, слишком сложно. Да и непонятно, зачем нужны разные типы. Создайте один объект — Узел дерева. Он может быть и листом, и поддеревом. И в любой момент преобразоваться из листа в поддерево, а из поддерева — в лист (путём добавления или удаления дочерних элементов).
КЛ>Если уж такое решение кажется некрасивым, то создайте два класса — Элемента и Группа и преобразуйте один к другому в ран-тайме.
почему же сложно?
я хочу, чтобы в моем интерфейсе IElement только в нужный момент появлялись методы интерфейса IGroup, чтобы они были вообще недоступны для обычных элементов (а не были заглушки).
не хочется делать так для всех элементов:
structure< IElement >::iterator iter;
if ( iter->hasChildren() ){}
а хочется точно знать, что у этого элемента могут быть (0+ штук) или не могут быть элементы вообще и т.д. Можно сделать и так, как вы предлагаете. просто есть возможность еще поиграться и выбрать самую удобную, красивую и безопасную архитектуру.
встречный вопрос, а что тогда почитать?
у меня лежит GoF и Фаулер "Проектирование корпоративных приложений".
Хочется чего-то практического, а не просто справочник полистать по паттернам.
Здравствуйте, Кирилл Лебедев, Вы писали:
I>>Да, она. Только там не про пользу юнит-тестирования, а про решение задачи с использованием юнит-тестирования.
КЛ>В таком случае, я бы не стал рекомендовать эту книгу по двум основаниям.
КЛ>Во-первых, соотношения курсов валют определяют финансовые площадки, а не непонятный класс Money.
Если бы ты читал книгу, то там бы и прочел, что Кент Бек и говорит, что Money описывает валюту, а не курсы валют.
Курсы валют для класса Money это внешняя сущность. Задача, на которой он показывал TDD, была исключительно про валюту.
КЛ>Во-вторых, дизайн, в котором названия валют зашиты в виде функций, ни к чему хорошему не приведёт: код придётся изменять при желании поддержать новую валюту.
У меня еще одно сомнение, что ты читал книгу.
КЛ>Резюме: подход к проектированию, который не позволяет вовремя просечь эти вещи, ИМХО, не является работоспособным.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, sax0n, Вы писали:
S>>встречный вопрос, а что тогда почитать?
КЛ>Посмотрите здесь и здесь.
не совсем подходит. нужна 1-2 книжки, а не 100500..
Здравствуйте, Кирилл Лебедев, Вы писали:
S>>Книжку многие рекомендуют, так что почитать стоит. но конкретно этот вырванный из контекста код выглядит немного некрасиво ( Money.dollars )
КЛ>Там везде такой код.
Здравствуйте, sax0n, Вы писали:
S>встречный вопрос, а что тогда почитать? S>у меня лежит GoF и Фаулер "Проектирование корпоративных приложений". S>Хочется чего-то практического, а не просто справочник полистать по паттернам.
Фаулер это немного другая область.
Попробуй те книги что я тебе предложил.
Если уж сильно не доверяешь Кенту Беку, посмотри книгу Физерса "Legacy Code" или Роберта Мартина "Чистый код", но это достаточно сложные книги.
Одно плохо — у Фаулер, Физерс, Мартин, Бек, Кериевски, Эванс, Канингем — это одна и таже банда.
Они все дизайн выводят через тестирование/рефакторинг/итерации.
Если ты хочешь посмотреть деяния другой ОПГ — попробуй Буча или Лармана, там совершенно другой подход к проектированию. Но лично я плохо знаком с работами этих товарищей.
Кстати, есть такая вещь, как Funq, автор — Daniel Cazzulino записал серию скринкастов как он разрабатывал этот фреймворк.
Там используется именно тот подход, который описывает Кент Бек в книге про TDD.
Здравствуйте, Ikemefula, Вы писали:
I>Загляни в книгу, там можешь конечный результат увидеть
Конечный результат не впечатляет. Как и разбираемый Кентом Беком пример.
Если бы Кент Бек взял бы реальную задачу (например, какую-нибудт бизнес-аппликуху, GPS-навигационную систему, компьютерную игру или что-то другое) и продемонстрировал бы возможности методологии на реальном примере, то отношение было бы другое.
Здравствуйте, Кирилл Лебедев, Вы писали:
I>>Загляни в книгу, там можешь конечный результат увидеть КЛ>Конечный результат не впечатляет. Как и разбираемый Кентом Беком пример.
Конечного результата там нет и Кент Бек на это указывает.
КЛ>Если бы Кент Бек взял бы реальную задачу (например, какую-нибудт бизнес-аппликуху, GPS-навигационную систему, компьютерную игру или что-то другое) и продемонстрировал бы возможности методологии на реальном примере, то отношение было бы другое.
Ага, показать XP+TDD на реальном приложении — на это и десяти книг не выйдет.
TDD это не чудеса, это работа с кодом. Он взял именно такую задачу, котороу можно показать в книге.
Здравствуйте, Кирилл Лебедев, Вы писали:
I>>Враньё ! КЛ>Не надо грубить. В данном случае, неправду говорите Вы.
Я говорю 1 книги ты не прочел 2 конечного результата ты видеть не мог
Кент Бек начинает с классов Dollar+Franс а заканчивает Money+Bank+Expression.
Money — для денег, Банк — для курсов, Expression — это фактически деревья выражений.
Еще раз — ты видел только промежуточные резултаты.
I>>Так выглядит промежуточный код и код в тестах.
КЛ>Нет. Такого рода код написан и далее.
Представь себе — во всех книгах Кент Бек подчеркивает важность ЧИСТОГО кода.
Метафора из его книги — живот пациента во время операции выглядит отвратительно.
I>>Ты книги не читал, лучше б молчал
КЛ>Для меня достаточно, что я посмотрел код примеров во всей книжке, а также — просмотрел отдельные главы.
Ты понимаешь, что ты смотрел в основном промежуточные результаты и тесты ?
Ты не мог видет конечного результата, т.к. в книге его просто нет !
Что бы получить его, надо проделать все его шаги и выполнить рекомендации из главы "Ретроспектива денежного примера" в частности "Что дальше ?".
КЛ>Если ты не понимаешь разницы между надуманными примерами и примерами из реальной жизни (для реальных проектов), то это не моя проблема.
У него реальный пример. Не на 100% реализованый, но реальный.
Я видел несколько приложений, в которых использовались Currency+Rate и это было жуткое зрелище.
Здравствуйте, Кирилл Лебедев, Вы писали:
I>>Да, она. Только там не про пользу юнит-тестирования, а про решение задачи с использованием юнит-тестирования.
КЛ>В таком случае, я бы не стал рекомендовать эту книгу по двум основаниям.
Было бы лучше, если бы ты делился рекомендациями после прочтения, а не после пролистывания.
Здравствуйте, Ikemefula, Вы писали:
I>Я видел несколько приложений, в которых использовались Currency+Rate и это было жуткое зрелище.
Возьмём пример из главы "Abstraction, Finally" (предшествует упомянутой тобой главе "Money Retrospective"). Смотрим код:
public void testSumTimes() {
Expression fiveBucks = Money.dollar(5);
Expression tenFrancs = Money.franc(10);
Bank bank = new Bank();
bank.addRate("CHF", "USD", 2);
Expression sum = new Sum(fiveBucs, tenFrancs).times(2);
Money result = bank.reduce(sum, "USD");
assertEquals(Money.dollar(20), result);
}
На мой взгляд, этот код ничуть не лучше того, что был. Валюта по-прежнему фигурирует в названиях функций. Курс обмена по-прежнему задаётся ручками. Сама цель выполняемых операций непонятна. Написать программу для сравнения двух чисел могут и обычные школьники после прохождения обзорного курса информатики.
I>>Я видел несколько приложений, в которых использовались Currency+Rate и это было жуткое зрелище.
КЛ>Возьмём пример из главы "Abstraction, Finally" (предшествует упомянутой тобой главе "Money Retrospective"). Смотрим код:
КЛ>
КЛ>public void testSumTimes() {
КЛ> Expression fiveBucks = Money.dollar(5);
КЛ> Expression tenFrancs = Money.franc(10);
КЛ> Bank bank = new Bank();
КЛ> bank.addRate("CHF", "USD", 2);
КЛ> Expression sum = new Sum(fiveBucs, tenFrancs).times(2);
КЛ> Money result = bank.reduce(sum, "USD");
КЛ> assertEquals(Money.dollar(20), result);
КЛ>}
КЛ>
КЛ>На мой взгляд, этот код ничуть не лучше того, что был.
Еще раз — это тестовый код, что ясно из названия "testSumTimes".
Конечного результата в книге нет !
>Валюта по-прежнему фигурирует в названиях функций.
Функции dollar это фактически алиас для money("USD")
>Курс обмена по-прежнему задаётся ручками.
Это тестовый код. Никто не мешает тебе написать код для хранения состояния Bank в базе данных.
>Сама цель выполняемых операций непонятна.
Конечно непонятна, надо ведь книгу прочесть, хотя бы ту часть что про Money
>Написать программу для сравнения двух чисел могут и обычные школьники после прохождения обзорного курса информатики.
Здравствуйте, Ikemefula, Вы писали:
>>Валюта по-прежнему фигурирует в названиях функций. I>Функции dollar это фактически алиас для money("USD")
ИМХО, это абсолютно не гибкое решение. Для каждой валюты будем алиас создавать?
>>Сама цель выполняемых операций непонятна. I>Конечно непонятна, надо ведь книгу прочесть, хотя бы ту часть что про Money
К сожалению, книгу не читал, но можно в двух словах пересказать чем плох подход
Money + CurrencyRate ?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
>>>Валюта по-прежнему фигурирует в названиях функций. I>>Функции dollar это фактически алиас для money("USD") AJD>ИМХО, это абсолютно не гибкое решение. Для каждой валюты будем алиас создавать?
Конечно не гибкое. Оно сделано не для гибкости, а для того, что бы человек не знакомый с кодами валют мог работать с наиболее используемыми валютами.
Я лично не в курсе дел, какие валюты каким кодом задаются и от перечня валют в коде программы начинает пухнуть мозг.
И решение, как ты понимаешь, абсолютно необзятальное — с таким же успехом ты можешь все const something = "someValue" ; заменить на конкретные значения.
Неиспользование этого алиаса никоим образом тебя не ограничивает.
I>>Конечно непонятна, надо ведь книгу прочесть, хотя бы ту часть что про Money AJD>К сожалению, книгу не читал, но можно в двух словах пересказать чем плох подход AJD>Money + CurrencyRate ?
Он не плох. Но лично я видел почему то только плохие реализации.
Кент Бек пользуясь разными методами выводит Money + Bank + Expression из классов Dollar и Franc.
Т.е. он именно выводит, а не говорит, в духе Кирила Лебедева, "давайте напишем следующие классы и убедимся что ООП не работает".
В твоем случае Expression, что очевидно, отсутствует. Кто возьмет на себя эти обязанности ? Вызывающий код или Money+CurrencyRate ?
Здравствуйте, sax0n, Вы писали:
S>привет. S>есть некий интерфейс IElement. В иерархии есть класс IGroup, который имеет все свойства интерфейса IElement, но отличается лишь тем, что может внутри хранить другие элементы и группы (некое дерево).
S>вопрос в том, какой паттерн используется для работы с такой иерархией?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Ikemefula, Вы писали:
КЛ>Если бы Кент Бек взял бы реальную задачу (например, какую-нибудт бизнес-аппликуху, GPS-навигационную систему, компьютерную игру или что-то другое) и продемонстрировал бы возможности методологии на реальном примере, то отношение было бы другое.
Чушь. Ни одна книга не показывает решение реальной задачи по нескольким причинам:
1. Ограниченный объем самой книги;
2. Предметная область реальной задачи часто требует серьезно погружения в нее и разбирательство с ней выходит за рамки книги (именно поэтому так интернет-магазины любят в учебниках по web-приложениям — понятная предметная область);
3. Задачи берутся специально простые, чтобы не отвлекатся на суть задач, а сосредоточится на сути изложения.
Что-то вы в своем "курсе" не стали рассматривать GPS-навигатор, а взяли простенькую (в силу значительного упрощения) область в виде редактора векторной графике. Не порядок, срочно решайте реальную задачу.
Я понял, почему вы с такой помпой свое видение проектирования позиционируете — книги-то вы оказывается не читаете, а только просматриваете...
> Джошуа Кериевски, "Рефакторинг с использованием шаблонов"
спасибо. как раз читаю. но, думаю, что нужно все же читать "другую банду", вот хочу Буча почитать. Чтобы что-то исправлять в процессе нужно хоть что-то для начала сделать..
_FR>Что-то на уровне интерфейсов никакой разницы между группой и элементом не наблюдается Совершенно не понятно, какой цели служит class IGroup.
Здесь пока его и нет... я как раз и думаю над этими проблемами %)
Группа является таким же элементом. но она может содержать в себе подэлементы (при чем ограничивать контролировать типы, которые в нее кидают)
Дело в том, как спроектировать это: будет огромное количество элементов и групп. как в таком случае работать с ними, чтобы сохранить тип? вот я беру любой элемент в своем дерево, и как мне определить, какого он типа? при чем конкретно такое действие нужно.
Здравствуйте, LeonidV, Вы писали:
LV>Чушь. Ни одна книга не показывает решение реальной задачи по нескольким причинам:
Почему же. Например, у Буча разбираются вполне реальные задачи. И у Питера Коуда — тоже. Другое дело, что далеко не всегда можно согласиться с предложенными ими решениями. Но это — уже другая проблема.
LV>3. Задачи берутся специально простые, чтобы не отвлекатся на суть задач, а сосредоточится на сути изложения.
Методологию нужно проверять на реальных задачах. Иначе — как можно судить о её эффективности?
LV>Что-то вы в своем "курсе" не стали рассматривать GPS-навигатор, а взяли простенькую (в силу значительного упрощения) область в виде редактора векторной графике. Не порядок, срочно решайте реальную задачу.
У меня не 10 рук, чтобы описать все задачи сразу. Постепенно буду выкладывать и другие задачи. Вот сейчас думаю, о чём лучше написать в первую очередь — о навигационной системе или об играх. С играми попроще, потому что они требуют менее объёмного описания. И можно привести исходный код.
LV>Я понял, почему вы с такой помпой свое видение проектирования позиционируете — книги-то вы оказывается не читаете, а только просматриваете...
Из чего вы сделали такой вывод? У меня в блоге приведён достаточно объёмный список литературы.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>У меня не 10 рук, чтобы описать все задачи сразу. Постепенно буду выкладывать и другие задачи. Вот сейчас думаю, о чём лучше написать в первую очередь — о навигационной системе или об играх. С играми попроще, потому что они требуют менее объёмного описания. И можно привести исходный код.
Игры, конечно, разные бывают. Но не думаю, что архитектура средней игры будет простой. Только если поверхностно рассмотреть. Любая задача композиционно разбивается на более мелкии, что вы сами и пытаетесь пропогандировать. Соответственно, грамотное решение подзадач является неотъемлемой частью грамотного решения всей задачи.
LV>>Я понял, почему вы с такой помпой свое видение проектирования позиционируете — книги-то вы оказывается не читаете, а только просматриваете... КЛ>Из чего вы сделали такой вывод? У меня в блоге приведён достаточно объёмный список литературы.
Из его наличия не следует, что вы книги читали А вывод сделан на основание ваших же слов — "пролистал, не читал, осуждаю".
Совершенно не понятно, какой цели служит class IGroup.
А вывод сделан на основание ваших же слов — "пролистал, не читал, осуждаю".
