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

[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% после того, как люди адаптируются к работе в паре)