rpe4aСпасибо за ответы, но все же получается паттерны - это прошлый век или как?Паттерны - это применение принципов ООП на практике. Если будешь правильно применять ООП, то при решении соответствующей задачи у тебя автоматически получится какой-нибудь паттерн, вне зависимости от твоего желания. :-)

Ознакомиться с паттернами полезно. Зубрить их смысла не вижу.

Shocker.Pro... и о существовании EF в вашем проекте может знать лишь РепозиторийЧеловечество пока не определилось, что считать Репозиторием при использовании EF. То ли сам DbContext, то ли что-то другое. :-)

skyANAАлексей Кпропущено...
Человечество пока не определилось, что считать Репозиторием при использовании EF. То ли сам DbContext, то ли что-то другое. :-)Человечество в чём-то не согласно с Фаулером в его определении и описании шаблона Репозиторий? Человечество каждый день меняет своё мнение на диаметрально противоположное. Сегодня какое число?

hVosttАлексей КОзнакомиться с паттернами полезно. Зубрить их смысла не вижу.

Если планируется в дальнейшем работать в команде, то хорошо знать паттерны нужно в обязательном порядке, а не только полезно. Уметь их различать, уметь использовать, уметь определять где, какой и почему паттерн используется. И не впадать в ступор, читая чужой код. Зависит от специфики. При написании банальных LINQ/SQL запросов знание всяких "визиторов" вряд ли поможет.

Большинство распространённых паттернов основано на замене логики полиморфизмом. Умения применять такую замену по назначению вполне достаточно.

kmawпонимать как и почему реализовано у других, и уметь делать также у себя - это не "паттерны", а, как уже замечено, умение писать в ООП-стиле"паттерн" = "умение ООП" + "общепринятые (кем?) названия"

hVosttАлексей КБольшинство распространённых паттернов основано на замене логики полиморфизмом. Умения применять такую замену по назначению вполне достаточно.

Абсолютно в корне не верное утверждение. Все распространённые паттерны являются теоретически подведённой чертой под накопленным опытом, который был обобщён и систематизирован. Не наоборот. Никто не изобретал паттерны, чтоб потом корячиться, дабы воплотить искусственное порождение больного воображения в жизнь. 16404511

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

Точка зрения, основанная на суперпозиции «я хочу и буду делать как хочу, как мне надо в зависимости от того, что и где у меня почесалось», совершенно не уместно при работе в команде. Но вполне подойдёт упоротому нерду, пребывающем в полном одиночестве со своим маленьким гениальным проектиком.В каждой команде разработчиков со временем формируется своя терминология. Учитывая современную культуру программирования в мире, никому доверять нельзя. У меня телевизор дома иногда виснет, перезагружать приходится. Докатились, блеат...

Кто они такие, чтобы я в обязательном порядке пользовался их терминологией? Своей головой надо думать. Удачные термины, которые у всех на слуху, вроде "фабрика", перенимать надо. Но стыдиться собственных терминов бы не стал. Как правило, они ничем не хуже.

Например, возьмём Repository. Дословный перевод: хранилище. Из названия делается вывод: репозитарий не должен содержать логики. Следовательно, логики в LINQ/SQL при таком подходе быть не может. Но так ли это на практике?

hVosttАлексей КВ каждой команде разработчиков со временем формируется своя терминология. Учитывая современную культуру программирования в мире, никому доверять нельзя. У меня телевизор дома иногда виснет, перезагружать приходится. Докатились, блеат...

Что за бред? Представь себе команду хирургов, у которых сформировалась «своя терминология», а затем берут опытного, но другого хирурга. И что теперь? Подумаешь, пару тройку неудачных операций, и чувак вольётся в дружную компашку, начнёт наконец понимать, о чём говорят эти парни.В медицине существует многолетняя устоявшаяся практика, в отличие от IT. Я бы не стал сравнивать эти отрасли.
hVosttАлексей ККто они такие, чтобы я в обязательном порядке пользовался их терминологией? Своей головой надо думать. Удачные термины, которые у всех на слуху, вроде "фабрика", перенимать надо. Но стыдиться собственных терминов бы не стал. Как правило, они ничем не хуже.

Ага. Все говорят, Фабрика, а мне нравится Ферма или Создатель.И что в этом плохого? Главное, чтобы название отражало суть.

Да и никто не использует в общении названия системных паттернов. Детский сад, ей богу... Обсуждения обычно касаются предметной области, её структур данных и логики. А это ER, UML и прочие диаграммы и математические формулы.

зы: вам шашечки или ехать?

hVosttАлексей КИ что в этом плохого? Главное, чтобы название отражало суть.

Если добавить уточнение «понятную всем» суть, то всё станет на свои места.Что в приведённых тобой примерах "Ферма" или "Создатель" может быть всем не понятно? Более того, Creator я уже где-то видел.

В рефлекшене есть родной класс Activator, который мог бы называться Factory. И что теперь, авторам стандартной дотнетной библиотеки убиться об стену из-за чувства вины перед обществом?

hVosttАлексей КВ медицине существует многолетняя устоявшаяся практика, в отличие от IT. Я бы не стал сравнивать эти отрасли.

Ну конечно, конечно... Программное обеспечение и медицина никак не связаны ПО для своего оборудования медики пишут сами.Предлагаю обсуждать суть. Придираться к словам тоже можно, но в разумных пределах. Тем более, что у меня специальность по институту "Медицинские приборы и системы" :-)

hVosttАлексей КВ рефлекшене есть родной класс Activator, который мог бы называться Factory. И что теперь, авторам стандартной дотнетной библиотеки убиться об стену из-за чувства вины перед обществом?

Он так не называется, потому что он не является Фабрикой.Как это? Там все методы CreateXXXInstance. Фабрики бывают не только абстрактными.
hVosttСтандартная библиотека и архитектура проекта... мне кажется мы немного о разных вещах говоримА какая разница?
hVosttСтандартизированная терминология, это основа эффективного взаимодействие.Я не эффективный менеджер. На меня маркетинговые уловки не действуют. У меня к ним иммунитет.
hVosttЗачем тратить время на решение проблем с коммуникаций?Каких проблем? У нас никаких проблем нет.
hVosttЗачем мне забивать голову каким-то бредом на счёт того, что Вася называет Фермой, Петя Пекарней, а я Фабрикой -- это одно и то же?Зачем терять время на изучение сомнительной литературы и навязывание её окружающим? Вася с Петей имеют за плечами кучу успешных проектов и тут появляюсь такой я, и начинаю их учить правильно жить. Зачем мне, как руководителю, это? Меня вполне устраивает их существующий лексикон.
hVosttПочему бы нам просто не пользоваться тем, что есть и решать задачи?А что есть? Я не видел ГОСТ, который регламентирует названия сущностей типовых ООП-моделей. Да и ГОСТ на типовые ООП-модели я тоже не видел.
hVosttКому нравится свобода творчества и бесконечный креатив, не должен суваться в программирование. Есть куча других видов деятельности, где это уместно.Ну я же говорю, обычно обсуждается предметная область. А там совершенно другая терминология. Мы же не операционные системы разрабатываем.

skyANAАлексей КНапример, возьмём Repository. Дословный перевод: хранилище. Из названия делается вывод: репозитарий не должен содержать логики. Следовательно, логики в LINQ/SQL при таком подходе быть не может. Но так ли это на практике?А как на практике? У кого как.

hVosttskyANAВсё это фигня!

Должно быть так:


, а не







Ну и к чему это? Впрочем, принятые, и описанные в документации, сокращения в проекте тоже имеют место быть. Глобальный объект ko в Knockout-е вроде никого не бесит.

skyANAАлексей КВася с Петей имеют за плечами кучу успешных проектов и тут появляюсь такой я, и начинаю их учить правильно жить. Зачем мне, как руководителю, это? Меня вполне устраивает их существующий лексикон.Гы. Вспомнил предисловие к нижке по UML.

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

hVosttАлексей КА что есть? Я не видел ГОСТ, который регламентирует названия сущностей типовых ООП-моделей. Да и ГОСТ на типовые ООП-модели я тоже не видел.

Это правда. И вы не можете программировать на C#, потому что его нет в ГОСТ? На C# есть ECMA-334 и ISO/IEC 23270. Был бы разработан у нас, был бы ГОСТ.

gandjustasАлексей КВася с Петей знакомы с ООП, поэтому всегда найдут общий язык. В конечном итоге, ООП - это тоже паттерн, поддерживаемый на уровне языка.

А если не знакомы, всю нелегкую жизнь писали на лиспе, не найдут общего языка?Но это не ко мне вопрос. Я ведь не сторонник навязывания паттернов.

ViPRosкаждого козла можно замаскировать под любого другого козла, если он не законченный козел (степной)Никаких "если".