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

Спасибо.

К сожалению, пока: 1. нет 2. нет.

Знаком. 
Если нахожу место применения -- очен радуюсь и применяю 
По большому счету да.

А вообще, ИМХО, у меня очень мало опыта и я не особо видел хорошо спроектированных проектов. Мой текущий вообще "обошелся" без стадии проектирования, вот теперь я и страдаю.
Единственный паттерн с которым я на ты --- это одиночка, singleton

Аналогично. Иногда использую фабрики. Щас как раз читаю про то как находить места применения паттернов.

Спасибо за ответы!

Я вот прямо сейчас изучаю их   Так что пока затрудняюсь на вышепоставленный вопрос ответить  

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

Использую, так сказать, по мере умения.

Безграмотно спроектированный проект - это ужос для заказчика (потом его развивать, дополнять и поддерживать). Способ проектирования от mr.DUDA -- тщательно продумать каждую мелочь, а потом забить на это и сделать всё как можно проще.   

О, даже мистер Дуда не обходиться без предварительного проектирования 

Приходится.

Хотя никакими визуальными тулзами не пользуюсь принципиально, всё - в голове.   

Видимо еще не случалось таких обстоятельств, где они были бы востребованы.

Для себя представляю только такую ситуацию: когда проектированием занимается один человек, а разработкой - другие, тогда  востребованы визуальные средства -- Visio, Rose, и т.п.

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

Крупный и серьезный проект ты не напишешь, если не будешь следовать методике. 

Потому в них и появилась потребность, что сложность разработки постоянно росла.

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

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

ООП пользуюсь постоянно. На паттерны постепенно перехожу, так как это полезная штука в больших проектах.

UML - рулит. UML может и забирать дополнительно времени на этапах формирования требований и проектирования, но существенно экономит Ваше время на доработку на этапах реализации, тестирования и внедрения.

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

Потома я себе купил книженцию по UML, на рынке их немеряно - изданий и переизданий от создателей UML (БУЧа, РАМБО и ЯКОБСОНа). Сначала каша - так как днем решаеш одну проблему, а вечерами - почитуеш книгу,  не просто книгу...
... как на как отдельный язык, правда моделирования, но как говорили создатели "С" - Б.Керниган и Д.Ричи - "единственный способ изучить язык программирования - это писать на нем програми"....

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

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

Дерзайте UML  - это вещь  

Я сам не использую UML. Было бы интересно начать.
Может кто подскажет есть ли бесплатное программное обеспечение для UML проектирования?

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

LostAlly, лови неплохой бесплатный, на .Net писанный UML редактор: http://staruml.sourceforge.net/en/

Кстати хотелось бы проголосовать за паттерны. Недавно стал знакомиться с этим методом ООП, достаточно неплохо развивает...   

По этому поводу добавлю хороший источник  ->  Э.Гамма, Э.Хелм и др.  Приемы объектно-ориентированного проектирования паттерны проектирования.

Недавно прочитал книгу "Экстремальное программирование" Кент Бек, которая очень понравилась. Помаленку пытаюсь использовать описанные там приципы. Интересно было бы услышать мнение тех, кто использовал UML, паттерны и XP. Что-то вроде сравнительного анализа.
Заранее спасибо.

deviLoper, а дай ссылочку на книжку

http://dl.kruzzz.com/files/1225/programm/etc/extr_prog.pdf

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

А вот на проектах небольших едва ли стоит сильно заморачиваться на проектировании... Бери и пиши... 

15892, не модифицировать?? я таких проектов не встречал ни разу!

аналогично - даже самый мегаконечный продукт через определенное время - выпадает из времени (блин кругом тафталогия) - любой проект дорабатываеться, перерабатывается или просто уходит в никуда, но что чаще бывает кода продукт реально качественный то модифичировать приходиться через достаточно долгий промежуток времени кога уже всё забыл ВОТ ТОГДА и думаеш про проектирование, тем более, как часто бывает, набрался опыта: хочеш, видеш и приступаеш к оптимизации  

скоро благодаря мелкомягким будем делать мега проекты нескольками кликами с объемом по несколько гигов  

Содержание поста не соответствует смыслу топика.

мне понравилось одно высказывание, точно не помню чье:
что-то вроде того что сначала когда вы начинаете знакомится с паттернами вам все это нравится,
потом начинаете пытаться применять, потом понимаете, что они полностью бесполезны и бросаете эту затею, и в конце концов ловите себя на том, что все-таки используете их

izekia, если точнее, это сказал Грег Ирвин, и звучало оно так:





А вообще, я сейчас стараюсь совмещать небольшое проектирование на основе модели предметной области, TDD и рефакторинг -- очень нравится, гораздо эффективнее всё получается.

Это классика. К прочтению обязательна.

А еще, если к этому прикрутить Design Patterns вообще вещь получается.
Рекомендую по этому поводу книженцию Джошуа Кириевски "Рефакторинг с использованием шаблонов".

UML Применяю всегда. Design Patterns всегда. А если мой работодатель хочет Fast & Dirty то пусть ищет другого программиста.

ООП из книге "Для профессионалов .NET 3.0" - http://depositfiles.com/files/4594993

Я сейчас нахожусь в этой стадии  Оставил только самые простые паттерны.
И больше обращаю внимание на бестпрактики, чем на паттерны.

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

Мое мнение: 
рекомендуя эту книгу человеку  не знакому с паттернами я бы все же изъял некоторые из них, которые часто неправильно понимаются и как следствие используются не там где надо, что больше усложняет код чем наоборот :( 

К таким могу отнести:
Мост (Bridge) про этот паттерн до сих пор спорят архитекторы и не могут приди к единому мнению -- в сад!
Строитель (Builder) сам не использовал -- не сталкивался с объектами требующими сложного конструирования.
]Комманда -- в большинстве случаев приводит к усложнению кода
Но в случаях когда она действительна нужна она незаменима, только вот трудновато новичку их определить. Я благодарин моему другу, что он отговорил меня его использовать в моем проекте (а было ох какое желание и тогда я думал, что он очень грамотно ложиться на задачу).
Цепочка обязанностей (Chain of Responsibility) -- см. команда, только попроще распознать нужен ли он тебе.
... 
Дописал до сих пор и понял, что все эти паттерны (кроме Моста, этот вообще жесть -- запутаться в нем раз плюнуть) при использовании не к месту всегда приводят к усложнению кода. Т.о. самая главная задача определить -- а оно тебе надо? Поэтому начинающему архитектору лучше о них не знать 

Продолжу перечисление:
Компоновщик (Composite), Интерпретатор (пример сложного паттерна, но его врятли начинающий рискнет использовать), Медиатор (лучше сразу MVC, MVP...), Посетитель (Visitor).

В противовес, паттерны которые должен знать каждый! разработчик:
Адаптер, Фасад, Итератор (хотя и встроен в современные языки, многи не понимают что это и зачем), Хранитель (Memento), Наблюдатель (Observer) (грамотно реализован в .Net с поможью событий), Синглтон, Состояние (State), 

Более сложные (знать не обязательно, но желательно): 
Фабричный метод, Декоратор, Прокси (Proxy)


Вот такое мое ИХМО.

Это сообщение отредактировал(а) ivashkanet - 11.4.2008, 09:17

Еще раз подчеркну:

Билдер можно использовать тогда, когда нужно построить объекты одного класса, но с разными значениями свойств. Например, если есть класс пакетов протокола, в которых все поля одинаковы, но имеют разные значения в зависимости от задач пакета, то наследование здесь будет лишне. С другой стороны, если полей такиx много, то стоит взвесить целесообразность билдера. Т.е. вместо:

У меня как раз Command всегда все упрощал. Это хороший способ инкапсулировать все, что относится к одному действию. Кроме того, этот паттерн позволяет строить иерархию комманд (Composite) или под-команды (когда одно действие состоит из нескольких более простых действий).

Добавлено через 2 минуты и 34 секунды

По-сути любая иерархичная структура реализует этот паттерн.

Хороший пример использования - обход дерева файлов проекта при компиляции.

Добавлено через 6 минут и 37 секунд

Извините, этo я погорячился.

firstone, Перечитай мой пост. Все паттерны упрощают разработку, если используются к месту. А использование их не к месту все только усложныет. 
И очень часто тяжело понять нужен он или нет, вот про это я и говорл.

И ты считаешь это не сложный пример?

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

ivashkanet, Во всем согласен. Простo я не в том ключе прочитал Ваш пост.

Добавлю  свое ИМХО по аналогии Вашего.

Должны знать: Factory, Factory method, Decorator, Adapter, Facade, Iterator, Proxy, Command, Memento, Observer, Composite, Mediator(?)

Необязательно: Chain of responsibility, Bridge, Builder, Visitor, (Mediator)


Собственно, Mediator - слишком пространственный паттерн. Наверняка его применяли все, простo не давали себе в этом отчет.

А вот и не правда  Для этого случая больше подходит прототип (один из обязательных паттернов).

А билдер нужен тогда, когда нужно создать один объект, но создавать его можно из разных источников.

В ГоФ-е дают пример про RTF документ, который билдиться из разных источников: обычного текста, TeX-файла, ...

Добавлено через 13 минут и 32 секунды
И еще, немного пересмотрел свой список (  ) исключив из него сложные паттерны, но которые тяжело использовать не там где надо 
Это например Компоновщик (Composite). О нем хорошо бы просто знать.
Потому что для работы с графикой (нарисовать три линии, квадратик, а внурти треугольник  ) он нужен просто как воздух.

Все же позвольте мне с Вами не согласиться.

В моем примере prototype и builder одинаково применимы. Я считаю, что билдер подходит больше из-за полного отсутствия разницы между классами. Потом некоторый customizing объектов все же необходим, так что после Clone()-а все равно надо будет менять какие-то свойстава. Хотя в обшем и прототип тут тоже сойдет и фактори. 

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

Согласен. Правда бывает, увлечешься этими паттернами, что и забудешь что вообще ты пытаешься ими решить 

Читаю статью Фаулера про проектирование в XP  и нарвался на такую фразу:


Это сообщение отредактировал(а) ivashkanet - 14.4.2008, 15:47

Анти-паттерн

Хорошая статья: Переход к шаблонам

Есть ли у кого рабочий пример паттерена МVC под WinForms?

При реализации MVC в WinForms есть определённые сложности. В .NET отсутствует чёткое разделение между Представлением и Контроллером. По сему приходиться реализовывать дополнительные паттерны - Mediator или Observer. (поправте меня если я ошибаюсь). По-этому хотелось бы узнать мнение о реализации данного паттерна  

Для общего ознакомления:
http://www.rsdn.ru/article/patterns/ModelViewPresenter.xml
http://www.rsdn.ru/article/patterns/generic-mvc.xml 

http://www.rsdn.ru/article/patterns/ModelViewPresenter.xml
В етой статье код не рабочий. В интерфесе обьявлены методы а в класе автор реализует свойства.

AdrenalinHunter, 
1) MVC -- это не один какой-то паттерн, а целое семейство паттернов. Какой из них тебя интеерсует?
2) Четкое разделение между представлением и контроллером либо присутствует, либо нет. И это совершенно безотносительно к .Net 
3) Код формы в WinForms -- чистый паттерн Mediator.
4) Обсервер -- встроен в C# (механизм событий)
5) Форма (контролы + медиатор) -- это V (View) из MVC 

Если интересует, как правильно применять паттерны в своих проектах, то есть замечательная библиотека от МS - Smart Client Software Factory

Вот описание на русском http://www.compress.ru/article.aspx?id=17281&iid=799

Когда я только познакомился с паттернами, я понял, что это великолепная  штука. Вот только никак подступиться по началу не мог, чувствовалась нехватка опыта непосредственного применения их в проектах. 

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

Это сообщение отредактировал(а) Medved - 6.7.2009, 21:33

Medved, а есть аналоги или бесплатные варианты для Express версий? Может приходилось сталкиваться?

Доброго времени суток! Уважаемые, нужен совет бывалого программиста 

Наверное вопрос не в тему,- сорри((

В общем, я хочу попытаться освоить C#, но есть некоторые нюансы и вопросы. Итак..
 1) С чего лучше всего начать? (Легко усваиваемая литература (для новичка), каким образом организовывать практикум (построение алгоритмов-> консольные приложения->..)) В общем все для полного нуба
 2) Сложно ли освоить С# без знания C/C++, и имея знания и практику по программированию и алгоритмизации на 3 с минусом Может рано я берусь за это..
 3) Какую среду разработки использовать для начала (сейчас осваиваю MSVC# 2008 EE)? Возможно для начала нужно что-то попроще?
 4) Какое Ваше мнение об C# и .NET платформе в общем? Перспективность, сложность изучения и т.д.?
 5) Кроссплатформенность, универсальность и т.п.
 6) Достоинства и недостатки данного языка и платформы в целом?
 7) Можно ли создавать на C# приложения работающие без .Net Framework'а?


Спасибо за внимания и ответы  Буду рад любым комментариям 

P.S. Извиняюсь, если вопросы задаю непонятно/некорректно..

Это сообщение отредактировал(а) mozgabyte - 10.10.2009, 21:29

?


1. Поставь перед собой задачу, конкретную задачу - написать например какое-нибдуь полноценное приложение. Не важно какое, плеер, текстовый редактор, личная БД, все что угодно, и уделяй этому время. Вот и все. Никаих секретов тут нет. Можно взять какое-нибудь учебное пособие, где идет обучение языку на примере построенния какого-нибудь учебного приложения. Это будет лучше всего.
Что-то конкретное из литературы посоветывать не могу, так как не слежу за книгами по этой тематике. Мне достаточно MSDN.
2. Для изучения С# знать С/С++ не обязательно. Это совершенно разные языки программирования. Хотя в чем-то синтаксис и похож. 
3. Ну раз уж ты пишешь в этом форуме, то рекомендую MS Visual Studio 2008 SP1.
4. Переспективная технология. Сложность - понятие относительне. Решил изучать эту платформу - изучай, не проградаешь. ИМХО.
5. Кросплатформенность официально отсутствует. Есть возможность запускать на Linux через неофициальный проект Mono. В данном случае прямой конкурент .NET - Java более предпочтительнее.
6. http://blog.nguen.net/post33-good_bad_plus...us_dot_net.html
7. Нет, без  Framework'а приложение работать не будет. Но это и не столь важно, практически у каждого пользователя уже присутствует этот пакет.

Это сообщение отредактировал(а) Medved - 10.10.2009, 22:54

Medved, спасибо за ответы  

Изучению UML у меня в инсте целый семестр отводится. Очень интересная штука, если разобраться=)

Хвост топика выделен в Процесс и инструменты для разработки

Иногда использую. 

Вообще, нас в вузе не так давно научили Rational Rose, но я сразу же ощутил всю прелесть - когда зараннее разрабатываешь класс на бумажке (ну там - в проекте), а потом генерируешь код. Так намного удобнее, можно сразу продумать логику взаимосвязи классов, как они между собой взаимодействуют. Особенно полезно, когда классов очень много - просто куче кода, без визуализации, очень легко запутаться. 

Поэтому еще иногда полезно использовать обрантый инженеринг - когда из кучи классов программка рисует красивую схемку. Кто программирует на Java в среде NetBeans, могут знать, что к среде есть достаточно неплохой модуль поддержки UML. Я им пользуюсь, полезная штука. http://netbeans.org/features/uml/

Использование методологий объектного моделирования и графического описания != использование паттернов.
Знаю основы, использовал пару раз за 5 лет самообучения, т.к. считаю что паттерны должны использоваться только если программист на 100% понимает что он делает, а для этого, по большому счету, до всех паттернов нужно дойти самому.
То что паттерн можно применить не значит, что он должен быть применен.

"Есть мнение, что слепое применение шаблонов из справочника, без осмысления причин и предпосылок выделения каждого отдельного шаблона, замедляет профессиональный рост программиста, так как подменяет творческую работу механической подстановкой шаблонов. Люди, придерживающиеся данного мнения, считают, что знакомиться со списками шаблонов необходимо тогда, когда программист «дорос» до них в профессиональном плане — и не раньше. Хороший критерий нужной степени профессионализма — выделение шаблонов самостоятельно, на основании собственного опыта. При этом, разумеется, знакомство с теорией, связанной с шаблонами, полезно на любом уровне профессионализма и направляет развитие программиста в правильную сторону. Сомнению подвергается только использование шаблонов «по справочнику»." ©Wikipedia.org

Что там учить в Uml? Достаточно беглого прочтения информации с википедии по любому типу диаграмм.
Считаю реально полезной и ходовой диаграмму классов, остальные только по праздникам(хотя Use-case человечки и доставляют)
Все тулзы по рисованию Uml, с которыми я работал, откровенно кривые(и я в поиске до сих пор). По времени на рисование соизмеримо с работой в пейнте.
Старая добрая бумага куда лучше.

Я диаграммы использую, но наоборот. Т.е. стараюсь динамично с использованием TDD разрабатывать. Скорость разработки в разы выше, чем у колег, которые вроде и опытные, а не пользуются такими вещами. Я противник предварительного создания архитектуры. Приходят требования, архитектура сама рождается. Когда набъете руку, то всего лишь пара интуитивных правил помогает создавать архитектуру на ходу. Я бы назвал эти правила:
1. Нахождение общего. Вынос в базовый класс. Или вынос в отдельный метод
2. Нахождение различий. Вынос в потомков.
3. Избегать любым способом дублирование данных. Для этого минимизировать как только возможно состояние объектов. Желательно, чтобы они вообще почти не имели состояния, а всё перевычислялось. Избегаем сайд-эффектов. Приближаемся к функциональному программированию. Если же потом не устраивает производительность, то просто в такую архитектуру добавляется кеширование.

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

На счет сложности проектов и предварительной архитектуры. Что-то не было на моей памяти мегасложных проектов на шарпе. Все архитектурные решения для бизнес-проектов - уже настолько давно всем известны, что набили оскомину. Поэтому каркас просто берется готовый, а далее TDD. Юнит-тестирование и рефакторинг - рулят. При этом UML и диаграммы не рисую, потому как считаю потерянным временем. Нарисовать диаграмму - это почти уже задать логику. Тогда зачем два раза это делать? Потом, если диаграммы рисуются до начала кодирования, сто процентов, будут еще куча изменений в требованиях и куча всего, что "не учли". Опять перерисовывать. А не дай бог еще кто-то увидит эту диаграмму. Тогда перерисовка ее сразу же обязывает согласовывать с другими, кто уже видел и запомнил, как оно собиралось быть внедрено.
Короче - куча лишних бессмысленных телодвижений. Когда как с опытом понимаешь, что для любой задачи уже есть архитектура и нормальная архитектура только одна. Нечего здесь креативить. Креативят новички.

Но диаграммы все таки рисую, но в конце. Т.е. когда уже сформировался проект и уже есть решение, нужно в конце документировать. Чтобы была документация и можно было передавать другим людям код.

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

http://www.ozon.ru/context/detail/id/2457392/ может.

Книгу  94 года? Нет, спасибо

А что не так? Принципы, лежащие в основе паттернов, с тех пор не изменились.
 Вообще, для изучения я бы рекомендовал эту http://www.ozon.ru/context/detail/id/6108824/ Но в ней точно такие же паттерны, как и в GOF.