Здравствуйте, 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.
А вывод сделан на основание ваших же слов — "пролистал, не читал, осуждаю".
