После долгих лет изучения ООП/ООД возникло-таки желание почитать о нём какую-то книжку Очень хочется, чтобы там было:
1. Откуда взялось слово "factory" и что ещё бывает оттуда же. Интересно, что у GoF есть только Abstract Factory, а просто Factory нету. Откуда оно взялось?
2. Откуда взялось слово "service" и что ещё бывает оттуда же. Предположу, что где-то там же должны быть описаны термины rich domain model и anemic domain model.
3. Рассказ про MVC с попытками однозначно его интерпретировать.
4. Рассказ про SOLID, GRASP и что ещё бывает такого.
Посоветуйте пожалуйста.
Re: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, andyag, Вы писали:
A>После долгих лет изучения ООП/ООД возникло-таки желание почитать о нём какую-то книжку Очень хочется, чтобы там было:
A>1. Откуда взялось слово "factory" и что ещё бывает оттуда же. Интересно, что у GoF есть только Abstract Factory, а просто Factory нету. Откуда оно взялось? A>2. Откуда взялось слово "service" и что ещё бывает оттуда же. Предположу, что где-то там же должны быть описаны термины rich domain model и anemic domain model. A>3. Рассказ про MVC с попытками однозначно его интерпретировать. A>4. Рассказ про SOLID, GRASP и что ещё бывает такого.
A>Посоветуйте пожалуйста.
Factory — это обобщение Factory Method\Abstract Factory из GOF, особую популярность паттерн получил в среде Java, где фабрику обозначали посфиксом в названии, чтобы не писать лишних слов. Если постфикс в названии класса, то это abstract factory, а если в названии метода, то factory method.
Здравствуйте, andyag, Вы писали:
A>После долгих лет изучения ООП/ООД возникло-таки желание почитать о нём какую-то книжку Очень хочется, чтобы там было:
Я не понимаю вообще. Зачем знать баззворды? Лучше какие-то более фундаментальные вещи. ИМХО.
... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 67>>
Re[2]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, romangr, Вы писали:
R>Здравствуйте, andyag, Вы писали:
A>>После долгих лет изучения ООП/ООД возникло-таки желание почитать о нём какую-то книжку Очень хочется, чтобы там было:
R>Я не понимаю вообще. Зачем знать баззворды? Лучше какие-то более фундаментальные вещи. ИМХО.
Фундаментальные вещи — это что например?
Re[3]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, andyag, Вы писали:
A>Фундаментальные вещи — это что например?
Для явы — . Она по-моему безнадёжно пропитана паттернами.
Для дотнета самый лучший использовать паттерны — не вспоминать про них вовсе. Гораздо полезней изучить Рихтера и Framework Design Guidelines. Ну и не забывать про здравый смысл и знание матчасти, но это уже общий рецепт.
Здравствуйте, LaptevVV, Вы писали:
LVV>То есть это все говорит, что нужно писать единую книжку.
LVV>Кто б из наших гуру занялся бы, а? LVV>А я б редактировал.
Данунафиг, неблагодарное это занятие.
Re[4]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, LaptevVV, Вы писали:
LVV>>То есть это все говорит, что нужно писать единую книжку.
LVV>>Кто б из наших гуру занялся бы, а? LVV>>А я б редактировал.
G>Данунафиг, неблагодарное это занятие.
Смотря что считать за пользу.
Писавшему — польза. Например, проясняются не совсем понятные моменты.
Опять же, если надо будет потом кому-то рассказывать, то формулировки уже будут отточены.
Денег — да, мало.
Но зато известность и репутация — а это часто стОит больших денег...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, andyag, Вы писали:
A>Фундаментальные вещи — это что например?
Фундаментальные вещи — это декомпозиция и композиция. То есть нужно уметь делить большую задачу на маленькие кусочки, которые максимально эффективно решаются средствами того языка и платформы, на которой ты работаешь, а потом собирать из этих кусочков готовое решение и встраивать его в приложение.
Например для ООП основа почти всех паттернов это выделение интерфейсов и рекурсивная композиция.
В ФЯ вариантов гораздо больше, там и ФВП, и монады, и комбинаторы, и пайплайн.
Re[4]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, andyag, Вы писали:
A>>Фундаментальные вещи — это что например?
G>Фундаментальные вещи — это декомпозиция и композиция. То есть нужно уметь делить большую задачу на маленькие кусочки, которые максимально эффективно решаются средствами того языка и платформы, на которой ты работаешь, а потом собирать из этих кусочков готовое решение и встраивать его в приложение.
Так паттерны как раз и посвящены композиции и декомпозиции. Паттерны в первую очередь описывают ситуацию, где есть как минимум 2 участника, каждый со своими интересами, и нужно каким-то образом их подружить. На реализацию дружбы накладываются какие-то дополнительные ограничения, а исходя из этих ограничений предлагается _подход_ к реализации. В разных языках реализация может требовать больше или меньше кода, но с точки зрения подхода, с точки зрения выделенных компонентов и связей между ними всегда будет одно и то же. Если взять тот же Observer из GoF:
1. В Java нужно будет написать интерфейс IObserver, чтобы выделить компонент "Observer", а уведомляющему классу добавить методы типа subscribe/unsubscribe, чтобы выделить компонент "Subject".
2. В .NET всё то же самое — предлагается выделить Observer и Subject, но в языке есть средства, которые позволяют обойтись без введения штук типа IObserver, а просто взять и использовать готовый инструмент — делагаты/события.
В обоих случаях участники и связи между ними одни и те же, но технически решения отличаются: просто в Java единственный подходящий инструмент — это интерфейсы и классы, а в .NET есть более подходящий инструмент — events/delegates.
ИМХО, вся фишка паттернов в том, что программист может оперировать "стереотипными пачками объектов", а не отдельными объектами — никакой более высокой цели. У меня в принципе нет никакого желания спорить о нужности или ненужности всех этих знаний — просто хочется почитать нечто по сравнительно конкретным темам
Re[4]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, andyag, Вы писали:
A>>Фундаментальные вещи — это что например?
S>Для явы — . Она по-моему безнадёжно пропитана паттернами. S>Для дотнета самый лучший использовать паттерны — не вспоминать про них вовсе.
Есть какая-то принципиальная разница между Java и .NET, из-за которой подход к программированию принципиально отличается? Мне правда интересно.
S>Гораздо полезней изучить Рихтера и Framework Design Guidelines. Ну и не забывать про здравый смысл и знание матчасти, но это уже общий рецепт.
Тут возникло какое-то недопонимание. Я просил посоветовать литературу по вполне конкретным темам. Если FDG хоть в какой-то степени релевантен (уже читал), то Рихтер — это вообще не в ту степь (тоже читал). У меня нет задачи потратить время максимально эффективно: есть задача найти чего почитать перед сном.
Re[5]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, andyag, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, andyag, Вы писали:
A>>>Фундаментальные вещи — это что например?
G>>Фундаментальные вещи — это декомпозиция и композиция. То есть нужно уметь делить большую задачу на маленькие кусочки, которые максимально эффективно решаются средствами того языка и платформы, на которой ты работаешь, а потом собирать из этих кусочков готовое решение и встраивать его в приложение.
A>Так паттерны как раз и посвящены композиции и декомпозиции.Паттерны в первую очередь описывают ситуацию, где есть как минимум 2 участника, каждый со своими интересами, и нужно каким-то образом их подружить. На реализацию дружбы накладываются какие-то дополнительные ограничения, а исходя из этих ограничений предлагается _подход_ к реализации. В разных языках реализация может требовать больше или меньше кода, но с точки зрения подхода, с точки зрения выделенных компонентов и связей между ними всегда будет одно и то же. Если взять тот же Observer из GoF: A>1. В Java нужно будет написать интерфейс IObserver, чтобы выделить компонент "Observer", а уведомляющему классу добавить методы типа subscribe/unsubscribe, чтобы выделить компонент "Subject". A>2. В .NET всё то же самое — предлагается выделить Observer и Subject, но в языке есть средства, которые позволяют обойтись без введения штук типа IObserver, а просто взять и использовать готовый инструмент — делагаты/события. A>В обоих случаях участники и связи между ними одни и те же, но технически решения отличаются: просто в Java единственный подходящий инструмент — это интерфейсы и классы, а в .NET есть более подходящий инструмент — events/delegates.
1) паттерны посвящены решению конкретных проблем, а не фундаментальным вещам.
2) паттерн претендуют на незвисимость от языка и платформы
На практике же в современных языках уже есть средства решения многих проблем, зачастую гораздо более элегантные, чем предлагается в GOF. Например визитор на динамиках в C#, лямбды с замыканиями вместо команд или паттерн-матчинг в ФЯ.
Поэтому первично — понимание возможностей языка и среды где ты создаешь решение, а паттерны вторичны (если вообще в них есть какой-либо смысл).
A>ИМХО, вся фишка паттернов в том, что программист может оперировать "стереотипными пачками объектов", а не отдельными объектами — никакой более высокой цели. У меня в принципе нет никакого желания спорить о нужности или ненужности всех этих знаний — просто хочется почитать нечто по сравнительно конкретным темам
Очень сомнительная "фишка", так как подменяет цель средством. Вместо простого кода решающего проблему появляется куча паттернов, которые только усложняют решение.
Я очень рад, что никто не выпустил книжку "asyncronous computation patterns" во времена .NET 2.0 , иначе мы бы сейчас имели вторую волну буллшита.
Re[5]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, andyag, Вы писали:
A>Здравствуйте, Sinix, Вы писали:
S>>Здравствуйте, andyag, Вы писали:
A>>>Фундаментальные вещи — это что например?
S>>Для явы — . Она по-моему безнадёжно пропитана паттернами. S>>Для дотнета самый лучший использовать паттерны — не вспоминать про них вовсе.
A>Есть какая-то принципиальная разница между Java и .NET, из-за которой подход к программированию принципиально отличается? Мне правда интересно.
1) Linq
2) Лямбды с честными замыканиями и ФВП
3) Анонимные типы
4) async\await и TPL
5) Очень прагматичные фреймворки
A>Тут возникло какое-то недопонимание. Я просил посоветовать литературу по вполне конкретным темам. Если FDG хоть в какой-то степени релевантен (уже читал), то Рихтер — это вообще не в ту степь (тоже читал). У меня нет задачи потратить время максимально эффективно: есть задача найти чего почитать перед сном.
Почитай SICP, Proramming pearls, Pragmatic Programmer, Design of Design и 4 томика крута.
Re[6]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, andyag, Вы писали:
A>>Есть какая-то принципиальная разница между Java и .NET, из-за которой подход к программированию принципиально отличается? Мне правда интересно.
G>1) Linq G>2) Лямбды с честными замыканиями и ФВП G>3) Анонимные типы G>4) async\await и TPL
Эти штуки C#/.NET безусловно рвут Java в плане скорости разработки и защиты от ошибок, но всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны и исчезает разница между .NET и Java. Не поймите меня неправильно: я последние несколько лет пишу параллельно на C# и Java, отлично понимаю разницу между одной выразительной строчкой на LINQ и сотней плохочитаемых строчек в JPA, отлично знаю какой это геморрой делать UI без async/await. Но это всё просто инструменты языка — где-то они заменяют нагромождение классов, где-то уменьшают это нагромождение, а где-то от них ни холодно, ни жарко.
ИМХО, вещи совершенно параллельные.
Re[6]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, andyag, Вы писали:
A>>Так паттерны как раз и посвящены композиции и декомпозиции.Паттерны в первую очередь описывают ситуацию, где есть как минимум 2 участника, каждый со своими интересами, и нужно каким-то образом их подружить. На реализацию дружбы накладываются какие-то дополнительные ограничения, а исходя из этих ограничений предлагается _подход_ к реализации. В разных языках реализация может требовать больше или меньше кода, но с точки зрения подхода, с точки зрения выделенных компонентов и связей между ними всегда будет одно и то же. Если взять тот же Observer из GoF: A>>1. В Java нужно будет написать интерфейс IObserver, чтобы выделить компонент "Observer", а уведомляющему классу добавить методы типа subscribe/unsubscribe, чтобы выделить компонент "Subject". A>>2. В .NET всё то же самое — предлагается выделить Observer и Subject, но в языке есть средства, которые позволяют обойтись без введения штук типа IObserver, а просто взять и использовать готовый инструмент — делагаты/события. A>>В обоих случаях участники и связи между ними одни и те же, но технически решения отличаются: просто в Java единственный подходящий инструмент — это интерфейсы и классы, а в .NET есть более подходящий инструмент — events/delegates. G>1) паттерны посвящены решению конкретных проблем, а не фундаментальным вещам.
Тут всё просто: меня сегодня не интересуют фундаментальные вещи, поэтому я попросил посоветовать книжки с баззвордами
G>2) паттерн претендуют на незвисимость от языка и платформы
Неправда. Если взять паттерны GoF, речь "официально" идёт только о языках, умеющих ООП. Прямо на обложке написано.
К чему тут слово "платформа" — не понял.
G>На практике же в современных языках уже есть средства решения многих проблем, зачастую гораздо более элегантные, чем предлагается в GOF. Например визитор на динамиках в C#, лямбды с замыканиями вместо команд или паттерн-матчинг в ФЯ. G>Поэтому первично — понимание возможностей языка и среды где ты создаешь решение, а паттерны вторичны (если вообще в них есть какой-либо смысл).
Хорошо. Что-то в манере моего письма заставило вас думать, что мне пока рано читать про вторичное?
A>>ИМХО, вся фишка паттернов в том, что программист может оперировать "стереотипными пачками объектов", а не отдельными объектами — никакой более высокой цели. У меня в принципе нет никакого желания спорить о нужности или ненужности всех этих знаний — просто хочется почитать нечто по сравнительно конкретным темам G>Очень сомнительная "фишка", так как подменяет цель средством. Вместо простого кода решающего проблему появляется куча паттернов, которые только усложняют решение. G>Я очень рад, что никто не выпустил книжку "asyncronous computation patterns" во времена .NET 2.0 , иначе мы бы сейчас имели вторую волну буллшита.
Вы из темы в тему пишете хорошие правильные вещи и всё время одна и та же проблема: вы интерпретируете вопросы с точки зрения своего нынешнего уровня не пытаясь проследить историю развития. Если бы вы "ненавидели" паттерны до знакомства с книжкой GoF, это было бы джуниорство. А вот после неё — вполне по-сеньорски. В обоих случаях — ненависть к паттернам, но сильно разная. Давайте предположим, что моя мотивация сейчас — прочитать ещё пару (десятков) книжек по паттернам, чтобы в итоге точно так же их возненавидеть.
Re[5]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, andyag, Вы писали:
A>Есть какая-то принципиальная разница между Java и .NET, из-за которой подход к программированию принципиально отличается? Мне правда интересно.
Ага. Фаулер не так популярен
Если серьёзно, то в дотнете куча вещей реализованы напрямую из коробки и поддерживаются языком. Плюс учтён опыт хождения по граблям явы, дельфей и бейсика. У явы такого подарка на было
В результате в дотнете нет особой необходимости переизобретать стандартные вещи на ровном месте, сравни например события шарпа и явы. Или linq (ответ по ссылке бесценен как mastercard )
И пожалуй главное: сам подход к дизайну api в дотнете гораздо прагматичнее, api за редкими исключениями здорово вылизано. По крайней мере кошмариков типа InstantiationAwareBeanPostProcessorAdapter я не встречал.
Чтобы не холиварить: по большому счёту вся разница сводится к спору о вкусе фломастеров, мои предпочтения явно смещены в сторону дотнета. Для полноты картины было бы классно услышать мнение с другой стороны.
S>>Гораздо полезней изучить Рихтера и Framework Design Guidelines. Ну и не забывать про здравый смысл и знание матчасти, но это уже общий рецепт. A>Тут возникло какое-то недопонимание. Я просил посоветовать литературу по вполне конкретным темам.
А без Рихтера от FDG толку не будет, без хорошего знания матчасти большая часть рекомендаций так и останется непонятной. Поэтому обычно советую обе книги парой.
Re[7]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, andyag, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, andyag, Вы писали:
A>>>Есть какая-то принципиальная разница между Java и .NET, из-за которой подход к программированию принципиально отличается? Мне правда интересно.
G>>1) Linq G>>2) Лямбды с честными замыканиями и ФВП G>>3) Анонимные типы G>>4) async\await и TPL
A>Эти штуки C#/.NET безусловно рвут Java в плане скорости разработки и защиты от ошибок, но всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах.
Для Linq все методы являются методами-расширениями, которые по сути стирают различия между method(a,b) a.method(b). А классы в этом случае не более чем пространства имен. В новом C# имена классов можно писать в using и не использовать квалифицированные имена методов других классов. Да и вообще есть scriptcs, в котом классы в C# писать не обязательно.
A>И где-то в этой точке одновременно появляются паттерны и исчезает разница между .NET и Java.
Нет такой точки самой по себе. Она только в голове программиста.
A>Не поймите меня неправильно: я последние несколько лет пишу параллельно на C# и Java, отлично понимаю разницу между одной выразительной строчкой на LINQ и сотней плохочитаемых строчек в JPA, отлично знаю какой это геморрой делать UI без async/await. Но это всё просто инструменты языка — где-то они заменяют нагромождение классов, где-то уменьшают это нагромождение, а где-то от них ни холодно, ни жарко. A>ИМХО, вещи совершенно параллельные.
Самое главное что эти методы позволяют по другому строить программы. Не как рекурсивную композицию объектов, а как композицию функций.
Re[7]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, andyag, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>Тут всё просто: меня сегодня не интересуют фундаментальные вещи, поэтому я попросил посоветовать книжки с баззвордами
а зря
G>>2) паттерн претендуют на незвисимость от языка и платформы
A>Неправда. Если взять паттерны GoF, речь "официально" идёт только о языках, умеющих ООП. Прямо на обложке написано.
И неправильно написано. Речь идет о языках, умеющих только ООП. Почувствуй разницу.
A>К чему тут слово "платформа" — не понял.
Например MVC, про который говоритс в GOF совершенно не нужен в WPF, где во всю рулит MVVM.
G>>На практике же в современных языках уже есть средства решения многих проблем, зачастую гораздо более элегантные, чем предлагается в GOF. Например визитор на динамиках в C#, лямбды с замыканиями вместо команд или паттерн-матчинг в ФЯ. G>>Поэтому первично — понимание возможностей языка и среды где ты создаешь решение, а паттерны вторичны (если вообще в них есть какой-либо смысл).
A>Хорошо. Что-то в манере моего письма заставило вас думать, что мне пока рано читать про вторичное?
Вот эта
ИМХО, вся фишка паттернов в том, что программист может оперировать "стереотипными пачками объектов"
A>>>ИМХО, вся фишка паттернов в том, что программист может оперировать "стереотипными пачками объектов", а не отдельными объектами — никакой более высокой цели. У меня в принципе нет никакого желания спорить о нужности или ненужности всех этих знаний — просто хочется почитать нечто по сравнительно конкретным темам G>>Очень сомнительная "фишка", так как подменяет цель средством. Вместо простого кода решающего проблему появляется куча паттернов, которые только усложняют решение. G>>Я очень рад, что никто не выпустил книжку "asyncronous computation patterns" во времена .NET 2.0 , иначе мы бы сейчас имели вторую волну буллшита.
A>Вы из темы в тему пишете хорошие правильные вещи и всё время одна и та же проблема: вы интерпретируете вопросы с точки зрения своего нынешнего уровня не пытаясь проследить историю развития. Если бы вы "ненавидели" паттерны до знакомства с книжкой GoF, это было бы джуниорство. А вот после неё — вполне по-сеньорски. В обоих случаях — ненависть к паттернам, но сильно разная. Давайте предположим, что моя мотивация сейчас — прочитать ещё пару (десятков) книжек по паттернам, чтобы в итоге точно так же их возненавидеть.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, andyag, Вы писали:
A>>Эти штуки C#/.NET безусловно рвут Java в плане скорости разработки и защиты от ошибок, но всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. G>Для Linq все методы являются методами-расширениями, которые по сути стирают различия между method(a,b) a.method(b). А классы в этом случае не более чем пространства имен. В новом C# имена классов можно писать в using и не использовать квалифицированные имена методов других классов.
Благодаря тому, что в последние несколько лет в C# регулярно появляется всё больше не-чисто-ООПшных штук, вполне ожидаемо, что в C# комьюнити появляются люди, которые пытаются всё тянуть под эти самые не-ООПшные штуки. Но за этим ничего нет — просто обязательно кто-то будет пытаться убедить оппонента, что в C# можно делать всё по-другому. Можно. А зачем?
G>Да и вообще есть scriptcs, в котом классы в C# писать не обязательно.
В мире Java есть Groovy — тоже можно не писать классы. К чему это?
A>>И где-то в этой точке одновременно появляются паттерны и исчезает разница между .NET и Java. G>Нет такой точки самой по себе. Она только в голове программиста.
Такая точка появляется при любой попытке заинтегрировать свой LINQ-only код с 99% фреймворков — начиная с MSTest/NUnit, где надо писать классы и вешать на них аттрибуты, и заканчивая ASP.NET WebAPI, где вообще от ApiController наследоваться нужно.
A>>Не поймите меня неправильно: я последние несколько лет пишу параллельно на C# и Java, отлично понимаю разницу между одной выразительной строчкой на LINQ и сотней плохочитаемых строчек в JPA, отлично знаю какой это геморрой делать UI без async/await. Но это всё просто инструменты языка — где-то они заменяют нагромождение классов, где-то уменьшают это нагромождение, а где-то от них ни холодно, ни жарко. A>>ИМХО, вещи совершенно параллельные. G>Самое главное что эти методы позволяют по другому строить программы. Не как рекурсивную композицию объектов, а как композицию функций.
Не соглашусь. Эта ценность есть только у вас в голове.
Re[8]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, andyag, Вы писали:
A>>Здравствуйте, gandjustas, Вы писали:
G>>>2) паттерн претендуют на незвисимость от языка и платформы A>>Неправда. Если взять паттерны GoF, речь "официально" идёт только о языках, умеющих ООП. Прямо на обложке написано. G>И неправильно написано. Речь идет о языках, умеющих только ООП. Почувствуй разницу.
Это какой-то флуд уже пошёл. Не бывает языков, которые умеют _только_ ООП.
A>>К чему тут слово "платформа" — не понял. G>Например MVC, про который говоритс в GOF совершенно не нужен в WPF, где во всю рулит MVVM.
MVC в GoF? Вы уверены, что читали книгу?
G>>>Поэтому первично — понимание возможностей языка и среды где ты создаешь решение, а паттерны вторичны (если вообще в них есть какой-либо смысл). A>>Хорошо. Что-то в манере моего письма заставило вас думать, что мне пока рано читать про вторичное? G>Вот эта G>
G>ИМХО, вся фишка паттернов в том, что программист может оперировать "стереотипными пачками объектов"
Окей.
G>>>Очень сомнительная "фишка", так как подменяет цель средством. Вместо простого кода решающего проблему появляется куча паттернов, которые только усложняют решение. G>>>Я очень рад, что никто не выпустил книжку "asyncronous computation patterns" во времена .NET 2.0 , иначе мы бы сейчас имели вторую волну буллшита. A>>Вы из темы в тему пишете хорошие правильные вещи и всё время одна и та же проблема: вы интерпретируете вопросы с точки зрения своего нынешнего уровня не пытаясь проследить историю развития. Если бы вы "ненавидели" паттерны до знакомства с книжкой GoF, это было бы джуниорство. А вот после неё — вполне по-сеньорски. В обоих случаях — ненависть к паттернам, но сильно разная. Давайте предположим, что моя мотивация сейчас — прочитать ещё пару (десятков) книжек по паттернам, чтобы в итоге точно так же их возненавидеть. G>А зачем? Нужно просто их знать и не применять.
Если стоит задача "не применять", то не-применять можно всё что угодно. Почему это должны быть именно паттерны GoF?
G>Когда изучишь 50 способов сделать тоже самое, то поймешь почему паттерны не нужно применять.
Сомнительный подход. Не получится потом, что находишь себя 40-летним дядькой, который единственное что умеет — делать одну и ту же ненужную хрень 50 разными способами?
Очень хочется, чтобы там было:
. Она по-моему безнадёжно пропитана паттернами.
)