И вообще, я бы предложил тебе изучать паттерны GOF в следующей последовательности:
1. Берешь какую нибудь интересную задачу, ну например разбор текстового файла в какой-нибудь, например — xml. Главное чтобы была какая-нибудь функциональная декомпозиция.
2. Реализуешь как умеешь.
3. Читаешь Фаулер "Рефакторинг". Притом первую часть. Сам справочник достаточно бесполезен и ненужен. Обрати внимание, там есть глава, что-то про вонючий код.
4. Рефакторишь программу, убираешь код с запашком.
5. Читаешь Гамму и узнаешь какие паттерны у тебя получились.
После какого-то опыта — паттерны, а точнее правильные решения дизайна, это продукт не сознания, а чисто подсознательный процесс. Его сначала реализуешь, а потом уже думаешь как это называется.
С уважением, Gleb.
Нет опыта полезней, чем опыт собственных ошибок.
(с)Я
Здравствуйте, RagiC, Вы писали:
RC>Нет, никто их специально не придумывает — просто так получилось — в туалет все одинаково ведь ходят — тоже хороший паттерн! Так и здесь.
Ёмко!
И всё-ж таки — хочется как-то почаще юзать и создавать паттерны.
Тем более что работодатели в вакансиях пишут "умение юзать паттерны".
А как научишся не юзая?
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, GlebZ, Вы писали:
GZ>И вообще, я бы предложил тебе изучать паттерны GOF в следующей последовательности: GZ>1. Берешь какую нибудь интересную задачу, ну например разбор текстового файла в какой-нибудь, например — xml. GZ>Главное чтобы была какая-нибудь функциональная декомпозиция. GZ>2. Реализуешь как умеешь. GZ>3. Читаешь Фаулер "Рефакторинг". Притом первую часть. Сам справочник достаточно бесполезен и ненужен. Обрати GZ>внимание, там есть глава, что-то про вонючий код. GZ>4. Рефакторишь программу, убираешь код с запашком. GZ>5. Читаешь Гамму и узнаешь какие паттерны у тебя получились.
Вы могли подробнее рассказать, Гамма — если это кнтга — как она называется?
Если нет — не могли бы Вы конкретизировать.
Хотя, впрочем, если это есть в книге Фаулера — пойму когда прочитаю.
(Простие за ламерский вопрос)
GZ>После какого-то опыта — паттерны, а точнее правильные решения дизайна, это продукт не сознания, а чисто GZ>подсознательный процесс. Его сначала реализуешь, а потом уже думаешь как это называется.
Да.
Это уже чем-то напоминаеи искусство.
В том смысле что в проессе создания кода участвует душа и подсознание. (IMHO)
GZ>С уважением, Gleb. GZ>Нет опыта полезней, чем опыт собственных ошибок. GZ>(с)Я
Здравствуйте, RagiC, Вы писали:
RC>Юзать — юзай, а вот создавать... хорош! И так уж достаточно их развелось — когда ж их изучать-то? Не одними паттернами сыты.
Здравствуйте, RagiC, Вы писали:
RC>Нет, никто их специально не придумывает — просто так получилось — в туалет все одинаково ведь ходят — тоже хороший паттерн! Так и здесь.
Ну кстати — это ёущё вопрос.
Честно говоря я с паттернами не совсем роздуплился ещё.
И всё же рискну предположить что ходить в туалет — скорее инстинкт (то есть — инстинктивая реакция) а не паттерн.
Ведь человек (обычный) просто не можент НЕ ходить в туалет.
А вот паттерном будет например ходить в туалет АККУРАТНО.
Или — каждый раз при посещении туалета СЛИВАТЬ ЗА СОБОЙ ВОДУ.
То есть — действие ОСОЗНАННОЕ.
Кстати — Вы натолкнули меня на очень интересный вопрос.
Кто-то слышал о паттернах поведения (beheviour patterns)?
Они могли бы возникнуть на пересечении психологии и программирования.
Это соответственно может быть связано с программированием собственных (для начала) эмоций и поведения.
P.S. Прошу прощения за оффтопик у тех кому это отклонение от основной темы было неинтересно за отнятое у них время.
Здравствуйте, Dr.Gigabit, Вы писали:
DG>“Design patterns help you learn from others' successes instead of your own failures" (c)Thinking in Patterns by Bruce Eckel
Cпасибо за чёткую формулировку.
Это во многом облегчает разговор.
На RDSN есть форум посвященный проектированию, можно свои гениальные идеи складывать туда Или пиши статьи!
WWW>Конечно. WWW>Но ведь задачи часто повторяются. WWW>IMHO....
Вот именно, задачи повторяются, поэтому надо повторять наиболее удачную их реализацию. В итоге это и будет твоим шаблоном.
WWW>Если не сложно (только если не сложно) — поделитесь решениями. WWW>Интересно.
Самый простой пример — доступ к БД, здесь используется Factory. Создается класс DAOFactory, причем одиночка (Singleton). У него будут свойства в духе IUserDAO, IEntityDAO, ...
IUserDAO — интерфейс, который могут реализовывать различные классы. Смысл — в том, чтобы в DAOFactory в зависимости от текущих настроек выбрать нужный класс, реализующий этот интерфейс. Например
IUserDAO UserDAO
{
get{
if (_userDAO == null)
_userDAO = new MySQLUserDAO(); //Здесь может быть чтение из .config — файла
return _userDAO();
}
}
Factory наверное самый распространенный шаблон. В нашем случае мы легко можем заменить классы доступа к базе MySQL на MSSQL — то есть, получили расширяемое решение.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, vitaly_spb, Вы писали:
WWW>>И всё ж таки — может что-то своё забабахаем?
_>На RDSN есть форум посвященный проектированию, можно свои гениальные идеи складывать туда Или пиши статьи!
WWW>>Конечно. WWW>>Но ведь задачи часто повторяются. WWW>>IMHO....
_>Вот именно, задачи повторяются, поэтому надо повторять наиболее удачную их реализацию. В итоге это и будет твоим шаблоном.
WWW>>Если не сложно (только если не сложно) — поделитесь решениями. WWW>>Интересно.
_>Самый простой пример — доступ к БД, здесь используется Factory. Создается класс DAOFactory, причем одиночка (Singleton). У него будут свойства в духе IUserDAO, IEntityDAO, ...
_>IUserDAO — интерфейс, который могут реализовывать различные классы. Смысл — в том, чтобы в DAOFactory в зависимости от текущих настроек выбрать нужный класс, реализующий этот интерфейс. Например
_>IUserDAO UserDAO _>{ _>get{ _> if (_userDAO == null) _> _userDAO = new MySQLUserDAO(); //Здесь может быть чтение из .config — файла _> return _userDAO(); _>} _>}
_>Factory наверное самый распространенный шаблон. В нашем случае мы легко можем заменить классы доступа к базе MySQL на MSSQL — то есть, получили расширяемое решение.
Здравствуйте, WildWildWind, Вы писали:
WWW>И всё же рискну предположить что ходить в туалет — скорее инстинкт (то есть — инстинктивая реакция) а не паттерн.
Природный паттерн. Реализован у большинства существ одинаково. Во! Даже название придумал — Defecator pattern.
WWW>Ведь человек (обычный) просто не можент НЕ ходить в туалет.
Re[2]: Использование патернов
От:
Аноним
Дата:
23.07.05 12:10
Оценка:
Здравствуйте, Real_Asv, Вы писали:
R_A>Здравствуйте, WildWildWind, Вы писали:
WWW>>Привет!
WWW>>Кто-то использовал паттерны (в частности — проектирования) при проектировании/разработке не очень сложных программ на С#/C++? WWW>>Вообще — насколько полезно/бесполезно их использование? WWW>>Поделитесь, пожалуйста,опытом, как Вы начали применять паттерны / какой был Ваш первый реализованный в программе патерн?
WWW>>Спасибо.
R_A>Существует очень много design patterns...Могу привести примеры которые реально понадобились в моей работе R_A>1) Паттерн Bridge — позволяет гибко отделить интерфейс от его реализации. Применяется даже в VS.NET IDE R_A>2) Паттерн Abstract Factory — создание группы объектов на основе некоторых параметров. R_A>3) Паттерн Provider Model — грубо говоря работа с источником данных независимо от его вида.
R_A>Более подробно — в инете море информации и примеров..
R_A>От себя скромно добавлю — паттерны очень полезная штука, если надо могу скинуть примеры кода который применялся в реальных приложениях.
Думаю, что все их используют, только не все знают об этом.
Это полезно в той же степени, в которой полезно изучать и применять лучший чужой опыт, а не корячиться изобретать свой собственный (но такой же) велосипед.
Первый шаблон, который я применил (тогда я о том не знал, что так оно называется — студентом был), назывался Фабрика_Классов. А было это 11 (уже...) лет назад
Здравствуйте, Real_Asv, Вы писали:
R_A>Здравствуйте, WildWildWind, Вы писали:
WWW>>Привет!
WWW>>Кто-то использовал паттерны (в частности — проектирования) при проектировании/разработке не очень сложных программ на С#/C++? WWW>>Вообще — насколько полезно/бесполезно их использование? WWW>>Поделитесь, пожалуйста,опытом, как Вы начали применять паттерны / какой был Ваш первый реализованный в программе патерн?
WWW>>Спасибо.
R_A>Существует очень много design patterns...Могу привести примеры которые реально понадобились в моей работе R_A>1) Паттерн Bridge — позволяет гибко отделить интерфейс от его реализации. Применяется даже в VS.NET IDE R_A>2) Паттерн Abstract Factory — создание группы объектов на основе некоторых параметров. R_A>3) Паттерн Provider Model — грубо говоря работа с источником данных независимо от его вида.
R_A>Более подробно — в инете море информации и примеров..
R_A>От себя скромно добавлю — паттерны очень полезная штука, если надо могу скинуть примеры кода который применялся в реальных приложениях.
Здравствуйте, WildWildWind, Вы писали:
WWW>Кто-то использовал паттерны (в частности — проектирования) при проектировании/разработке не очень сложных программ на С#/C++?
Паттерны не "используют". Паттерны — реализуют. Хотя, можно сказать, что "использовано описание паттерна" или "использована библиотечная реализация паттерна такого-то".
Поэтому, кстати, бессмысленно жонглировать выражениями типа: "А какой тут паттерн использовать?"
WWW>Вообще — насколько полезно/бесполезно их использование?
Совершенно бесполезно. Полезно понимать — что, зачем и почему.
WWW>Поделитесь, пожалуйста,опытом, как Вы начали применять паттерны / какой был Ваш первый реализованный в программе патерн?
Устойчивые методы решения задач похожей структуры (паттерны, собственно) выделяются разработчиком где-то ко второму случаю появления похожей задачи. Или после глубоко осмысления первого случая столкновения с задачей. Паттерны могут быть у каждого своими, а могут и оказаться похожими на те, что описаны у GoF.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WildWildWind, Вы писали:
WWW>Привет!
WWW>Кто-то использовал паттерны (в частности — проектирования) при проектировании/разработке не очень сложных программ на С#/C++?
Например, каждый, кто писал на MFC, использовал паттерн MVC (Model-View-Controller) — он просто встроен в framework.
И так уж достаточно их развелось — когда ж их изучать-то? Не одними паттернами сыты.
Паттерны могут быть у каждого своими, а могут и оказаться похожими на те, что описаны у GoF.
