Design patterns

[BOBAH13]

Приветствую.
Стало интересно, как часто какие и в каких задачах Вы используете какие паттерны? Или же вообще не используете?
Так же было бы интересно увидеть кто что читал по паттернам в связки языков C#, Objective C

Edit

да вы стебетесь чтоль

Нет, предлагаете лучше не развиваться?

Edit:
Ух ты, прям тему "как сделать скриншот" создал )) ну пофиг, удалите тогда ее

Edit:
Спасибо

[pproger]

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

да, используем. singleton, observer, adaptor, реже фабрики. читал gof

Нет, предлагаете лучше не развиваться?

предлагаю не пилить по 10 раз одно и то же.

2BOBAH13

Ух ты, прям тему "как сделать скриншот" создал )) ну пофиг, удалите тогда ее

http://programmersforum.ru/showthread.php?t=54347
пожалуйста. там те и примеры, и умл диаграммы. могу еще стопицот ссылок подкинуть с того же хабра. ты спроси, мне не жалко.

[MaTBeu]

В objective-c чаще всего используется делегирование. Реже - синглтоны.

[pu4koff]

Сообщение от BOBAH13

Приветствую.
Стало интересно, как часто какие и в каких задачах Вы используете какие паттерны? Или же вообще не используете?

Я не ставлю перед собой задачу обязательно использовать паттерны. Это хоть и шаблон, но шаблон - не как лекало, по которому нужно всё вырисовывать, а как пример. Нужна транзакционность - можно сделать Единицу работы (Unit of Work). Нужно преобразовывать данные между двумя представлениями вот вам преобразователь данных (Data Mapper). И т.д. Ничто не мешает комбинировать в одном классе несколько паттернов и нет необходимости всё приводить к книжному виду. Это просто набор серебряных пуль, которые всё же нужно затачивать под задачу.

Сообщение от BOBAH13

Так же было бы интересно увидеть кто что читал по паттернам в связки языков C#, Objective C

Ну тут пожалуй из книг только "Фаулер - архитектура корпоративного ПО". Для разработчиков ИС и прочих систем по работе с БД много мыслей в книге. Ответов мало, а после прочтения вопросов будет много. У меня сложилось понимание, что всё я делаю не так, а как надо - не понятно
Тем не менее, считаю книжку достаточно интересной и полезной. Примеры там убогие и бессмысленные, но зато на C# и Java. Именно эта книга толкнула меня к началу более обдуманного проектирования. Раньше проектирование сводилось к разбрасыванию кнопочек по форме и размазыванию логики по всему коду.
Сейчас стараюсь разделять на слои (UI, данные, логика,...), чтобы всё лежало на своём месте и код был понятнее.

[BOBAH13]

Я не ставлю перед собой задачу обязательно использовать паттерны. Это хоть и шаблон, но шаблон - не как лекало, по которому нужно всё вырисовывать, а как пример. Нужна транзакционность - можно сделать Единицу работы (Unit of Work). Нужно преобразовывать данные между двумя представлениями вот вам преобразователь данных (Data Mapper). И т.д. Ничто не мешает комбинировать в одном классе несколько паттернов и нет необходимости всё приводить к книжному виду. Это просто набор серебряных пуль, которые всё же нужно затачивать под задачу.

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

[pu4koff]

Сообщение от BOBAH13

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

Да они на 90% в принципе банальны. Их плюс в более или менее стандартном названии (класс со статическим свойством Instance наверняка реализует паттерн "одиночка" ну и суффиксы factory, facade тоже достаточно прозрачный намек на суть классов дают). Более полезно для меня было описание шаблонов с примерами задач. Почитаешь зачем нужен каждый паттерн и мозг уже начинает работать (в пылу решения задач частенько какие-то нюансы пропускаешь, а тут что-то вроде зарубки остаётся на будущее). Есть некие опорные точки для анализа будущих задач. Взять того же Фаулера и паттерны доступа к данным. Для кого-то DataSet - наше всё и больше человек ничего не знает и в принципе программы работают. А оказывается можно сделать и Active Record и Table Gateway и Data Mapper. При этом прописываются плюсы и минусы каждого из подходов. На базе этого можно уже не только выбирать наиболее подходящее решение для задачи, но и делать какие-то комбинированные версии или какие-то свои модификации. В общем, тут польза больше не из-за того, что готовые детали конструктора в голове будут, а дополнительная пища для мозга подается.
ЗЫ. Это я всё конечно же по себе сужу. Сколько людей, столько и мнений и каждый от паттернов своё берет. Кого хлебом не корми, дай паттерн воткнуть чтобы был, а не потому что реально нужен. Кто-то их использует как детали конструктора, вставляя в код по мере необходимости (без излишнего фанатизма). Ну а кто-то как я, прочитал, тут же забыл половину паттернов и пользуется прочитанным материалом больше как примером анализа задач и их решения.
Собственно самый большой минус паттернов - после их изучения, многие начинают лепить их ни к селу, ни к городу. Примерно как с ООП ситуация (узнал человек про классы и понеслась...).