После долгих лет изучения ООП/ООД возникло-таки желание почитать о нём какую-то книжку Очень хочется, чтобы там было:

1. Откуда взялось слово "factory" и что ещё бывает оттуда же. Интересно, что у GoF есть только Abstract Factory, а просто Factory нету. Откуда оно взялось?
2. Откуда взялось слово "service" и что ещё бывает оттуда же. Предположу, что где-то там же должны быть описаны термины rich domain model и anemic domain model.
3. Рассказ про MVC с попытками однозначно его интерпретировать.
4. Рассказ про SOLID, GRASP и что ещё бывает такого.

Посоветуйте пожалуйста.

Здравствуйте, 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>Посоветуйте пожалуйста.

SOLID — Роберт Мартин http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

Factory — это обобщение Factory Method\Abstract Factory из GOF, особую популярность паттерн получил в среде Java, где фабрику обозначали посфиксом в названии, чтобы не писать лишних слов. Если постфикс в названии класса, то это abstract factory, а если в названии метода, то factory method.

Service — это от SOA. Историю можно тут почитать — http://www.eriktownsend.com/doc_download/12-1-the-25-year-history-of-service-oriented-architecture.html. Получился настолько универсальный термин, что утянули везде.

GRASP — Ларман http://authors.phptr.com/larman/uml_ooad/index.html

Про MVC — нет такого, до GOF цельной инфы об MVC не было, да и GOF не внесли ясности. Разве что тут — http://rsdn.ru/forum/design/5406934.1

Автор: gandjustas
Дата: 23.12.13

Вообще все что можно почитать по теме можно найти в википедии — http://en.wikipedia.org/wiki/Software_design_pattern#Further_reading и http://en.wikipedia.org/wiki/Software_design_pattern#References

Здравствуйте, andyag, Вы писали:

A>После долгих лет изучения ООП/ООД возникло-таки желание почитать о нём какую-то книжку Очень хочется, чтобы там было:

Я не понимаю вообще. Зачем знать баззворды? Лучше какие-то более фундаментальные вещи. ИМХО.

То есть это все говорит, что нужно писать единую книжку.

Кто б из наших гуру занялся бы, а?
А я б редактировал.

Здравствуйте, romangr, Вы писали:

R>Здравствуйте, andyag, Вы писали:

A>>После долгих лет изучения ООП/ООД возникло-таки желание почитать о нём какую-то книжку Очень хочется, чтобы там было:

R>Я не понимаю вообще. Зачем знать баззворды? Лучше какие-то более фундаментальные вещи. ИМХО.

Фундаментальные вещи — это что например?

Здравствуйте, andyag, Вы писали:

A>Фундаментальные вещи — это что например?

Для явы — . Она по-моему безнадёжно пропитана паттернами.
Для дотнета самый лучший использовать паттерны — не вспоминать про них вовсе. Гораздо полезней изучить Рихтера и Framework Design Guidelines. Ну и не забывать про здравый смысл и знание матчасти, но это уже общий рецепт.

Обсуждалось кучу раз, например здесь

Автор: -rsdn-
Дата: 24.03.14

.

Здравствуйте, LaptevVV, Вы писали:

LVV>То есть это все говорит, что нужно писать единую книжку.

LVV>Кто б из наших гуру занялся бы, а?
LVV>А я б редактировал.

Данунафиг, неблагодарное это занятие.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, LaptevVV, Вы писали:

LVV>>То есть это все говорит, что нужно писать единую книжку.

LVV>>Кто б из наших гуру занялся бы, а?
LVV>>А я б редактировал.

G>Данунафиг, неблагодарное это занятие.
Смотря что считать за пользу.
Писавшему — польза. Например, проясняются не совсем понятные моменты.
Опять же, если надо будет потом кому-то рассказывать, то формулировки уже будут отточены.
Денег — да, мало.
Но зато известность и репутация — а это часто стОит больших денег...

Здравствуйте, andyag, Вы писали:

A>Фундаментальные вещи — это что например?

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

Например для ООП основа почти всех паттернов это выделение интерфейсов и рекурсивная композиция.
В ФЯ вариантов гораздо больше, там и ФВП, и монады, и комбинаторы, и пайплайн.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, andyag, Вы писали:

A>>Фундаментальные вещи — это что например?

G>Фундаментальные вещи — это декомпозиция и композиция. То есть нужно уметь делить большую задачу на маленькие кусочки, которые максимально эффективно решаются средствами того языка и платформы, на которой ты работаешь, а потом собирать из этих кусочков готовое решение и встраивать его в приложение.

Так паттерны как раз и посвящены композиции и декомпозиции. Паттерны в первую очередь описывают ситуацию, где есть как минимум 2 участника, каждый со своими интересами, и нужно каким-то образом их подружить. На реализацию дружбы накладываются какие-то дополнительные ограничения, а исходя из этих ограничений предлагается _подход_ к реализации. В разных языках реализация может требовать больше или меньше кода, но с точки зрения подхода, с точки зрения выделенных компонентов и связей между ними всегда будет одно и то же. Если взять тот же Observer из GoF:
1. В Java нужно будет написать интерфейс IObserver, чтобы выделить компонент "Observer", а уведомляющему классу добавить методы типа subscribe/unsubscribe, чтобы выделить компонент "Subject".
2. В .NET всё то же самое — предлагается выделить Observer и Subject, но в языке есть средства, которые позволяют обойтись без введения штук типа IObserver, а просто взять и использовать готовый инструмент — делагаты/события.
В обоих случаях участники и связи между ними одни и те же, но технически решения отличаются: просто в Java единственный подходящий инструмент — это интерфейсы и классы, а в .NET есть более подходящий инструмент — events/delegates.

ИМХО, вся фишка паттернов в том, что программист может оперировать "стереотипными пачками объектов", а не отдельными объектами — никакой более высокой цели. У меня в принципе нет никакого желания спорить о нужности или ненужности всех этих знаний — просто хочется почитать нечто по сравнительно конкретным темам

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, andyag, Вы писали:

A>>Фундаментальные вещи — это что например?

S>Для явы — . Она по-моему безнадёжно пропитана паттернами.
S>Для дотнета самый лучший использовать паттерны — не вспоминать про них вовсе.

Есть какая-то принципиальная разница между Java и .NET, из-за которой подход к программированию принципиально отличается? Мне правда интересно.

S>Гораздо полезней изучить Рихтера и Framework Design Guidelines. Ну и не забывать про здравый смысл и знание матчасти, но это уже общий рецепт.

Тут возникло какое-то недопонимание. Я просил посоветовать литературу по вполне конкретным темам. Если FDG хоть в какой-то степени релевантен (уже читал), то Рихтер — это вообще не в ту степь (тоже читал). У меня нет задачи потратить время максимально эффективно: есть задача найти чего почитать перед сном.

Здравствуйте, 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 , иначе мы бы сейчас имели вторую волну буллшита.

Здравствуйте, 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 томика крута.

Здравствуйте, 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. Но это всё просто инструменты языка — где-то они заменяют нагромождение классов, где-то уменьшают это нагромождение, а где-то от них ни холодно, ни жарко.
ИМХО, вещи совершенно параллельные.

Здравствуйте, 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, это было бы джуниорство. А вот после неё — вполне по-сеньорски. В обоих случаях — ненависть к паттернам, но сильно разная. Давайте предположим, что моя мотивация сейчас — прочитать ещё пару (десятков) книжек по паттернам, чтобы в итоге точно так же их возненавидеть.

Здравствуйте, andyag, Вы писали:

A>Есть какая-то принципиальная разница между Java и .NET, из-за которой подход к программированию принципиально отличается? Мне правда интересно.

Ага. Фаулер не так популярен

Если серьёзно, то в дотнете куча вещей реализованы напрямую из коробки и поддерживаются языком. Плюс учтён опыт хождения по граблям явы, дельфей и бейсика. У явы такого подарка на было
В результате в дотнете нет особой необходимости переизобретать стандартные вещи на ровном месте, сравни например события шарпа и явы. Или linq (ответ по ссылке бесценен как mastercard )

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

Чтобы не холиварить: по большому счёту вся разница сводится к спору о вкусе фломастеров, мои предпочтения явно смещены в сторону дотнета. Для полноты картины было бы классно услышать мнение с другой стороны.

S>>Гораздо полезней изучить Рихтера и Framework Design Guidelines. Ну и не забывать про здравый смысл и знание матчасти, но это уже общий рецепт.
A>Тут возникло какое-то недопонимание. Я просил посоветовать литературу по вполне конкретным темам.
А без Рихтера от FDG толку не будет, без хорошего знания матчасти большая часть рекомендаций так и останется непонятной. Поэтому обычно советую обе книги парой.

Здравствуйте, 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>ИМХО, вещи совершенно параллельные.
Самое главное что эти методы позволяют по другому строить программы. Не как рекурсивную композицию объектов, а как композицию функций.

Здравствуйте, 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, это было бы джуниорство. А вот после неё — вполне по-сеньорски. В обоих случаях — ненависть к паттернам, но сильно разная. Давайте предположим, что моя мотивация сейчас — прочитать ещё пару (десятков) книжек по паттернам, чтобы в итоге точно так же их возненавидеть.

А зачем? Нужно просто их знать и не применять.
Классика же http://rsdn.ru/forum/info/FAQ.philosophy.kungfu

Когда изучишь 50 способов сделать тоже самое, то поймешь почему паттерны не нужно применять.

Здравствуйте, 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>Самое главное что эти методы позволяют по другому строить программы. Не как рекурсивную композицию объектов, а как композицию функций.

Не соглашусь. Эта ценность есть только у вас в голове.

Здравствуйте, 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 разными способами?

Здравствуйте, andyag, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, andyag, Вы писали:

A>>>Эти штуки C#/.NET безусловно рвут Java в плане скорости разработки и защиты от ошибок, но всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах.
G>>Для Linq все методы являются методами-расширениями, которые по сути стирают различия между method(a,b) a.method(b). А классы в этом случае не более чем пространства имен. В новом C# имена классов можно писать в using и не использовать квалифицированные имена методов других классов.

A>Благодаря тому, что в последние несколько лет в C# регулярно появляется всё больше не-чисто-ООПшных штук, вполне ожидаемо, что в C# комьюнити появляются люди, которые пытаются всё тянуть под эти самые не-ООПшные штуки. Но за этим ничего нет — просто обязательно кто-то будет пытаться убедить оппонента, что в C# можно делать всё по-другому. Можно. А зачем?

1) меньше кода
2) больший контроль со стороны компилятора
3) меньше связность
4) Чистые функции (меньше ошибок)


G>>Да и вообще есть scriptcs, в котом классы в C# писать не обязательно.
A>В мире Java есть Groovy — тоже можно не писать классы. К чему это?
Ты не понял? groovy это другой язык, а scriptcs это тот же самый C#, в котором нет необходимости писать классы.


A>>>И где-то в этой точке одновременно появляются паттерны и исчезает разница между .NET и Java.
G>>Нет такой точки самой по себе. Она только в голове программиста.

A>Такая точка появляется при любой попытке заинтегрировать свой LINQ-only код с 99% фреймворков — начиная с MSTest/NUnit, где надо писать классы и вешать на них аттрибуты, и заканчивая ASP.NET WebAPI, где вообще от ApiController наследоваться нужно.
Открою тайну, в ASP.NET 5 уж не нужно ни от чего наследоваться. там все на conventions сделано. Да и раньше достаточно было реализовать IController только. ControllerBase нужен только для того, чтобы методы вызывать без префикса-имени класса. А, как уже писал выше в C# новой версии это не нужно, поэтому и потребность в базовом классе отпала, а да и в каком либо интерфейсе.


Просто ASP.NET MVC появился тогда, когда появился .NET 3.5 и на тот момент ООП еще будоражило умы людей. А webapi тупо скопировал дизайн ASP.NET MVC. Прошло 5 лет и народ попроще стал относится к ООП, перестал плодить абстрактные фабрики стратегий.


A>>>Не поймите меня неправильно: я последние несколько лет пишу параллельно на C# и Java, отлично понимаю разницу между одной выразительной строчкой на LINQ и сотней плохочитаемых строчек в JPA, отлично знаю какой это геморрой делать UI без async/await. Но это всё просто инструменты языка — где-то они заменяют нагромождение классов, где-то уменьшают это нагромождение, а где-то от них ни холодно, ни жарко.
A>>>ИМХО, вещи совершенно параллельные.
G>>Самое главное что эти методы позволяют по другому строить программы. Не как рекурсивную композицию объектов, а как композицию функций.
A>Не соглашусь. Эта ценность есть только у вас в голове.
Ну не соглашайся, твое дело.
Попробуй просто на досуге собрать на принципах ООП (применяя любые паттерны из GOF) чтонить вроде linq.

Здравствуйте, gandjustas, Вы писали:

G>Открою тайну, в ASP.NET 5 уж не нужно ни от чего наследоваться. там все на conventions сделано.

Обычно это означает — меньший контроль со стороны компилятора.

Здравствуйте, andyag, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, andyag, Вы писали:

A>>>Здравствуйте, gandjustas, Вы писали:

G>>>>2) паттерн претендуют на незвисимость от языка и платформы
A>>>Неправда. Если взять паттерны GoF, речь "официально" идёт только о языках, умеющих ООП. Прямо на обложке написано.
G>>И неправильно написано. Речь идет о языках, умеющих только ООП. Почувствуй разницу.

A>Это какой-то флуд уже пошёл. Не бывает языков, которые умеют _только_ ООП.
Как это? simula, smalltalk, C++ ранних версий. Там кроме ООП практически нет средств и подульности, ни композиции.

A>>>К чему тут слово "платформа" — не понял.
G>>Например MVC, про который говоритс в GOF совершенно не нужен в WPF, где во всю рулит MVVM.

A>MVC в GoF? Вы уверены, что читали книгу?
Уверен, а ты?
В русском издании раздел 1.2 имеет название" Паттерны проектирования в схеме MVC в языке Smalltalk".


A>Если стоит задача "не применять", то не-применять можно всё что угодно. Почему это должны быть именно паттерны GoF?
Потому что их слишком легко применять неправильно и не к месту.

G>>Когда изучишь 50 способов сделать тоже самое, то поймешь почему паттерны не нужно применять.
A>Сомнительный подход. Не получится потом, что находишь себя 40-летним дядькой, который единственное что умеет — делать одну и ту же ненужную хрень 50 разными способами?
Для начала попробуй сделать ProblemK хотя бы на 10 разных яызках.
После этого можешь броить разработку, написать книгу по архитектуре и проводить безумно дорогие тренинги для неофитов.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>Открою тайну, в ASP.NET 5 уж не нужно ни от чего наследоваться. там все на conventions сделано.

D>Обычно это означает — меньший контроль со стороны компилятора.

А раньше какой контроль был?

Пример

public class HomeController: Controller
{
    ActionResult Index()
    {
       return View();
    }
}

Какие использовались соглашения:
1) Имя класса контроллера заканчивается на Controller
2) Action возвращает ActionResult (хотя может возвращать что угодно, главное не void)
Что из них проверяется компилятором? Внезапно ничего.

Единственная ценность наследования в данном случае — это писать return View(), а не return new ViewResult().
Но в новом C# можно написать return View(), даже если метод View находится в другом классе.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, andyag, Вы писали:

A>>Это какой-то флуд уже пошёл. Не бывает языков, которые умеют _только_ ООП.
G>Как это? simula, smalltalk, C++ ранних версий. Там кроме ООП практически нет средств и подульности, ни композиции.

Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО. Точно так же как и в языках без поддержки ООП из коробки можно самостоятельно сделать своё ООП. В первом случае программиста назовут идиотом, потому что он использует "слишком мало" возможностей языка, во втором случае — потому использует язык, возможностей которого не хватает для избранного подхода к дизайну.

A>>MVC в GoF? Вы уверены, что читали книгу?
G>Уверен, а ты?
G>В русском издании раздел 1.2 имеет название" Паттерны проектирования в схеме MVC в языке Smalltalk".
Сорри — утверждение проинтерпретировалось как "MVC — паттерн из GoF". То что он там где-то в районе предисловия был вполне допускаю.

A>>Если стоит задача "не применять", то не-применять можно всё что угодно. Почему это должны быть именно паттерны GoF?
G>Потому что их слишком легко применять неправильно и не к месту.
Ага, то ли дело — изучить ФП.

G>>>Когда изучишь 50 способов сделать тоже самое, то поймешь почему паттерны не нужно применять.
A>>Сомнительный подход. Не получится потом, что находишь себя 40-летним дядькой, который единственное что умеет — делать одну и ту же ненужную хрень 50 разными способами?
G>Для начала попробуй сделать ProblemK хотя бы на 10 разных яызках.
Спасибо, изучением миллионов языков я уже переболел, парсеры и обход графа делать умею.

Здравствуйте, gandjustas, Вы писали:

G>Какие использовались соглашения:
G>1) Имя класса контроллера заканчивается на Controller
G>2) Action возвращает ActionResult (хотя может возвращать что угодно, главное не void)
G>Что из них проверяется компилятором? Внезапно ничего.

Если так, то может быть. Но у меня кроме Index() обычно ещё куча всяких вспомогательных методов в контроллере (проверка прав, например; а в случае REST-двигла там вообще развесистый template method), и наследование начинает рулить со страшной силой: code completion, защита от опечаток и т.п. В этой связи я когда-то высказывался (в теме, называвшейся что-то типа "что вам не нравится в языках, на которых вы пишете") про жаву, что ейные фреймворки целиком на POJO+аннотациях вместо наследования — уничтожают саму идею статики.

Здравствуйте, andyag, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, andyag, Вы писали:

A>>>Это какой-то флуд уже пошёл. Не бывает языков, которые умеют _только_ ООП.
G>>Как это? simula, smalltalk, C++ ранних версий. Там кроме ООП практически нет средств и подульности, ни композиции.

A>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО.
Прекрасный вывод, но кажется полдня назад ты утверждал что

A>всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны

A>Точно так же как и в языках без поддержки ООП из коробки можно самостоятельно сделать своё ООП. В первом случае программиста назовут идиотом, потому что он использует "слишком мало" возможностей языка, во втором случае — потому использует язык, возможностей которого не хватает для избранного подхода к дизайну.
И как же люди на haskell или scheme пишут... там вообще классов нет. Да и линукс написан на голом С без классов.
Видимо в ООП не так много ценности, что его так игнорируют и не страдают.

A>>>MVC в GoF? Вы уверены, что читали книгу?
G>>Уверен, а ты?
G>>В русском издании раздел 1.2 имеет название" Паттерны проектирования в схеме MVC в языке Smalltalk".
A>Сорри — утверждение проинтерпретировалось как "MVC — паттерн из GoF". То что он там где-то в районе предисловия был вполне допускаю.
Его жизнь началась с GOF, до этого никто не слышал о таком. Если посмотреть историю, то до GOF было два упоминания MVC в публичном доступе, что в отсутствии повсеместного доступа в интернет означало, что об MVC не знал никто.
По сути до появления массового общедоступного интернета знания распространялись только в книгах. Сейчас таким носителем служат скорее блоги, записи выступлений, вебкасты? презентации и StackOverflow.


G>>>>Когда изучишь 50 способов сделать тоже самое, то поймешь почему паттерны не нужно применять.
A>>>Сомнительный подход. Не получится потом, что находишь себя 40-летним дядькой, который единственное что умеет — делать одну и ту же ненужную хрень 50 разными способами?
G>>Для начала попробуй сделать ProblemK хотя бы на 10 разных яызках.
A>Спасибо, изучением миллионов языков я уже переболел, парсеры и обход графа делать умею.
Вот в этом и фишка. Парсеры и обходы графов умеют многие, а сделать из этого приложение, выполняющее осмысленные действия — почти никто. И ключевой навык нужный для этого — композиция.
Поэтому и полезно решать такие задачи, причем на разных языках, потому что появляется навык применять нереальное число способов композиции.

ЗЫ. Кстати в книге pragmatic programmer, о которой я выше писал, рекомендуется изучать по одному языку в год.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, andyag, Вы писали:

A>>Благодаря тому, что в последние несколько лет в C# регулярно появляется всё больше не-чисто-ООПшных штук, вполне ожидаемо, что в C# комьюнити появляются люди, которые пытаются всё тянуть под эти самые не-ООПшные штуки. Но за этим ничего нет — просто обязательно кто-то будет пытаться убедить оппонента, что в C# можно делать всё по-другому. Можно. А зачем?

G>1) меньше кода
G>2) больший контроль со стороны компилятора
G>3) меньше связность
G>4) Чистые функции (меньше ошибок)

Это ваша субъективная любовь к ФП или есть какие-то исследования, где 2 группы обезьян пишут на ФП и ООП?

A>>В мире Java есть Groovy — тоже можно не писать классы. К чему это?
G>Ты не понял? groovy это другой язык, а scriptcs это тот же самый C#, в котором нет необходимости писать классы.

До тех пор пока оно не компилируется csc, это не C#. Если вы закрываете на это глаза, Groovy ничем не отличается от Java кроме необязательности классов.

A>>Такая точка появляется при любой попытке заинтегрировать свой LINQ-only код с 99% фреймворков — начиная с MSTest/NUnit, где надо писать классы и вешать на них аттрибуты, и заканчивая ASP.NET WebAPI, где вообще от ApiController наследоваться нужно.
G>Открою тайну, в ASP.NET 5 уж не нужно ни от чего наследоваться. там все на conventions сделано. Да и раньше достаточно было реализовать IController только. ControllerBase нужен только для того, чтобы методы вызывать без префикса-имени класса. А, как уже писал выше в C# новой версии это не нужно, поэтому и потребность в базовом классе отпала, а да и в каком либо интерфейсе.

Не расслышал — вы говорите, всё ещё надо классы писать или мне показалось?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, andyag, Вы писали:

A>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, andyag, Вы писали:

A>>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО.
G>Прекрасный вывод, но кажется полдня назад ты утверждал что
G>

A>>всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны

Если есть какое-то противоречие, я его не вижу. Давайте по-другому попробую. Если язык говорит, что через конструкцию "class XXX { ... }" можно описывать ООПшные классы, это:
1. во-первых не означает, что ООПшные классы нужно описывать именно этой конструкцией
2. во-вторых не означает, что этой конструкцией можно описывать только ООПшные классы

A>>Точно так же как и в языках без поддержки ООП из коробки можно самостоятельно сделать своё ООП. В первом случае программиста назовут идиотом, потому что он использует "слишком мало" возможностей языка, во втором случае — потому использует язык, возможностей которого не хватает для избранного подхода к дизайну.
G>И как же люди на haskell или scheme пишут... там вообще классов нет. Да и линукс написан на голом С без классов.
G>Видимо в ООП не так много ценности, что его так игнорируют и не страдают.
Т.е. если кто-то пишет на Haskell, в котором не классов, и у него нет проблем, всем нужно всё бросить и переходить на Haskell?
Есть ещё другие люди — они пишут на C#, в котором есть классы, и у них тоже нет проблем. Всем нужно всё бросить и переходить на C#?
Абсолютно пофигу, если кто-то счастлив работать с инструментами, которые сильно отличаются от моих или ваших. У людей разная мотивация: кто-то "работает программистом", кто-то любит "программирование", а кто-то любит "делать всякие штуки". Первому, очевидно, вообще всё пофигу — лишь бы не уволили. Второй наизусть помнит все задачки из SICP. Третий с большей радостью сделает какой-то новый недопродукт и заставит людей на него смотреть, чем будет вспоминать что делает этот кусок на Scheme, который ещё 10 минут назад казался абсолютно понятным.

G>ЗЫ. Кстати в книге pragmatic programmer, о которой я выше писал, рекомендуется изучать по одному языку в год.
Это одна из моих всею душою любимых книг.

Здравствуйте, gandjustas, Вы писали:

G>Про MVC — нет такого, до GOF цельной инфы об MVC не было, да и GOF не внесли ясности. Разве что тут — http://rsdn.ru/forum/design/5406934.1

Автор: gandjustas
Дата: 23.12.13

У Фаулера была статья, где он разбирал все эти MVC, MVP и т.п. Рассказ, помнится, начинался с утверждения, что нынче обзывают MVC всё что ни попади, а термин идёт от smalltalk и ихний самый первый и потому истинный MVC выглядел так: ... Как он выглядел, не помню, и вообще никакой конкретики оттуда не помню, да и пофиг, потому что меня поразило, насколько все эти паттерны друг на дружку похожи. Буквально: одним крошечным рефакторингом друг в дружку превращаются. Я хз как такое вообще запомнить и имеет ли смысл, если я рефакторингами получу то же самое или даже лучше. На днях появилась у меня версия: мода на баззворды пошла от убогого американского образования. Их учат не систематическому взгляду на мир, а разрозненным howto. Поэтому каждый чих должен иметь своё название.

Здравствуйте, andyag, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, andyag, Вы писали:

A>>>Благодаря тому, что в последние несколько лет в C# регулярно появляется всё больше не-чисто-ООПшных штук, вполне ожидаемо, что в C# комьюнити появляются люди, которые пытаются всё тянуть под эти самые не-ООПшные штуки. Но за этим ничего нет — просто обязательно кто-то будет пытаться убедить оппонента, что в C# можно делать всё по-другому. Можно. А зачем?

G>>1) меньше кода
G>>2) больший контроль со стороны компилятора
G>>3) меньше связность
G>>4) Чистые функции (меньше ошибок)

A>Это ваша субъективная любовь к ФП или есть какие-то исследования, где 2 группы обезьян пишут на ФП и ООП?

А при ем тут любовь? Вполне объективные факторы:
1) используем лямбды — не пишем вручную замыкания в командах (передачу параметров), не пишем сами классы команд — кода меньше, котроля со стороны компилятора больше.
2) Используем чистые фукнции (комбинаторы) — опять таки меньше кода, меньше связность (чистая функция зависит от параметров).
3) Не используем функциональную композицию — снижаем связность между классами и связность по состоянию.
4) про async\await вообще молчу, аснихронных код без async\await и честных замыканий написать нереально сложно.
И дело не только в ФП. Micosoft добивается высокой продуктивности разработчиков на C#, внедряя в язык эти самые паттерны. Просто многие фишки берут из ФЯ, ибо там многие паттерны уже 20-30 лет как реализованы.


A>>>В мире Java есть Groovy — тоже можно не писать классы. К чему это?
G>>Ты не понял? groovy это другой язык, а scriptcs это тот же самый C#, в котором нет необходимости писать классы.
A>До тех пор пока оно не компилируется csc, это не C#. Если вы закрываете на это глаза, Groovy ничем не отличается от Java кроме необязательности классов.
Оно компилируется Roslyn, который и есть компилятор C#, сделанный взамен древнего csc.

A>>>Такая точка появляется при любой попытке заинтегрировать свой LINQ-only код с 99% фреймворков — начиная с MSTest/NUnit, где надо писать классы и вешать на них аттрибуты, и заканчивая ASP.NET WebAPI, где вообще от ApiController наследоваться нужно.
G>>Открою тайну, в ASP.NET 5 уж не нужно ни от чего наследоваться. там все на conventions сделано. Да и раньше достаточно было реализовать IController только. ControllerBase нужен только для того, чтобы методы вызывать без префикса-имени класса. А, как уже писал выше в C# новой версии это не нужно, поэтому и потребность в базовом классе отпала, а да и в каком либо интерфейсе.

A>Не расслышал — вы говорите, всё ещё надо классы писать или мне показалось?
Только как средство группирования методов. Другого пока не придумали в C#. Важно что не используется наследование, полиморфизм и композиция объектов. Даже identity таким объектам не нужен.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>Какие использовались соглашения:
G>>1) Имя класса контроллера заканчивается на Controller
G>>2) Action возвращает ActionResult (хотя может возвращать что угодно, главное не void)
G>>Что из них проверяется компилятором? Внезапно ничего.

D>Если так, то может быть. Но у меня кроме Index() обычно ещё куча всяких вспомогательных методов в контроллере (проверка прав, например; а в случае REST-двигла там вообще развесистый template method), и наследование начинает рулить со страшной силой: code completion, защита от опечаток и т.п.
Для этого фильтры есть, зачем тебе наследование? Или this.UpdateModel(model,form) лучше, чем ModelBinder.UpdateModel(model,form)? Особенно в случае, когда ни this., ни ModelBinder. можно не писать.

D>В этой связи я когда-то высказывался (в теме, называвшейся что-то типа "что вам не нравится в языках, на которых вы пишете") про жаву, что ейные фреймворки целиком на POJO+аннотациях вместо наследования — уничтожают саму идею статики.
Надо по ситуации смотреть, не всегда есть смысл в наследовании от базовых классов. Например в asp.net 5 его нет.

Здравствуйте, Sinix, Вы писали:

S>Для явы — . Она по-моему безнадёжно пропитана паттернами.

В силу своей убогости. Тут даже уместно будет [в целом спорное] утверждение, что паттерн — это поименованный и узаконенный костыль. Отсутствие ФВП фиксим костылём под названием "стратегия". Отсутствие вложенных функций — объектной декомпозицией и приватными методами. Мне тут один джавер на днях выкатил претензию — мол в моей реализации тестового задания слишком глубокая вложенность. МакКоннелом тряс. Ага, давайте лучше контракт класса засрём, даже если и приватными методами — размазанную на сотню маленьких методов логику ему видимо проще читать, чем в одном месте. А на МакКоннела нехай молодняк маструбирует, находящийся на стадии "никогда не делайте то-то"

Автор: Sinclair
Дата: 19.01.06

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

Здравствуйте, dimgel, Вы писали:

D>Если так, то может быть. Но у меня кроме Index() обычно ещё куча всяких вспомогательных методов
Так соглашения по именованию не отменяют наследования, можно писать и в старом стиле.

D>ейные фреймворки целиком на POJO+аннотациях вместо наследования — уничтожают саму идею статики.
Пока от статики "избавились" только там, где она и так особой роли не играла, это просто сахар для DI. Скорее наоборот, ошибок будет меньше: с рослином гораздо проще добавить проверки, которые нарушения соглашений будут ловить на лету, при написании кода.

Здравствуйте, andyag, Вы писали:


A>>>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО.
G>>Прекрасный вывод, но кажется полдня назад ты утверждал что
G>>

A>>>всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны

A>Если есть какое-то противоречие, я его не вижу. Давайте по-другому попробую. Если язык говорит, что через конструкцию "class XXX { ... }" можно описывать ООПшные классы, это:
A>1. во-первых не означает, что ООПшные классы нужно описывать именно этой конструкцией
A>2. во-вторых не означает, что этой конструкцией можно описывать только ООПшные классы
Логическую нестыковку выделил. В процитированном фрагменте был смысл что нужно писать классы и они являются априори ООП (что на самом деле не так).
Какое будет финальное мнение?


A>Т.е. если кто-то пишет на Haskell, в котором не классов, и у него нет проблем, всем нужно всё бросить и переходить на Haskell?
Нет, это ишь говорит, что в аскеле достаточно средств, чтобы писать код и не использовать ООП.

A>Есть ещё другие люди — они пишут на C#, в котором есть классы, и у них тоже нет проблем. Всем нужно всё бросить и переходить на C#?
Это еще не значит, что используют ООП.

A>Абсолютно пофигу, если кто-то счастлив работать с инструментами, которые сильно отличаются от моих или ваших. У людей разная мотивация: кто-то "работает программистом", кто-то любит "программирование", а кто-то любит "делать всякие штуки". Первому, очевидно, вообще всё пофигу — лишь бы не уволили. Второй наизусть помнит все задачки из SICP. Третий с большей радостью сделает какой-то новый недопродукт и заставит людей на него смотреть, чем будет вспоминать что делает этот кусок на Scheme, который ещё 10 минут назад казался абсолютно понятным.
К чему эта фраза? Увести разговор от обсуждения пользы паттернов и ООП в современных языках?

G>>ЗЫ. Кстати в книге pragmatic programmer, о которой я выше писал, рекомендуется изучать по одному языку в год.
A>Это одна из моих всею душою любимых книг.
и тем не менее

A>изучением миллионов языков я уже переболел

Здравствуйте, gandjustas, Вы писали:

G>Для этого фильтры есть, зачем тебе наследование? Или this.UpdateModel(model,form) лучше, чем ModelBinder.UpdateModel(model,form)? Особенно в случае, когда ни this., ни ModelBinder. можно не писать.

ХЗ что такое фильтры, но подозреваю, это что-то C#-specific, а у меня скала. В шарпе есть какая-то мулька, аналогичная скаловским implicits, но я всё время забываю, как она называется (ты её уже упоминал в этой ветке). Но implicits я не люблю: нагрузка на компилятор и запутывание кода. Хотя для пущей красивости DSL-ей иногда приходится.

Здравствуйте, gandjustas, Вы писали:

G>Для этого фильтры есть, зачем тебе наследование?

Кроме того, наследование (особенно template method, конкретно мною сделанный и полностью меня устраивающий) помогает структурировать мозги и код. А ещё по нему проще понять, что ожидается от реализации, чем от расположенных хрен знает где (и скорее всего даже не в одном месте, если среди них есть и библиотечные, и app-specific) третьих методов, пользы от которых для читаемости и обучения ничуть не больше, чем от жавовских аннотаций.

UPD. Т.е. слабая связность имеет и свои обратные стороны (которые, кстати, тут неоднократно упоминались в контексте DI-фреймворков): когда код вообще ни хрена не связан, концы вообще хрен найдёшь.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>Для этого фильтры есть, зачем тебе наследование? Или this.UpdateModel(model,form) лучше, чем ModelBinder.UpdateModel(model,form)? Особенно в случае, когда ни this., ни ModelBinder. можно не писать.

D>ХЗ что такое фильтры, но подозреваю, это что-то C#-specific, а у меня скала.
Ничего там C#-specific нет, просто набор объектов-обработчиков (паттерн chain of responsibility). При желании можно навешивать в виде атрибутов на классы\методы (для большей гранулярности)

D>В шарпе есть какая-то мулька, аналогичная скаловским implicits, но я всё время забываю, как она называется (ты её уже упоминал в этой ветке).
Extension methods называется.

D>Но implicits я не люблю: нагрузка на компилятор и запутывание кода. Хотя для пущей красивости DSL-ей иногда приходится.
По этому поводу есть рекомендации в FDG для C#.

Здравствуйте, gandjustas, Вы писали:

G>Extension methods называется.

Угу, они самые.

G>По этому поводу есть рекомендации в FDG для C#.

Англичанин русскому: с моста прыгать нельзя!
Русский: да плевал я на ваши запреты!

UPD. Я имею в виду, что нету у меня желания забивать голову чтивом в таком объёме, который ты осилил за сравнительно короткий срок, превратившись в тутошнего гуру (ну или активно претендуя на ). Я всю жизнь на позициях простого девелопера, вечное пиши-код-[beep].рф (сайтец кстати давно заблокировали), и привык проверять всё своим собственным лбом. Долго, но интересно. И очень надёжно.

D>Здравствуйте, gandjustas, Вы писали:

G>>Для этого фильтры есть, зачем тебе наследование?

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

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>Для этого фильтры есть, зачем тебе наследование?

D>Кроме того, наследование (особенно template method, конкретно мною сделанный и полностью меня устраивающий) помогает структурировать мозги и код. А ещё по нему проще понять, что ожидается от реализации, чем от расположенных хрен знает где (и скорее всего даже не в одном месте, если среди них есть и библиотечные, и app-specific) третьих методов, пользы от которых для читаемости и обучения ничуть не больше, чем от жавовских аннотаций.

В asp.net mvc все построено на конвенциях. По умолчанию, если ты вызываешь /home/index, то ищется HomeController, в нем ищется метод Index. который должен вернуть IActionResult. Все, остальное не забота фреймворка и разруливается программистом. Причем ASP.NET MVC сам подсказывает что нужно сделать. Он честно скажет что не найден метод в таком-то классе и такой-то сигнатурой.

Кстати IActionResult имеет один метод Execute и вообще не было бы смысла плодить интерфейс, если бы делегаты работали быстрее и можно было делать алиасы для типов.

D>UPD. Т.е. слабая связность имеет и свои обратные стороны (которые, кстати, тут неоднократно упоминались в контексте DI-фреймворков): когда код вообще ни хрена не связан, концы вообще хрен найдёшь.
Ну это банальная история. Пишется код, который разбивается на набор классов, вызывающих друг друга. Потом для покрытия тестами создаются везде интерфейсы и ссылки на классы заменяются на ссылки на интерфейсы, а экземпляры подсовываются через IOC. Дальше оказывается, что внесение изменений требует правки интерфейса, класса и пересборки всех ссылающихся на интерфейс. Тогда приходит в голову гениальная идея, вместо прямого вызова сделть "общую шину", через которую вызывать другие классы и все, концов уже не найдешь.


А всего-то надо было не заморачиваться с тестами.

Здравствуйте, gandjustas, Вы писали:

G>Ну это банальная история.

История действительно банальная,

G>А всего-то надо было не заморачиваться с тестами.

но вывод, мягко говоря, спорный. Правильный вывод должен быть другим: серебрянных пуль нет, и больших семь шапок из овцы сложную логику в простой код невозможно впихнуть в принципе. UPD: а ещё — что тестирование "снизу вверх" без моков рулит.

Здравствуйте, dimgel, Вы писали:

D>>Здравствуйте, gandjustas, Вы писали:

G>>>Для этого фильтры есть, зачем тебе наследование?

D>Короче говоря, зачем мне фильтры, если есть наследование. У меня вообще складывается ощущение, что тут многие ненавидят ООП просто за то, что вот они его любили, а оно их разочаровало: оказалось не серебрянной пулей, а просто одним из паттернов. И они теперь принципиально не юзают его вообще нигде, даже там, где оно вполне нормально ложится.

Ну например затем, что фильтры можно утащить в другой проект, а код написанный внутри класса можно утащить только копипастой. Хотя предполагалось что ООП улучшает реюз, поэтому и не нравится. Реюз через наследование — слишком хреновый способ.

Здравствуйте, gandjustas, Вы писали:

G>В asp.net mvc все построено на конвенциях. По умолчанию, если ты вызываешь /home/index, то ищется HomeController, в нем ищется метод Index. который должен вернуть IActionResult. Все, остальное не забота фреймворка и разруливается программистом. Причем ASP.NET MVC сам подсказывает что нужно сделать. Он честно скажет что не найден метод в таком-то классе и такой-то сигнатурой.

Если он это скажет как compile error, то всё хорошо. Как раз сейчас я все свои наработки перефигачиваю под макросы именно с этой целью: некоторые иерархии, непроверяемые соглашения и т.п. превратить в соглашения, проверяемые на этапе компиляции макросами. Но не все, повторюсь; некоторые не смогу просто в силу ограничений макросов (начинаю уже почёсывать репу в сторону плагина компилятора — там возможностей вроде и не сильно больше, но для ряда сценариев это "несильно" оказывается ключевым), а кое-где меня ООП вполне устраивает.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>В asp.net mvc все построено на конвенциях. По умолчанию, если ты вызываешь /home/index, то ищется HomeController, в нем ищется метод Index. который должен вернуть IActionResult. Все, остальное не забота фреймворка и разруливается программистом. Причем ASP.NET MVC сам подсказывает что нужно сделать. Он честно скажет что не найден метод в таком-то классе и такой-то сигнатурой.

D>Если он это скажет как compile error, то всё хорошо.
Не скажет, ибо не знает никаким образом, что запрос придет на /home/index

Здравствуйте, gandjustas, Вы писали:

D>>Короче говоря, зачем мне фильтры, если есть наследование.

G>Ну например затем, что фильтры можно утащить в другой проект, а код написанный внутри класса можно утащить только копипастой. Хотя предполагалось что ООП улучшает реюз, поэтому и не нравится. Реюз через наследование — слишком хреновый способ.

Что реюз через наследование хренов, спорить глупо. Но реюз вообще хренов. Потому что в новом проекте мне почти всегда вдруг требуется какой-нибудь пустяковый преподвыподверт, в реюзанное не ложащийся. И кстати, совершенно пофиг, речь идёт про новый проект, новый модуль в том же проекте или вообще соседний метод в том же классе. Во всех случаях я буду рефакторить и подкручивать существующее API: в границах проекта оно зацепит все сорцы, где уже используется, а в новый проект — копипаста рулит, если не хочется трогать старый проект. (А вообще, it depends: иногда дешевле и/или выгоднее исправить и юзать общий код в нескольких проектах. Но оно по жизни всё так — it depends; с этой формулировочкой наперевес даже и спорить как-то скучно и не о чем.)

Здравствуйте, gandjustas, Вы писали:

D>>Если он это скажет как compile error, то всё хорошо.
G>Не скажет, ибо не знает никаким образом, что запрос придет на /home/index

Ну и низачот, чё. А у меня — скажет, потому что в моём абстрактном классе Page, кроме абстрактоного метда service() есть ещё uri(params: (String, String)*) (в реализациях по желанию добавляются overloaded статически типизированные uri(ParamObject)), и если хоть одна страница на данную ссылается, она вызывает её uri() для генерации ссылки, и ссылку на несуществующую страницу я при такой модели не пропущу. Про метод checkRights() я уже говорил... А в рамках вот этого повально популярного идиотизма с методом-на-URI вместо класса-на-URI такое не сделать, разве что ввести очередное naming convention типа Index_CheckRights, Index_URI и т.п. Которое, впрочем, компилятором опять же не проверится, так что один хрен низачот. Это раз.

Во-вторых, хрен отличишь обычный метод от HTTP-замапенного. В спринге это решается очередной <матерно>аннотацией</матерно>. Точнее, сразу несколькими (на класс, на метод, на параметры). В общем, утяжеляется всё сразу и резко.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

D>>>Если он это скажет как compile error, то всё хорошо.
G>>Не скажет, ибо не знает никаким образом, что запрос придет на /home/index

D>Ну и низачот, чё. А у меня — скажет, потому что в моём абстрактном классе Page, кроме абстрактоного метда service() есть ещё uri(params: (String, String)*) (в реализациях по желанию добавляются overloaded статически типизированные uri(ParamObject)), и если хоть одна страница на данную ссылается, она вызывает её uri() для генерации ссылки, и ссылку на несуществующую страницу я при такой модели не пропущу. Про метод checkRights() я уже говорил... А в рамках вот этого повально популярного идиотизма с методом-на-URI вместо класса-на-URI такое не сделать, разве что ввести очередное naming convention типа Index_CheckRights, Index_URI и т.п. Которое, впрочем, компилятором опять же не проверится, так что один хрен низачот. Это раз.
Ну в ASP.NET MVC с первых версий есть хелперы, которые позволяют писать так:

Html.ActionLink<CatalogController>(c => c.Product(id))

И в разметке появится ссылка /Ctatalog/Product/{id}, ессено проверятся при компиляции. И для этого вовсе не надо контроллеры нагружать генерацией ссылок.

Да и не очень понятно зачем uri в классе Page, это ведь надо инстанцировать Page для получения ссылки.


D>Во-вторых, хрен отличишь обычный метод от HTTP-замапенного. В спринге это решается очередной <матерно>аннотацией</матерно>. Точнее, сразу несколькими (на класс, на метод, на параметры). В общем, утяжеляется всё сразу и резко.
В MVC по умолчанию работают соглашения, но при желании можно обвешать все атрибутами. Это смотря что тебе удобнее.

Здравствуйте, gandjustas, Вы писали:

G>Да и не очень понятно зачем uri в классе Page, это ведь надо инстанцировать Page для получения ссылки.

Page у меня stateless, я их инстанциирую при запуске в том же духе, как и BL-контроллеры. (UPD: Простыня, выполняющая связывание, генерируется автоматически.)

G>В MVC по умолчанию работают соглашения, но при желании можно обвешать все атрибутами. Это смотря что тебе удобнее.

Понятно, полный комплект извращений, выбирай на вкус. А мне удобнее так, как я написал.

D>Здравствуйте, gandjustas, Вы писали:

G>

G>Html.ActionLink<CatalogController>(c => c.Product(id))
G>

Длинно. И опять же, доведённая до абсурда философия развязывания всего и вся мне не нравится: геморрою больше, чем пользы. И ещё: а если у страницы несколько параметров, и часть идут в path, часть в query string?

G>И для этого вовсе не надо контроллеры нагружать генерацией ссылок.

Нет, наоборот. Если в одном и том же месте — в подклассе Page — URL и генерируется, и парсится, это очень хорошо, легко на одном экране проверить симметричность кода, "и для этого вовсе не надо" (с) городить внешние хелперы.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, andyag, Вы писали:

A>>>>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО.
G>>>Прекрасный вывод, но кажется полдня назад ты утверждал что
G>>>

A>>>>всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны

A>>Если есть какое-то противоречие, я его не вижу. Давайте по-другому попробую. Если язык говорит, что через конструкцию "class XXX { ... }" можно описывать ООПшные классы, это:
A>>1. во-первых не означает, что ООПшные классы нужно описывать именно этой конструкцией
A>>2. во-вторых не означает, что этой конструкцией можно описывать только ООПшные классы
G>Логическую нестыковку выделил. В процитированном фрагменте был смысл что нужно писать классы и они являются априори ООП (что на самом деле не так).
G>Какое будет финальное мнение?

Давайте ещё раз попробуем:

Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО.

Теоретически почти на любом ЯП можно использовать почти любую парадигму программирования. Можно заниматься ФП на C#, это всегда потребует как минимум одного класса как минимум с одним методом. Наличие класса с методом в этом случае не будет частью вашего дизайна, это будет просто выполнением требований языка.

всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны

Практически любой код не имеет смысла без интеграции с внешним миром. Интеграция с внешним миром достигается через применение библиотек/фреймворков. Выбрав язык, вы одновременно выбираете и внешний мир. Когда вы делаете выбор в пользу C#, оказывается, что абсолютное большинство библиотек — "объекто ориентированные". Простой пример — реализация веб-сервиса. Вы берёте ASP.NET Web API и внезапно выясняется, что есть какие-то объекты-контроллеры, что для конструирования этих объектов-контроллеров вам предлагается описать другие объекты (типа IDependencyResolver, которые по сути своей являются реализацией паттерна проектирования service locator), а чтобы не изобретать велосипед, вы скорее всего возьмёте готовый IoC-контейнер типа Unity или Ninject, которые по своей сути являются чем-то вроде обобщённой фабрики. В итоге часть вашего решения будет иметь ФП-дизайн, а часть ООП-дизайн. Причём в контексте C# (чтобы не вылезло ещё одно противоречие: речь всё ещё идёт про интеграцию с внешним миром) гарантированно будет ООП, а ФП вполне может не быть.

A>>Т.е. если кто-то пишет на Haskell, в котором не классов, и у него нет проблем, всем нужно всё бросить и переходить на Haskell?
G>Нет, это ишь говорит, что в аскеле достаточно средств, чтобы писать код и не использовать ООП.
Хорошо. Т.е. ваше утверждение сводится к простому "на Haskell можно писать код". Что вы пытались сказать?

A>>Есть ещё другие люди — они пишут на C#, в котором есть классы, и у них тоже нет проблем. Всем нужно всё бросить и переходить на C#?
G>Это еще не значит, что используют ООП.
Если это не теоретики-исследователи, совершенно точно используют в том или ином виде. Чуть выше описал почему.

A>>Абсолютно пофигу, если кто-то счастлив работать с инструментами, которые сильно отличаются от моих или ваших. У людей разная мотивация: кто-то "работает программистом", кто-то любит "программирование", а кто-то любит "делать всякие штуки". Первому, очевидно, вообще всё пофигу — лишь бы не уволили. Второй наизусть помнит все задачки из SICP. Третий с большей радостью сделает какой-то новый недопродукт и заставит людей на него смотреть, чем будет вспоминать что делает этот кусок на Scheme, который ещё 10 минут назад казался абсолютно понятным.
G>К чему эта фраза? Увести разговор от обсуждения пользы паттернов и ООП в современных языках?
Эта фраза выражает мою точку зрения на ваше настроение "изучать ФП и SICP — круто, изучать паттерны — фигня". Мысль, которую я пытаюсь донести, очень проста: можно знать ФП, можно не знать ФП. Знать ФП не необходимо. Давайте ещё напомню с чего топик начался: я попросил подсказать литературу по конкретным темам. С тех пор вы неустанно пытаетесь меня убедить, что такая литература не нужна

G>>>ЗЫ. Кстати в книге pragmatic programmer, о которой я выше писал, рекомендуется изучать по одному языку в год.
A>>Это одна из моих всею душою любимых книг.
G>и тем не менее
G>

A>>изучением миллионов языков я уже переболел

Снова какое-то противоречие на пустом месте? Мне извиниться, что в этом году я задрачиваюсь по JavaScript, а не по Scheme?

Здравствуйте, andyag, Вы писали:

A>

A>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО.

A>Теоретически почти на любом ЯП можно использовать почти любую парадигму программирования. Можно заниматься ФП на C#, это всегда потребует как минимум одного класса как минимум с одним методом. Наличие класса с методом в этом случае не будет частью вашего дизайна, это будет просто выполнением требований языка.
Это неверно. Если у тебя нет ФВП в языке, то практически тебе недоступно ФП (как в Java ранних версий). Если тебе недоступен динамический полиморфизм по неявному аргументу через указатель на объект, то у тебя нет ООП (как в haskell без расширений).


A>

A>всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны

A>Практически любой код не имеет смысла без интеграции с внешним миром. Интеграция с внешним миром достигается через применение библиотек/фреймворков. Выбрав язык, вы одновременно выбираете и внешний мир. Когда вы делаете выбор в пользу C#, оказывается, что абсолютное большинство библиотек — "объекто ориентированные". Простой пример — реализация веб-сервиса. Вы берёте ASP.NET Web API и внезапно выясняется, что есть какие-то объекты-контроллеры, что для конструирования этих объектов-контроллеров вам предлагается описать другие объекты (типа IDependencyResolver, которые по сути своей являются реализацией паттерна проектирования service locator), а чтобы не изобретать велосипед, вы скорее всего возьмёте готовый IoC-контейнер типа Unity или Ninject, которые по своей сути являются чем-то вроде обобщённой фабрики. В итоге часть вашего решения будет иметь ФП-дизайн, а часть ООП-дизайн. Причём в контексте C# (чтобы не вылезло ещё одно противоречие: речь всё ещё идёт про интеграцию с внешним миром) гарантированно будет ООП, а ФП вполне может не быть.

Ты неверно понимаешь ООП. ООП это не наличие классов. Это проектирование приложения, через композицию объектов и полиморфизм через наследование.
Реализация интерфейса фактически не является ни в каком роде ООП, просто в языке типа C# нет другим способов объявить несколько связанных методов, кроме как создать класс, который реализует интерфейс.

Берем тот же MVC. В теории мы там наследуемся от класса controller на практике не переопределяем ни одного метода, то есть никакого полиморфизма нет, а наследование — просто кривой способ удовлетворения контракта, ибо другого не было на момент создания MVC. IDependencyResolver — отличный пример, который можно без потери функциональности заменить одной ФВП — Func<Type, IEnumerable<object>>. Но в C# нельзя алиас типа сделать, поэтому для лучшей читабельности делают интерфейс и реализацию в виде класса. То есть снова интерфейсы и классы — деталь реализации, зависящая от особенностей языка, а вовсе не от того, что это какие то паттерны.
Паттерны — лишь следствие особенностей языка, а не основополагающий аспект проетирования. Поэтому изучать паттерны большого смысла не имеет, скорее всего любое умышленное применение паттернов будет вредным.


A>Эта фраза выражает мою точку зрения на ваше настроение "изучать ФП и SICP — круто, изучать паттерны — фигня". Мысль, которую я пытаюсь донести, очень проста: можно знать ФП, можно не знать ФП. Знать ФП не необходимо. Давайте ещё напомню с чего топик начался: я попросил подсказать литературу по конкретным темам.
Если ФП поменять на "паттерны" будет то же самое. Тем не менее программисты, знающие ФП, на практике оказываются на голову лучше, тех, кто не знает. А вот с паттернами такое не наблюдается (особенно с теми, что GOF).

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

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, andyag, Вы писали:

A>>

A>>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО.

A>>Теоретически почти на любом ЯП можно использовать почти любую парадигму программирования. Можно заниматься ФП на C#, это всегда потребует как минимум одного класса как минимум с одним методом. Наличие класса с методом в этом случае не будет частью вашего дизайна, это будет просто выполнением требований языка.
G>Это неверно. Если у тебя нет ФВП в языке, то практически тебе недоступно ФП (как в Java ранних версий).

Вы наверное не знакомы с Java. Давайте расскажу. Вот так делалось ФП в Java до 1.8:

interface Func1<TResult, TArg1> {
  TResult apply(TArg1 arg1);
}

interface Func2<TResult, TArg1, TArg2> {
  TResult apply(TArg1 arg1, TArg2 arg2);
}
...
Func1<TResult, TArg2> bindFirst(Func2<TResult, TArg1, TArg2> func2, TArg1 arg1) {
  return new Func1<TResult, TArg2>() {
    TResult apply(TArg2 arg2) {
      return func2.apply(arg1, arg2);
    }
  };
}

Func2<Integer, Integer, Integer> add = new Func2() {
  Integer apply(Integer a, Integer b) {
    return a + b;
  }
};

Func1<Integer, Integer> addFive = bindFirst(add, 5);
int result = addFive.apply(3);
assertEquals(8, result);

Длинно и страшно — да. Невозможно — нет.

С выходом Java 1.8 появился синтаксический сахар: когда нужно реализовать интерфейс с единственным методом, можно делать вот так:

Func2<Integer, Integer, Integer> add = (a, b) -> a + b;

Поменялся только синтаксис языка — стало немного меньше мусора, но работает оно точно так же как и раньше. Даже вызов этих Func2 остаётся прежним:

int result = add.apply(2, 3);

G>Если тебе недоступен динамический полиморфизм по неявному аргументу через указатель на объект, то у тебя нет ООП (как в haskell без расширений).
Я не знаю где вы взяли эти критерии — скорее всего с потолка.
1. Посмотрите например на Майкрософтовский COM — это яркий пример объектно-ориентированного дизайна на не-ОО языке.
2. Вот тут аж целая книжка "Object-Oriented Programming With ANSI-C": http://www.cs.rit.edu/~ats/books/ooc.pdf
Снова, длинно и страшно — да. Невозможно — нет..

A>>Практически любой код не имеет смысла без интеграции с внешним миром. Интеграция с внешним миром достигается через применение библиотек/фреймворков. Выбрав язык, вы одновременно выбираете и внешний мир. Когда вы делаете выбор в пользу C#, оказывается, что абсолютное большинство библиотек — "объекто ориентированные". Простой пример — реализация веб-сервиса. Вы берёте ASP.NET Web API и внезапно выясняется, что есть какие-то объекты-контроллеры, что для конструирования этих объектов-контроллеров вам предлагается описать другие объекты (типа IDependencyResolver, которые по сути своей являются реализацией паттерна проектирования service locator), а чтобы не изобретать велосипед, вы скорее всего возьмёте готовый IoC-контейнер типа Unity или Ninject, которые по своей сути являются чем-то вроде обобщённой фабрики. В итоге часть вашего решения будет иметь ФП-дизайн, а часть ООП-дизайн. Причём в контексте C# (чтобы не вылезло ещё одно противоречие: речь всё ещё идёт про интеграцию с внешним миром) гарантированно будет ООП, а ФП вполне может не быть.

G>Ты неверно понимаешь ООП. ООП это не наличие классов. Это проектирование приложения, через композицию объектов и полиморфизм через наследование.
G>Реализация интерфейса фактически не является ни в каком роде ООП, просто в языке типа C# нет другим способов объявить несколько связанных методов, кроме как создать класс, который реализует интерфейс.

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

G>Берем тот же MVC. В теории мы там наследуемся от класса controller на практике не переопределяем ни одного метода, то есть никакого полиморфизма нет, а наследование — просто кривой способ удовлетворения контракта, ибо другого не было на момент создания MVC. IDependencyResolver — отличный пример, который можно без потери функциональности заменить одной ФВП — Func<Type, IEnumerable<object>>. Но в C# нельзя алиас типа сделать, поэтому для лучшей читабельности делают интерфейс и реализацию в виде класса. То есть снова интерфейсы и классы — деталь реализации, зависящая от особенностей языка, а вовсе не от того, что это какие то паттерны.

Вот снова вы. Конечно можно. Можно вообще все API ASP.NET сделать функциональными. Но это только у вас в голове, а на практике там ОО.

A>>Эта фраза выражает мою точку зрения на ваше настроение "изучать ФП и SICP — круто, изучать паттерны — фигня". Мысль, которую я пытаюсь донести, очень проста: можно знать ФП, можно не знать ФП. Знать ФП не необходимо. Давайте ещё напомню с чего топик начался: я попросил подсказать литературу по конкретным темам.
G>Если ФП поменять на "паттерны" будет то же самое. Тем не менее программисты, знающие ФП, на практике оказываются на голову лучше, тех, кто не знает. А вот с паттернами такое не наблюдается (особенно с теми, что GOF).

Это только ваша субъективная статистика. Я предпочёл бы, чтобы у многих моих коллег был GoF головного мозга, вместо того, что у них там сейчас. Я искренне предпочёл бы, чтобы джуниор писал всем ненавистный синглтон вместо статического класса с состоянием. Просто потому что синглтон лучше поддаётся рефакторингу в сторону DI. Но это, снова, субъективно.

Здравствуйте, dimgel, Вы писали:

D>>Здравствуйте, gandjustas, Вы писали:

G>>

G>>Html.ActionLink<CatalogController>(c => c.Product(id))
G>>

D>Длинно. И опять же, доведённая до абсурда философия развязывания всего и вся мне не нравится: геморрою больше, чем пользы.
Можно и сократить. Главное — собственно в вызове
D>И ещё: а если у страницы несколько параметров, и часть идут в path, часть в query string?
Тогда этот код начинает рулить ещё сильнее, т.к. изменения routing автоматически учитываются. Фреймворк берёт метод и ищет его роут, подставляя параметры ровно куда надо.
D>Нет, наоборот. Если в одном и том же месте — в подклассе Page — URL и генерируется, и парсится, это очень хорошо, легко на одном экране проверить симметричность кода, "и для этого вовсе не надо" (с) городить внешние хелперы.
Это верно. Просто в нормальном случае URL в классе Page не парсится. оттого и генерировать его там никакого желания нет.

Здравствуйте, LaptevVV, Вы писали:

LVV>То есть это все говорит, что нужно писать единую книжку.

LVV>Кто б из наших гуру занялся бы, а?
LVV>А я б редактировал.

Стань этим гуру — отредактируй книгу целиком.

+-----------------+
|                 |
|   Лаптев В.В.   |
|                 |
|   Всё об ООП    |
|                 |
|                 |
|                 |
|  Издательство   |
|      КЫВТ       |
|                 |
|      2015       |
+-----------------+

Здравствуйте, AleksandrN, Вы писали:

AN>Здравствуйте, LaptevVV, Вы писали:

LVV>>То есть это все говорит, что нужно писать единую книжку.

LVV>>Кто б из наших гуру занялся бы, а?
LVV>>А я б редактировал.

AN>Стань этим гуру — отредактируй книгу целиком.

AN>

AN>+-----------------+
AN>|                 |
AN>|   Лаптев В.В.   |
AN>|                 |
AN>|   Всё об ООП    |
AN>|                 |
AN>|                 |
AN>|                 |
AN>|  Издательство   |
AN>|      КЫВТ       |
AN>|                 |
AN>|      2015       |
AN>+-----------------+
AN>

Дык ее сначала написать надо.
А чтоб тебе было понятно, что я не с бодуна о редактировании написал — я редактировал вот эту книгу: http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/table_of_contents.html
Естественно, в переводе. Но пришлось читать оригинал, ибо переводчик явно использовал не мозги, а программу...

A>Посоветуйте пожалуйста.

Почти оффтоп.

Design Patterns in Dynamic Languages. http://www.norvig.com/design-patterns/

В функциональных языках многие паттерны органически «вшиты» в сам язык.