Знакомы ли в с объектно-ориентированным проектированием и UML? 
Используете ли вы паттерны в своих проектах?
Помогают ли они вам в ваших программах?

Спасибо.

Использую иногда, когда менеджеры проекта чуть слабее ограничивают по срокам и бюджетам. Обычно это в случае каких-либо сложных именно новых модулей. Далее ИМХО. Примнение такого проектирования для старых модулей не целесообразно, т.к. в большинстве случаев там даже джавадоков нету... ИМХО, все упирается в культуру,  техпроцесс и бюджеты. Если проограммистов постоянно пинать, чтобы код следовал конвеншенсам, чтобы писали юниттесты, чтобы писали джавадоки, а диаграммы и схемы проекта всегда содержались бы в актуальном состоянии - тогда, да, имеет смысл постоянно использовать такой подход к проектированию. В остальных случаях, это надо делать только там, где с помощью него действительно удобно девелоперить...

Это сообщение отредактировал(а) y3u - 22.3.2007, 13:51

Вспомнил ситуацию. Директор фирмы в которой я однов ремя работал, ездил в коммандировку в Ростов. Там ребята написали какой-то софт, и просили за него баснасловные деньги. Директор когда узнал сколько, просто офигел...   

Спросил а чем обусловлена такая цена. А те ответили: "Наш софт написан по всем стандартам".
Потом он приехал к нам из командировки, и начал требовать, чтобы мы начали изучать эти стандарты. Собственно именно тогда я и познакомился с этой тематикой. А до этого писал на Дельфи так - тыкнул кнопку, написал обработчик, довольный...хорошо... (голосом Бората) 

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

ИМХО. Обьектный подход удобен гораздо чаще, чем неудобен, но бывают случаи (а может и целые области, которых я не знаю), когда без обьектов проще и быстрее.

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

я бы еще понял если бы опрос был по аспектно-ориентированному программированию... тут действительно tastes differ. но ооп... странный опрос   

Имхо -- гарантирует, как минимум одни класс для main -- нужен   

Читайте пожалуйста внимательнее!
Я говорю о ПРОЕКТИРОВАНИИ и АНАЛИЗЕ. UML, паттерны, диаграммы и т.п.

Medved

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

Вы знаете, бывает что как-то обходяться. Правда себе потом дороже выходит.

Добавлено @ 20:44 


Ээээ.. это как? 

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

Ммм.. сорри, прочел только шапку, без первого поста. Отвечу по пунктам   

• Использую. Пришел в Java именно за этим и в восторге от реализации маниакально стараюсь обобъектить все и вся.   
• Знаком + клиенты требуют technical design documents с обязательным наличинем UML-диаграмм на все ключевые вещи.   
• Использование паттернов было частым, но несколько фрагментарным до того момента, пока не пришлось писать собственный фреймворк, на базе которого разрабатывется около десятка схожих приложений. Только в этом процессе осознал суть и соль..     уверен, что не до конца и для открытий место осталось.
• Мой код не существует без описанного выше.

Леоненков. Самоучитель UML.

Специализируюсь на объектно-ориентированных системах, поэтому хотел бы высказать несколько идей.

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

Шаблоны улучшают проект при наличии трех основополагающих: знание самих шаблонов разработчиками, понимание причин применения шаблонов и способ применения шаблонов. Зачастую достичь всех трех условий в рамках конкретного проекта и команды разработчиков нельзя. Лучший способ использования паттернов проектирования - не использовать их вообще, пока вы не возникает ситуация, когда без них не обойтись и в которой они приносят реальную выгоду. Сами по себе шаблоны не решают проблем проектирования и не являются повторно используемым кодом (Бертранд Мейер "Объектно-ориентированное конструирование систем"). Изучение шаблонов полезно для развития навыков написания "правильного" (что в первую очередь обозначает понятного) кода, но использование шаблонов не есть самоцель.

UML очень мощное средство, но опять возникает проблема, что большинство разработчиков владеют только азами этого языка и попытка представить структуру на 3-х 4-х связанных диаграммах может только замедлить проект, а не улучшить взаимодействие. Поэтому использование UML зачастую разумно ограничить только начальным уровнем (например, брошюры Кэндалла Скотта).

Вообще ОО проектирование, шаблоны, UML (а также рефакторинг) нужно рассматривать как отдельные вопросы (а еще лучше как конкретные вопросы), иначе можно просто бесконечно говорить о наборе абстрактных вещей.

Паттерны рулят, антипаттерны еще больше   UML + генерация кода из него тоже ... Это всё у нас теперь в обязательной программе обучения...   

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

Кстати есть еще одна крутая вещь которая стоит рядом с software quality, unit тестами, итд... это Software measurement ...

COCOMO Model
Lines of Code
Function point analysis (на немецком)

Это сообщение отредактировал(а) Гарри - 7.6.2007, 12:34

Ну, количество строк кода (и другие подобные параметры) - штука довольно глупая, имхо. А всё потому, что хороший софт не обязан иметь минимальное или максимальное число строк кода. Он обязан, в первую очередь, хорошо работать. Быстро, стабильно и удобно.  
В целом по шаблонам почти согласен с adLucem - надо головой думать, нужен шаблон в данном месте или нет. Мне, например, из подходов к разработке очень нравится идея экстремального программирования. Только вот в полной мере она подходит далеко не для всех ситуаций. Часть идей можно использовать почти везде, но в целом - не так уж и часто. То же самое и с шаблонами.