Паттерны проектирования

[MOPO3]

Качнул книгу по сабжу с сайта клуба. Читаю уже третий раз, и всё ещи никак не могу нормально "въехать" в это  Видать туповат я ещё для этого  :nono: Может есть где статьи в интернете о сабже, только ну совсем для даунов ? 

[Alf]

Если ты о нетленном творении "банды четырех", то книга IMHO не для чтения, а для практического применения. Читать ее подряд, как и любой справочник, не слишком интересно.

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

[LEON]

Для более легкого понимания паттернов, больше подходит книга Лармана. В ней описаны сам процесс разработки программы с применением паттернов, от анализа и до конца. примерно половина книга, на описание UML и UP а вторая часть непосредственно на шаблоны. А GoF это в большей степени справочник и настольная книга.

[xelos]

Лармана захотелось поиметь

http://vlgu.1gb.ru/i01/blog/archives/2004/09/04/novye-knigi/

не пускают, может из-за не российского ИП?
попробуйте, кто-нить, пожалуйста

[MOPO3]

У меня ИП не российский, и всё равно не пускают

[npak]

Скачал

Выложил по адресу http://www.ispras.ru/~npak/tmp/%5bLarman%5d%5bApplying_UML_And_Patterns%5d.pdf

[LP]

Качнул книгу по сабжу с сайта клуба. Читаю уже третий раз, и всё ещи никак не могу нормально "въехать" в это Видать туповат я ещё для этого :nono: Может есть где статьи в интернете о сабже, только ну совсем для даунов ?

Есть такая книга - "Философия С++ 2-й том", Эккель, Элисон изд. Питер. Там 10-я глава про паттерны.
Не читал книгу Гаммы и др. но в этой по-моему довольно хорошо написано... для начинающих.

Можешь посмотреть оригинал книги в инете - Thinking in C++ Volume 2 (Chuck Allison и Bruce Eckel).
http://kia.etel.ru/lib/thcpp/tic0286.html

[LP]

Извиняюсь, неудачную ссылку дал, там у них почему-то некоторые фрагменты пропущены:(
Лучше вот отсюда скачать:
http://mindview.net/Books/TICPP/ThinkingInCPP2e.html
(2-й том)

[nikedeforest]

LP, кажется эта книга есть на шелеке.

[LP]

Действительно есть:)

[xelos]

Скачал

Выложил по адресу http://www.ispras.ru/~npak/tmp/%5bLarman%5d%5bApplying_UML_And_Patterns%5d.pdf

спасип огромный

[ukrandruha]

Не подскажите почему я с шелеха немогу скачать эту, да и не только, книгу? (ip - ukraine)

[Finch]

Читай первый пост RXL от 25 Июль 2005 https://forum.shelek.ru/index.php/topic,6914.msg107548.html#msg107548. В последнем абзаце есть объяснения.

[Igel]

Не перевариваю электронные книжки, наверное нет подходящего устройства чтения.
Купил книженцию "Паттерны проектирования" издательства Питер. Есть много вопросов по реализации.
Общее впечатление - очень помогла по другому взглянуть на ООП.
LEON писал про Лармана, тоже хочу, а т.к. английский на уровне "интуитивного понимания Хелпа" - прочитать не получится. Отсюда вопрос - есть РУССКОЕ издание?

[Alf]

Есть. Я в "Озоне" покупал, в магазинах не попадалось.

[Igel]

А как книга-то называется, та что Лармана? Хотя у него судя по всему много. Но та, что с паттернами проектирования?

[Alf]

Я полагаю, речь идет о книге: К. Ларман, "Применение UML и шаблонов проектирования".

Хотел скинуть ссылку на "Озон", но там уже нет ее.

[Igel]

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

[Alf]

Лично я применяю частично. Идею парного программирования отбросил сразу. У меня не лежит к ней душа, да и до руководства, думаю, вряд ли ее донес бы. Два программиста за компьютером - все равно что два землекопа с одной лопатой.

А вот идея писать тесты одновременно с основным кодом представляется мне весьма здравой. Про серьезную отладку забываешь, подавляющее большинство ошибок отпадает сразу же.

[Igel]

Я бы не отбрасывал парное программирование сразу.
Есть опыт, когда я еще и не слышал о всяких штука, как и о экстремальном программировании.
Пришли мы с другом на завод работать, и выделили каждому по компу. Причем я пришел на 30 мин. раньше и мне попался "крутой". Когда нам выдали задание - мы практически делали его за одним компом - за моим.
И действительно за 2 нед. сделали столько и изучили так хорошо, что сравнений нет. Причем не перенапрягались.

[Dimka]

Из своей практики. Когда попадаются нетривиальные задачки, парное программирование продуктивнее одиночного. Тогда один в паре генерирует идеи, а второй критикует и дополняет. В процессе работы роли периодически меняются: когда "генератор идей" больше не может ничего предложить, активным становится второй человек в паре. Причём концентрация внимания на задаче в паре сохраняется лучше, нежели в одиночку, так как в случае кризиса свежих идей благодаря смене ролей не происходит "отключения" от задачи.

У нас на работе в сложных ситуациях несколько человек (из тех, кто "в теме") собираются вокруг "проблемного" разработчика и устраивают мозговой штурм.

Парное программирование - непозволительная роскошь для нетворческих шаблонных задач с известными решениями.

[Alf]

Все равно как-то не доходит до меня идея парного программирования.

Одно дело, когда определяется архитектура нового проекта или модуля. Тут имеет смысл обсудить всей группой, какие будут связи по входам-выходам, какие объекты будут соответствовать сущностям, что в каких потоках выполняется и как синхронизируется и т.д. Но это продуктивнее делать с обычной доской, чем всей толпой за компьютером: не во всяком хозяйстве найдется проектор, да и набросать эскиз на доске быстрее получается. У меня, во всяком случае.

А вот когда доходит очередь до воплощения этих идей в код, тут другое дело. Не представляю, чтобы кто-то пялился в экран за моей спиной и проверял, не забыл ли я где точку с запятой и правильно ли определил границы цикла for. В первом случае мне укажет ошибку компилятор (а в случае использования приличного IDE она будет помечена еще до компиляции, практически мгновенно), во втором я узнаю о ней через несколько минут при прогоне unit-теста. Тем более не представляю себя в роли наблюдателя.

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

Судя по тому, что читал у Бека, парное программирование имеет чрезвычайно мало общего с мозговым штурмом. А у МакКоннелла есть альтернативные варианты коллективной работы, которые представляются мне более привлекательными.

[Igel]

ALF, нуась поподробнее про альтернативные варианты.

[Alf]

Не хотелось бы переписывать целые страницы из книги.  А еще меньше хотелось бы пересказывать в своем изложении, получится как в одесском анекдоте, "Рабинович по телефону напел"... Давай я лучше кину ссылку на книгу, если нет под рукой в бумаге:
http://www.natahaus.ru/2005/09/07/sovershennyy_kod__master_klass.html
(моя особая благодарность Nikedeforest'у за то, что показал мне эту библиотеку; очень хороший выбор книг, и качество сканирования обычно весьма высокое, особенно с учетом таких объемов).

Книга заслуживает того, чтобы прочитать ее от корки до корки; непосредственно же к теме данного разговора относится глава 21, "Совместное конструирование" (стр. 471-489). Предлагаю прочитать, а потом обсудить. Возможно, в новой теме, здесь как-то оффтопом получится.

[Антон (LogRus)]

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

[Alf]

Все равно, как-то трудно абстрактно воспринимается... Можно пример подобной мелкой ошибки, которая нашлась благодаря парной работе?

И еще вопрос - как реально подбираются пары? Стараются объединить наиболее совпадающих по уровню? Или по принципу "учитель-ученик"? Только просьба - не цитаты из Бека, а как сами реально пробовали.

[Антон (LogRus)]

например использование boost::timex в boost::condition::timed_wait предполагает использование абсолютного времени, а не относительного о чем я не знал соотвественно и временное отпускание мьютекса делал не корректно, опять же вопросы дизайна функций.

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

[Антон (LogRus)]

Alf, дело не в дублировании дело в контроле, проще попробовать месяц поработать парами над не слишком критичным проектом, чем рассуждать о за и против.

у меня нет слов в обоснования своей точки зрения.
Что касается того, что ты не можешь представить, как кто-то смотри в твой монитор, так это просто особенность твоей личности.

[Alf]

Что касается того, что ты не можешь представить, как кто-то смотри в твой монитор, так это просто особенность твоей личности.

Я, наверное, не совсем точно выразился.

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

[Антон (LogRus)]

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

где-то в сети видел пару исследований про парное программирование с графиками и т.п. штуками, кажется везде говорилось о том, что польза от парного програмиирования и менно в снижении стоимости поддержки и тестирования при не значительном увеличении стоимости разработки(время разработки увеличивается примерно на 25% после того, как люди адаптируются к работе в паре)

[Igel]

Забыл добавить, что время разработки в общем снижается. В общем - это применение остальных практик ХР.
Да и вообще, сегодня попробовал парное программирование. 3 задачи решили за небольшое время. Так-бы я неделю отдал на разработку, т.к. понимаю, что человек устает, есть практика работчего дня и пр...
В моем случае выводы таковы:
- Ускорение работы за счет организации. Вдвоем за одним компом не особо похалтуришь.
- Вдвоем решать задачи кодирования быстрее получается. Пока смотришь, что человек пишет (все равно у него какая-то часть под моторику занята), уже кучу вариантов разбираешь.
- Да еще практика для менее опытного человека. Хотя это тормозит работу.

[Igel]

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

[Антон (LogRus)]

На счет тестов и документации - не делали ничего. Просто проект уже в стадии. Т.е. документация какая-то уже есть, что-то уже сделано.

Хм. по идее надо сначала тесты потом код.
про документацию: программа хорошо документирована на языке C++

[Alf]

про документацию: программа хорошо документирована на языке C++

Не очень понятен этот пункт... То есть руководство оператора, требования к операционному окружению, описание форматов входных/выходных данных и т.д. забиты в виде комментариев в самом коде? Или используются специальные комментарии XML, подобно Java  и C#, которые потом специальной утилитой можно собрать в виде удобного документа?

[Антон (LogRus)]

Alf, это шутка такая.

[Alf]

Понял, шутка хорошая

А на самом деле документацию пишет та же пара, совещаясь вдвоем?

[Антон (LogRus)]

нет, документацию пишет, сотрудник у которого есть такая задача(согласование ТЗ, draft, request), во время кодирования документация не формируется.

[Alf]

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

[Антон (LogRus)]

Alf, нет ТЗ и прочее пишут разработчики, согласовывают с аналитиками и т.д.
тех.писатели включаются позже, часть документации для клиента готовят тестеры

[Igel]

1. Предлагаю тему отдельную создать. Пусть модератор перенесет то, что про ХР написали.
2. LogRus - только начал, с тестами проблема. В принципе делали диалоги, т.е GUI. Хотя по ходу дела пришлось править и другой модуль. Поэтому собственно вопрос - как делать тесты?
3. Alf, по идее надобность докментации в ХР отрицается, т.к. все  равно окончательный проект не будет соответствовать изложенному в документации. Вторая часть - исходный код с комментариями - для разработчика лучшая документация. Тесное общение разработчиков, смена направлений работы (парное программирование) и пр. позволяют держать в курсе дела всех разработчиков. И если документация используется для того, чтобы проект не заглох из-за текучки кадров, то нужно ее убрать, оставшиеся просто передадут свои знания о системе.
Что там еще было? В дальнейшем документацию можно составить по исходникам, дабы возникнет такая нужда.
Кстати как-то давно видел разработки, которые по исходникам проводили создание технической документации, вплоть до помощи. И даже в одном месте видел внедренную практику внесения стандартизованных комментариев.

[Dimka]

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

Вот наша компания себе позволяет, и я бы не сказал, что этот подход "очень правильный" по следующим соображениям:

1) Технический писатель должен одновременно отлично владеть языком (языками), знать правила составления текстов и в то же время разбираться в том, о чём он пишет.

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

3) Разработка документов по архитектуре выполняется архитектором. Если архитектор будет только думать, а писатель только писать, всё равно необходимо будет наладить между ними взаимодействие, чтобы архитектор сумел объяснить писателю, что от него требуется. В результате часть рабочего времени этой пары будет уходить на коммуникацию. Технический писатель не может иметь квалификацию на уровне архитектора, иначе он бы не работал техническим писателем, или ему пришлось бы платить бОльшую зарплату, нежели архитектору, чтобы удержать на должности. Итого имеем, что разработку проектных документов, описание архитектуры должен выполнять архитектор собственноручно - так будет и быстрее, и надёжнее по содержанию, хотя литературные достоинства такого документа могут страдать.

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

5) Разработка руководств пользователей, файлов справки и т.п. документов, перевод их на разные языки - вот это единственное место приложения технического писателя. И то (из своего опыта) результаты работы требуют контроля со стороны разработчиков, потому что писатель обычно не имеет детальных знаний тех программных систем, которые документирует.

В итоге на должность техписателя-переводчика попадают филологи и т.п. специалисты, которые довольно слабо разбираются в программировании. В то же время у нас есть архитекторы и менеджеры, имеющие второе филологическое образование, но они не будут работать на должности тех.писателя, да и в голову никому не приходит предлагать им такую должность. Просто эти архитекторы используют своё второе образование для составления более качественных документов, чем их коллеги.

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

[Антон (LogRus)]

dimka, согласен

ТЗ у нас составляют те кто называются архитекторами
перед ним есть запрос на разработку от продажников или руководства
техписатели готовят конечную документацию для клиента: описание настроек, help и т.п.

и главное нам не говорят, КАК нам это делать

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

[Alf]

3. Alf, по идее надобность докментации в ХР отрицается, т.к. все  равно окончательный проект не будет соответствовать изложенному в документации.

Я полагаю, тут Бек или сильно лукавит, или неточно изложил свои мысли. Представь себе, ты мне заказываешь софт, я тебе приношу ворох .exe и .dll, возможно, еще и исходники. У тебя возникает масса вопросов: как это все инсталлировать, в какую среду, как настроить, с какими опциями запускать и т.д. А я гордо парирую, что я использую идеологию ХР и посему документацию отрицаю. В крайнем случае читай исходники, их всего-то 30.000 строк, там все прекрасно видно. Вряд ли я после этого у тебя хоть копейку заработаю, да и друзьям накажешь не подпускать меня близко.

Разработчики могут экономить на внутренней документации, особенно если при данной технологии она становится только балластом. Но от внешней никуда не денешься. Я в основном ей интересовался, причем в условиях, когда нет специального отдела документации, ее делают те же разработчики.

[Igel]

LogRus , а примеры можно глянуть?

[Igel]

Я полагаю, тут Бек или сильно лукавит, или неточно изложил свои мысли. Представь себе, ты мне заказываешь софт, я тебе приношу ворох .exe и .dll, возможно, еще и исходники. У тебя возникает масса вопросов: как это все инсталлировать, в какую среду, как настроить, с какими опциями запускать и т.д. А я гордо парирую, что я использую идеологию ХР и посему документацию отрицаю. В крайнем случае читай исходники, их всего-то 30.000 строк, там все прекрасно видно. Вряд ли я после этого у тебя хоть копейку заработаю, да и друзьям накажешь не подпускать меня близко.

В корне неверно. Сопроводительная документация не отрицается. Подразумевается что для создания продукта разработчиками создается куча документации, на которую тратится море сил и времени, а результат этого не стоит.

Разработчики могут экономить на внутренней документации, особенно если при данной технологии она становится только балластом. Но от внешней никуда не денешься. Я в основном ей интересовался, причем в условиях, когда нет специального отдела документации, ее делают те же разработчики.
[/quote]

[Alf]

Хорошо. Допустим. Откатываем транзакцию в исходную точку:

3. Alf, по идее надобность докментации в ХР отрицается...

Мнение Бека:

Хорошим примером являются средства из категории CASE, которые позволяют вам целиком и полностью определять поведение всей системы при помощи графических изображений. Часто эту методику называют генерацией кода (code generation), или автоматической генерацией кода, однако для меня это — язык программирования. В этом случае я возражаю не против картинок, а против попыток хранения одной и той же информации о системе в двух разных синхронизированных между собой представлениях.

(самизнаетеоткуда, стр. 145).

Не видно никакой документофобии, и прослеживается явный намек на UML. Полный отказ от документации - это уже какое-то радикальное течение, экстремизм внути экстремального программирования. Бек так далеко не заходит.

[Igel]

Ну-у, Альф, какая документофобия? Я же написал "по идее". Ежу понятно, что без определенных планов, схем, каких-то ТЗ что-то не сделать. Просто проводится идея - "меньше писанины, больше общения". Т.е. не нужно писать что я должен сделать, когда не знаю что делать.

[Антон (LogRus)]

LogRus , а примеры можно глянуть?

боюсь, что пока нет. не кодю я дома на работе хватает выше крыши. кстати пример чего?
С утра придумаю пример напишу(если не забуду).
кстати в тестах используем boost::test удобная штука.

[Антон (LogRus)]

Igel, о тестах
1. садимся определяем интерфейс класса.
2. пишемем unit_test под интерфейс
пример (использую код из другого сообщения)
тест класса processdata:

Код:

template<class data>
class processdata
{
public:
	template <class indata, class outdata>
	bool doNext(indata i, outdata o);
}

struct test_data
{
	long i;
}

struct testindata
{
	test_data d;
	bool res;
	bool get(test_data& i){ d = i; return res;}
}

struct testoutdata
{
	test_data d;
	bool res;
	void put(test_data& o){ o = d;}
}

int test_main(int argc, _TCHAR* argv[])
{
	test_data d;
	testIndata in;
	testIndata out;
	in.res = true;
	in.d = d;
	processdata p;
	// предполагается, что test_data::i увеличится на еденицу и вернётся значение
	// которое вернул testindata::get
	// проверяем
	BOOST_CHECK_EQUAL (p.doNext(in,out), true);
	BOOST_CHECK_EQUAL (out.d.i, 1);
	// или так, если нельзя просто вывести в cout значени переданные в BOOST_CHECK_EQUAL
	BOOST_CHECK(out.d.i == 1);
	return 0;
}

тест выведет на экран ошибки если они есть и вернёт количество ошибок в коде возврата испольняемого файла теста
это число можно проверить во внешнем скрипте и сформировать отчет
если тест долже прерватся на любой ошибке заменяем BOOST_CHECK_EQUAL на BOOST_REQUIRE_EQUAL c BOOST_CHECK аналогично
можно также просто вывести придупреждение BOOST_WARN_EQUAL и BOOST_WARN