Re: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 24.03.14 09:12
Оценка: +7
Здравствуйте, -rsdn-, Вы писали:

R>нужны примеры с учетом платформы и языка программирования

По-моему, единственный работающий способ использовать паттерны — не вспоминать про них вовсе. Гораздо полезней изучить Рихтера и Framework Design Guidelines и использовать здравый смысл и знание матчасти.


R>в частности интересно что такое связность от связанность (cohesion & coupling)

Кстати, cohesion обычно как сцепление переводится.

Если на пальцах:
* сoupling — это мера, определяющая, насколько различные модули приложения зависят один от другого,
* cohesion — насколько функционал отдельного модуля однороден.

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

Гораздо проще описать cohesion-vs-coupling в терминах разделения ответственности ака "слона едят по кусочкам".

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

Слабая связанность (coupling) означает, что делегировав задачу, исходный модуль не пытается вмешиваться в дальнейший процесс её решения и не завязывается на конкретные детали реализации модулей, которым он передал кусочки исходной задачи.

Смысл такого разделения — в локализации ответственности и в уменьшении исправлений в зависимом коде.
Re: паттерны экслюзивно для .net c#
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 30.03.14 09:30
Оценка: 136 (4)
Здравствуйте, -rsdn-, Вы писали:

R>нужны примеры с учетом платформы и языка программирования

R>в частности интересно что такое связность от связанность (cohesion & coupling)

О паттернах

Тут уже выше давали ссылку, что я начал публикацию постов именно по теме паттернов программирования в .NET, с примерами с учетом платформы .NET и языка программирования C#.

Хотя есть масса примеров GoF паттернов привязанной к платформе и языку программирования, я бы сказал, что паттерны больше привязаны к парадигме программирования (OOP vs. FP) нежели к языку, хотя культурные особенности платформы тоже присутствуют.

Вот несколько примеров:

Шаблонный Метод

Основная суть шаблонного метода в том, что базовый класс задает каркас алгоритма, а наследник переопределяет недостающие куски, но что если вместо наследования переменные шаги задавать с помощью анонимных методов? Поскольку C# в этом плане является мультипарадигменным языком (ОО + FP фичи), то этот подход вполне оправдан. Подход на основе делегатов является очень популярным решением, хотя и применяется зачастую локально в классе (я назвал его локальным методом шаблона). С другой стороны, локальный метод шаблона часто используется для выполнения некоторых действий не зависимо от исхода "основного шага алгоритма", что в других языках (таких как С++) реализуется с помощью идиомы RAII — Resource Aquisition is Initialization. Эта же идиома используется и в языке C# в виде блока using и Disposable паттерна (который является одним из многих платформенно-зависимых паттернов проектирования).

Но в C# есть и еще одна возможность, которая может быть использована для реализации паттерна Шаблонный Метод — методы расширения. В классическом шаблонном метод каркас алгоритма задается в виде (неполиморфного) метода базового класса, а шаги задаются за счет переопределения (обычно) защищенных методов. Но что если мы зададим алгоритм шаблонного метода вне базового класса — с помощью метода расширения, а переменные шаги делегируем открытым виртуальным методам интерфейса или абстрактного класса? (привет, LINQ) В некотором роде этот подход можно рассматривать как разновидность шаблонного метода, специфичного для конкретного языка программирования. Сходство будет более очевидным, если посмотреть на другие языки, такие как Java, в которой появилась аналогичная возможность, но несколько под другим соусом в виде Default Method Implementation.

Итератор

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

Так, например, итератор в .NET представлен интерфейсами IEnumerable/IEnumerator и IEnumerable<T>/IEnumerator<T>, который является однонаправленным итератором только для чтения. При этом в других языках/платформах итераторы другие. Так, в С++ их огромное множество: есть однонаправленные, двунаправленные, random-access, реверсные итераторы и т.п.

С другой стороны, в языке C# есть синтаксический сахар для создания итераторов/генераторов — так называемый блок итераторов (подробнее смотри в Итераторы в C#. Часть 1, Часть 2, Часть 3). При этом блок итераторов начинает смещать акцент с итераторов к генераторам, граница которых начинает стираться.

Визитор

Есть такая общая проблема в computer science под названием expression problem, основная идея которой заключается в том, что разные парадигмы программирования предоставляют "точки расширения" в одной плоскости, усложняя расширение в другой. Так, в ООП очень легко добавить новый тип в иерархию типов и переопределить пару виртуальных методов (тот самый принцип Открыт-Закрыт), но при этом сложности возникают при попытке добавить новый абстрактный метод в базовый тип иерархии. С другой стороны, ФП и структурное программирование легко позволяет добавить новую операцию над семейством типов (в ФП языках за счет pattern-matching-а), усложняя добавление нового типа в это семейство.

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

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

О cohesion&coupling

Эти два понятия являются фундаментальными понятиями в проектировании ПО, хотя они применимы и за его пределами.
Давай рассмотрим распределенную команду разработчиков. Как сделать ее максимально эффективно? Для этого нужно сосредоточить в одной локацию людей, которые будут заниматься решением одной задачи с возможно минимальным количеством взаимодействия с другими локациями (это и есть low coupling), при этом решать эта команда должна работать не над разнородными задачами, а решать одну или родственные задачи (это и есть high cohesion).

Эта проблема есть и в дизайне. Класс/модуль/приложение должны минимально зависеть от других классов/модулей/приложений, что позволит думать, развивать и улучшать класс/модуль/приложение самостоятельно не ломая и не задумываясь о соседях (это low couping). При этом класс/модуль/приложение должен решать связанный набор задач, а не быть швейцарским ножом, который умеет гайки закручивать, отчеты отправлять и в базу данных ходить (это high cohesion; нарушение Single Responsibility Principla обычно подразумевает слабый cohesion).

При этом low couling подразумевает не только то, что класс должен знать о минимальном числе других классов (это самый простой вид каплинга — физический каплинг), но и зависеть от минимального числа других классов/модулей логически. Именно логическая связанность является самой злой, когда один класс предполагает, что в корне приложения есть код, который поместил реализацию этого интерфейса в контейнер; или предполагает, что некоторый код сохранил файл в определенном месте в определенном формате; или предполагает, что есть некий другой класс, который будет публиковать события через event aggregator. Нужно понимать, что слабая связанность подразумевает возможность анализа и развития класса А в отрыве от класса Б, не зависимо от того, знает ли класс А о существовании класса Б или лишь рассчитывает на его существование.

Coupling и паттерны программирования

Есть довольно простая, но весьма хорошая книга о паттернах проектирования, под названием Head-First Design Patterns, там есть хорошая фраза:
(основная суть паттернов проектирования): выделите переменные составляющие и инкапсулируйте их, чтобы позднее их можно было изменять или расширять без воздействия на постоянные составляющие..

В целом, эта мысль пронизывает и всю книгу банды четырех: как инкапсулировать процесс создания семейства объектов (абстрактная фабрика) так, чтобы клиенты не задумывались о конкретных типах? Как инкапсулировать процесс обхода составного объекта так, чтобы клиенты не знали о его внутренней структуре (итератор)? Как бесшовно добавлять новую функциональность, чтобы клиенты класса этого не замечали (декоратор) и т.п?

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

З.Ы. У Ayende есть цикл постов по этой же теме — Design Patterns in the Test of Time
Re[13]: паттерны экслюзивно для .net c#
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.04.14 09:49
Оценка: 20 (1) +2
Здравствуйте, Sinix, Вы писали:
S>
Ещё раз повторяю, медленно: то, что на одном языке реализуется при помощи паттерна, на другом языке может быть реализовано языковой конструкцией.
Понимаете? Это никак не делает термин "паттерн" баззвордом, который не обозначает ничего.

Это делает некоторые паттерны неактуальными в языках, оборудованных соответствующими конструкциями.
То есть, например, если кто-то фигачит в Delphi или C# парные методы типа getMouthWidth / setMouthWidth, не вводя Property, его надо немедленно удавить логарифмической линейкой.
Если кто-то в C# начинает городить иерархию классов publisher/subscriber — то же самое.
Или если кто-то начинает в С фигачить цикл на основе goto.

Всё это никак не отменяет важности и полезности паттернов вроде "цикл" в программах на RISC-ассемблерах.
И всё это никак не означает какой-то святости паттернов, описанных как GoF, так и Фаулером.
Если у вас нет тех проблем, которые решаются предложенными ими паттернами — не нужны и паттерны. Если есть готовые средства решения проблем — паттерны опять не нужны, можно просто взять готовые средства.

Это, по-моему, элементарные всё вещи.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: паттерны экслюзивно для .net c#
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.03.14 06:46
Оценка: +3
Здравствуйте, Sinix, Вы писали:

S>Неа, тут та же путаница: рефакторинг — это общее описание проблемы ("фиговый код, нужно улучшить"). Замена стратегии на Func/Action — это конкрентый инструмент.


Рефакторинг это не описание проблемы, это просто безопасные преобразования кода. Дело не в улучшении, а в изменении текущей структуры кода. А вот для чего это может понадобиться — для улучшения, для изучения, для исследования и тд — дело десятое.
Re[2]: паттерны экслюзивно для .net c#
От: -n1l-  
Дата: 27.03.14 10:55
Оценка: 23 (2)
Забыл ссылку.
вот
Re[3]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 27.03.14 11:11
Оценка: 2 (1) +1
Здравствуйте, -n1l-, Вы писали:

N>Забыл ссылку.

N>вот

Объём работы впечатляет, но у меня два вопроса:

Если смотреть на цель — чем оно отличается от оригинального GoF?
Если смотреть на минусы и на реализацию, то большинство паттернов (навскидку — фабричный метод, ленивая инициализация, синглтон, наблюдатель и т.д.) — это скорее антипаттерны, т.к. на "чистом" c# то же самое делается проще и красивее.

В общем, выглядит как пересказ GoF для явы -> GoF для c# человеком, который практически не знает c#.
Re[3]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 24.03.14 10:54
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

I>FDG это сборник паттернов в чистом виде с той лишь разнией, что паттернам не даются громкие названия, как у фаулера или гоф.

Нет. От слова совсем. Разница примерно такая же, как между прекраснодушным МакКоннелом и хардкорным Рихтером

Про фаулерологию очено хорошо написал XopoSHiy вот тут
Автор: XopoSHiy
Дата: 14.04.10
. Ни прибавить, ни отнять
Framework design guidelines, напротив, приземлена и прагматична: почти все рекомендации не допускают различных толкований, не описывают велосипедов, их можно подтвердить примерами, нарушения — поймать статическим анализом.
Re: паттерны экслюзивно для .net c#
От: Doc Россия http://andrey.moveax.ru
Дата: 01.04.14 07:30
Оценка: 30 (1)
Здравствуйте, -rsdn-, Вы писали:

R>нужны примеры с учетом платформы и языка программирования

R>в частности интересно что такое связность от связанность (cohesion & coupling)

Тут есть кое-что по шаблонам Gof с примерами на C#
Re[7]: паттерны экслюзивно для .net c#
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.03.14 11:48
Оценка: 20 (1)
Здравствуйте, Sinix, Вы писали:

I>>Это GOF-паттерны в пересказе от XopoSHiy. Рассуждения применимы исключительно к GOF и ни к чему более, а между тем паттерны есть вообще везде.

S>Тогда паттерны у тебя вырождаются в баззворд, который не несёт никакой нагрузки.

Наоборот. Если ты не заметил, то паттерны GOF уже давно превратились в баззворды безо всякого смысла. За упоминание паттернов скоро лицо будут бить.

>Т.к. он может обозначать и типовые проблемы, как в GoF/Фаулере, и инструмент для решения проблем (как у Nuseraro), и рекомендации по проектированию API (как в FDG).


Я бы не ставил паттерны GOF вместе с паттернами у Файлера. Фаулер с Кентом Беком частенько стебутся с GOF.

S>Если в таком ключе обсуждать, у нас вообще дикая путаница выйдет.


Путаница уже давно и именно из за подхода GOF.

I>>На самом деле типовую проблему можно решить десятком разных способов и каждое решение будет типовым. С тз GOF не ясно, не то один паттерн, не то десять разных.

S>По-моему (тут я согласен с XopoSHiy), неясность возникает если читать GoF как готовый решебник.

А он и есть решебник. При чем решение дается сходу, там где Intent, и там где диаграма. А проблема ставится неявно в простынях текста и кода.

Вот state

"Allow an object to alter its behavior when its internal state changes. The object will appear to change its class"


Это решение в чистом виде. Теперь посмотри Джошуа Кериевски, чего он пишет про State.

Вот strategy

"Define a family of algorithms, encapsulate each one, and make them interchangeable.
Strategy lets the algorithm vary independently from clients that use it. "


И снова — решение в чистом виде.

Decorator

Attach additional responsibilities to an object dynamically. Decorators provide
a flexible alternative to subclassing for extending functionality


Опаньки — и здесь решение.

>А если смотреть на описание проблемы (кстати это первый пункт в описании каждого паттерна), то становится понятно, что неоднозначность не в самой книжке, а в том, с какой стороны мы смортрим на проблему.


В GOF описание проблемы подается невнятно, многословно и на конкретных примерах. Описание паттерна это сходу решение, еще до постановки проблемы.

I>>ВОт берем например книгу Фаулера про DSL и видим, что один и тот же пример идет почти через всю книгу. Опаньки, сразу ясно, что надо выбирать тот, который лучше подходит в конкретной ситуации.

S>Не читал но осуждаю, судя по оглавлению и превью — там вообще про классические паттерны речь не идёт, один-в-один пересказ dragon book с упором на особенности DSL.

Нет никаких "классических" паттернов. Все паттерны относятся к конкретным областям. Это может быть и кодирование, и АПИ, и внутренний дизайн и архитектура и все что угодно.

DSL это не пересказ dragon book, это навроде антологии вычислительных моделей. Из книги дракона только одна или две главы.
Re[5]: паттерны экслюзивно для .net c#
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.03.14 09:30
Оценка: 11 (1)
Здравствуйте, Sinix, Вы писали:

S>>>По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо.

N>>Не совсем понял, я вроде и не называл.
S>Ну, речь была про "паттерны и рефакторинги специфичные для СиШарпа", как пример приводились "Замена стратегии на Func/Action" и обратно и "Перенос метода из класса в extension для этого класса"

S>Это всё никак не относится к паттернам и рефакторингам в классическом понимании, скорее к знанию особенностей языка.



N>>Бывает что паттерн становится возможностью языка. Кстати наверное даже цикл for как раз и вырос в свое время из "паттерна" goto+inc+if. А вот цикл foreach ну вы знаете.

S>Неа. Паттерн — это скорее описание типовой проблемы+способ решения в качестве иллюстрации. Выше была ссылка
Автор: XopoSHiy
Дата: 14.04.10
на сообщение от XopoSHiy, процитирую


Это GOF-паттерны в пересказе от XopoSHiy. Рассуждения применимы исключительно к GOF и ни к чему более, а между тем паттерны есть вообще везде.
На самом деле типовую проблему можно решить десятком разных способов и каждое решение будет типовым. С тз GOF не ясно, не то один паттерн, не то десять разных. А если открыть Джошуа Кериевски, Фаулера и Кента Бека, то все становится предельно простым и понятным — типовое решение типовой проблемы. Практически как в университете — один и тот же предел (типовая задача) решается самым разными способами, каждый из которых типовой.

ВОт и получается, что паттерны GOF непойми что, а отсюда не надо удивляться, что каждый понимает непойми что непойми как.
ВОт берем например книгу Фаулера про DSL и видим, что один и тот же пример идет почти через всю книгу. Опаньки, сразу ясно, что надо выбирать тот, который лучше подходит в конкретной ситуации.
Re[3]: паттерны экслюзивно для .net c#
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.03.14 09:13
Оценка: 7 (1)
Здравствуйте, Sinix, Вы писали:

N>>Я вот хотел бы написать статейку про те наработки, которые знаю в вопросах паттернов и рефакторингов специфичных для СиШарпа, но косноязычен По сути те же JetBrains их изучают и применяют, только у них книжки нет. Например у них есть, "Convert foreach-clause to LINQ" и обратно. А я вот например применяю "Замена стратегии на Func/Action" и обратно. Или "Перенос метода из класса в extension для этого класса" и обратно.


S>По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо.


Если нет async/await, то в асинхронном коде во весь рост плодятся паттерны инкремент, цыкл и все что угодно:
Вот например асинхронный последовательный foreach на промисах
var task = array.reduce(function(promise, item){
   return promise.then(function(result){
      return Something(result, item);
   });
}, Promise.resolve());

вот асинхронный параллельный foreach на промисах
var task = Promise.join(Promise.map(array, function(item){
   return Something(item);
}, Promise.resolve()));


Итого, паттерн это просто некоторая фича которая поддерживается на уровне библиотеки. По простому — типовое решение конкретной типовой проблемы.
Согласуется, что характерно, и с GOF, и с Фаулером, и с Кентом Беком, и даже с FDG.
Re[8]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 28.03.14 05:09
Оценка: +1
Здравствуйте, Nuseraro, Вы писали:

S>>Неа, тут та же путаница: рефакторинг — это общее описание проблемы ("фиговый код, нужно улучшить"). Замена стратегии на Func/Action — это конкрентый инструмент.


N>Можно говорить о том, что понимание проблемы важнее, а главное, первичнее, специфичного решения, но неправильно говорить, что решение вообще не важно.

Решение приведённое в качестве примеров — вообще не важно. Зачастую там фигня полная.

Выше -n1l- дал ссылку на шпаргалку по паттернам в творческом переложении под c#. Там как раз почти каждая реализация — пример как делать не надо.
Например, паттерн builder:
abstract class Builder
{
  public virtual void BuildPartA()
  {
  }
  public virtual void BuildPartB()
  {
  }
  public virtual Product GetResult()
  {
  }
}


А теперь смотрим на реальные сценарии использования и понимаем, что реализацию ваяли от балды. Даже если отбросить лютый изврат в виде "class Director ...":

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

Во-вторых, смотрим на реальные билдеры из фреймворка.
Если билдер должен только заполнять свойства — то у билдера свойства и должны быть, а сам билдер заполняется через object initializer, см на ProcessStartInfo или на SqlConnectionStringBuilder.
Если использование билдера предполагает цепочку вызовов вида
 var result = builder
  .BuildPartA()
  .BuildPartB()
  .GetResult();

— должен быть fluent api, и, как следствие, виртуальные методы должны быть protected, а public api должно возвращать точный тип билдера.

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


Так что да, решение которое обычно приводится как иллюстрация, вообще не важно.
паттерны экслюзивно для .net c#
От: -rsdn- Беларусь http://dsalodki.wix.com/resume
Дата: 24.03.14 07:31
Оценка:
нужны примеры с учетом платформы и языка программирования
в частности интересно что такое связность от связанность (cohesion & coupling)
Re[2]: паттерны экслюзивно для .net c#
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.03.14 10:22
Оценка:
Здравствуйте, Sinix, Вы писали:

R>>нужны примеры с учетом платформы и языка программирования

S>По-моему, единственный работающий способ использовать паттерны — не вспоминать про них вовсе. Гораздо полезней изучить Рихтера и Framework Design Guidelines и использовать здравый смысл и знание матчасти.

FDG это сборник паттернов в чистом виде с той лишь разнией, что паттернам не даются громкие названия, как у фаулера или гоф.
Re: Observer
От: Qbit86 Кипр
Дата: 24.03.14 10:54
Оценка:
Здравствуйте, -rsdn-, Вы писали:

R>нужны примеры с учетом платформы и языка программирования


Observer
Глаза у меня добрые, но рубашка — смирительная!
Re: паттерны экслюзивно для .net c#
От: Аноним  
Дата: 24.03.14 17:59
Оценка:
Здравствуйте, -rsdn-, Вы писали:

R>нужны примеры с учетом платформы и языка программирования

R>в частности интересно что такое связность от связанность (cohesion & coupling)

Можете поискать в блоге у Сергея Теплякова. http://sergeyteplyakov.blogspot.ru/2014/02/gof-net.html
И другие записи
Re[4]: паттерны экслюзивно для .net c#
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.03.14 21:31
Оценка:
Здравствуйте, Sinix, Вы писали:

I>>FDG это сборник паттернов в чистом виде с той лишь разнией, что паттернам не даются громкие названия, как у фаулера или гоф.

S>Нет. От слова совсем. Разница примерно такая же, как между прекраснодушным МакКоннелом и хардкорным Рихтером

S>Про фаулерологию очено хорошо написал XopoSHiy вот тут
Автор: XopoSHiy
Дата: 14.04.10
. Ни прибавить, ни отнять

S>Framework design guidelines, напротив, приземлена и прагматична: почти все рекомендации не допускают различных толкований, не описывают велосипедов, их можно подтвердить примерами, нарушения — поймать статическим анализом.

Фдг это всё равно паттерны, только немного другие.
Re[5]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 25.03.14 04:51
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Фдг это всё равно паттерны, только немного другие.


Cпорить не буду, т.к. бесполезно.
Re: паттерны экслюзивно для .net c#
От: Nuseraro Россия  
Дата: 27.03.14 07:15
Оценка:
По формулировке мне казалось, что вопрос про те паттерны, которые реализуются именно на .NET за счет особенностей языка.

GoFовские — треть устарели, треть внедрилась внутрь языков и не актуальна, и только треть рабочая. GoF — это про работу с объектами у которых очень сложное внутреннее устройство при простом интерфейса. Во времена когда она писалась этого было очень много. Теперь — реже. В бизнес-разработке — ещё реже. Поэтому "GoF не нужен", точнее спектр его эффективности уже совсем не тот что ранее. Хотя конечно тем кто вообще не знаком с паттерн-подходом читать надо, это же про системное мышление, а оно важно.

Я вот хотел бы написать статейку про те наработки, которые знаю в вопросах паттернов и рефакторингов специфичных для СиШарпа, но косноязычен По сути те же JetBrains их изучают и применяют, только у них книжки нет. Например у них есть, "Convert foreach-clause to LINQ" и обратно. А я вот например применяю "Замена стратегии на Func/Action" и обратно. Или "Перенос метода из класса в extension для этого класса" и обратно.
Homo Guglens
Re[2]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 27.03.14 07:37
Оценка:
Здравствуйте, Nuseraro, Вы писали:

N>Я вот хотел бы написать статейку про те наработки, которые знаю в вопросах паттернов и рефакторингов специфичных для СиШарпа, но косноязычен По сути те же JetBrains их изучают и применяют, только у них книжки нет. Например у них есть, "Convert foreach-clause to LINQ" и обратно. А я вот например применяю "Замена стратегии на Func/Action" и обратно. Или "Перенос метода из класса в extension для этого класса" и обратно.


По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо.
Re[3]: паттерны экслюзивно для .net c#
От: Nuseraro Россия  
Дата: 27.03.14 07:51
Оценка:
Здравствуйте, Sinix, Вы писали:

S>По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо.

Не совсем понял, я вроде и не называл.
Бывает что паттерн становится возможностью языка. Кстати наверное даже цикл for как раз и вырос в свое время из "паттерна" goto+inc+if. А вот цикл foreach ну вы знаете.
Homo Guglens
Re[4]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 27.03.14 08:53
Оценка:
Здравствуйте, Nuseraro, Вы писали:

S>>По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо.

N>Не совсем понял, я вроде и не называл.
Ну, речь была про "паттерны и рефакторинги специфичные для СиШарпа", как пример приводились "Замена стратегии на Func/Action" и обратно и "Перенос метода из класса в extension для этого класса"

Это всё никак не относится к паттернам и рефакторингам в классическом понимании, скорее к знанию особенностей языка.


N>Бывает что паттерн становится возможностью языка. Кстати наверное даже цикл for как раз и вырос в свое время из "паттерна" goto+inc+if. А вот цикл foreach ну вы знаете.

Неа. Паттерн — это скорее описание типовой проблемы+способ решения в качестве иллюстрации. Выше была ссылка
Автор: XopoSHiy
Дата: 14.04.10
на сообщение от XopoSHiy, процитирую

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

Всё сообщение стоит прочитать целиком, оно маленькое

Возможности языка, напротив, это инструмент для решения типовых проблем. Который тоже надо использовать с осторожностью, особенно если исправление рекомендуется решарпером (раз уж про него зашла речь). Иногда слепое следование рекомендациям скорее вредят, чем помогают. Пример — всё та же свёртка циклов в linq или замена лямбды на method group
Автор: Sinix
Дата: 04.03.11
.
Re[5]: паттерны экслюзивно для .net c#
От: Nuseraro Россия  
Дата: 27.03.14 10:25
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Ну, речь была про "паттерны и рефакторинги специфичные для СиШарпа", как пример приводились "Замена стратегии на Func/Action" и обратно и "Перенос метода из класса в extension для этого класса"

S>Это всё никак не относится к паттернам и рефакторингам в классическом понимании, скорее к знанию особенностей языка.

Рефакторинг представляет собой процесс такого изменения программной системы, при котором не
меняется внешнее поведение кода, но улучшается его внутренняя структура.

Возможны ли случаи, когда замена стратегии на Func/Action улучшит внутреннюю структуру кода не меняя внешнего поведения? Я надеюсь все согласятся, что да. А стало быть это рефакторинг.

N>>Бывает что паттерн становится возможностью языка. Кстати наверное даже цикл for как раз и вырос в свое время из "паттерна" goto+inc+if. А вот цикл foreach ну вы знаете.

Именно, сначала вырабатывается паттерн, что если нам нужен цикл "10 раз", то объявляем переменную вначале, делаем тут же её if проверку, потом в конце прибавить переменную, написать комментарий //next, и сделать goto. И типа всегда если тебе нужен цикл поступать именно так. Потом это начинает так регулярно повторятся, что разработчики языка решают — а не упростить ли нам жизнь наших пользователей? И вставляют новую возможность языка, которая позволяет решать ту же проблему "напрямую" (Или как в немерле, сами пользователи добавляют,не сдержался). Вряд ли все возможности языка так получились, но история характерная.
Homo Guglens
Re[6]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 27.03.14 10:37
Оценка:
Здравствуйте, Ikemefula, Вы писали:


S>>Неа. Паттерн — это скорее описание типовой проблемы+способ решения в качестве иллюстрации. Выше была ссылка
Автор: XopoSHiy
Дата: 14.04.10
на сообщение от XopoSHiy, процитирую


I>Это GOF-паттерны в пересказе от XopoSHiy. Рассуждения применимы исключительно к GOF и ни к чему более, а между тем паттерны есть вообще везде.

Тогда паттерны у тебя вырождаются в баззворд, который не несёт никакой нагрузки. Т.к. он может обозначать и типовые проблемы, как в GoF/Фаулере, и инструмент для решения проблем (как у Nuseraro), и рекомендации по проектированию API (как в FDG).

Если в таком ключе обсуждать, у нас вообще дикая путаница выйдет.


I>На самом деле типовую проблему можно решить десятком разных способов и каждое решение будет типовым. С тз GOF не ясно, не то один паттерн, не то десять разных.

По-моему (тут я согласен с XopoSHiy), неясность возникает если читать GoF как готовый решебник. А если смотреть на описание проблемы (кстати это первый пункт в описании каждого паттерна), то становится понятно, что неоднозначность не в самой книжке, а в том, с какой стороны мы смортрим на проблему.


I> А если открыть Джошуа Кериевски, Фаулера и Кента Бека, то все становится предельно простым и понятным — типовое решение типовой проблемы. Практически как в университете — один и тот же предел (типовая задача) решается самым разными способами, каждый из которых типовой.

Ну... Фаулер (я про enterprise applications) и Бек (рефакторинг что-то-там), если воспринимать их буквально, вообще до карго-культа доводят из-за чрезмерной категоричности и чёрно-белого "устарело==плохо", "передовое==хорошо". Я бы их рассматривал как чтение для общего развития, не как учебник уровня Рихтера-Танненбаума-Руссиновича. Кериевски только пролистывал. Он меня не зацепил, так что сказать ничего не могу

I>ВОт и получается, что паттерны GOF непойми что, а отсюда не надо удивляться, что каждый понимает непойми что непойми как.

I>ВОт берем например книгу Фаулера про DSL и видим, что один и тот же пример идет почти через всю книгу. Опаньки, сразу ясно, что надо выбирать тот, который лучше подходит в конкретной ситуации.
Не читал но осуждаю, судя по оглавлению и превью — там вообще про классические паттерны речь не идёт, один-в-один пересказ dragon book с упором на особенности DSL.
Re: паттерны экслюзивно для .net c#
От: -n1l-  
Дата: 27.03.14 10:53
Оценка:
Здравствуйте, -rsdn-, Вы писали:
Вот.
Re[6]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 27.03.14 10:58
Оценка:
Здравствуйте, Nuseraro, Вы писали:

N>Возможны ли случаи, когда замена стратегии на Func/Action улучшит внутреннюю структуру кода не меняя внешнего поведения? Я надеюсь все согласятся, что да. А стало быть это рефакторинг.

Неа, тут та же путаница: рефакторинг — это общее описание проблемы ("фиговый код, нужно улучшить"). Замена стратегии на Func/Action — это конкрентый инструмент.

Если их смешивать, то получается путаница, как с фасадом-медиатором-посредником-мостом. Решение по большому счёту одно и то же, проблемы разные.

N>>>Бывает что паттерн становится возможностью языка. Кстати наверное даже цикл for как раз и вырос в свое время из "паттерна" goto+inc+if. А вот цикл foreach ну вы знаете.

N>Именно, сначала вырабатывается паттерн, что если нам нужен цикл "10 раз", то объявляем переменную вначале, делаем тут же её if проверку, потом в конце прибавить переменную, написать комментарий
Ну блин, это не паттерн в терминах оригинального GoF/Фаулера. Иначе мы так дойдём до "с++ — это сборник паттернов для ассемблера" и паттерн у нас превратится в баззворд, который обозначает так много, что не обозначает ничего.
Re[8]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 27.03.14 12:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Наоборот. Если ты не заметил, то паттерны GOF уже давно превратились в баззворды безо всякого смысла. За упоминание паттернов скоро лицо будут бить.

И XopoSHiy как раз привёл логичное обоснование, почему оно так вышло. Не, конечно остаётся ещё версия "GoF изначально является бесполезной фигнёй, раскрученной на волне хайпа", но тогда и обсуждать нечего. Фигня — она и есть фигня

I>А он и есть решебник. При чем решение дается сходу, там где Intent, и там где диаграма. А проблема ставится неявно в простынях текста и кода.

I>В GOF описание проблемы подается невнятно, многословно и на конкретных примерах. Описание паттерна это сходу решение, еще до постановки проблемы.
Тут согласен. С такой точки зрения я неправ и разницы действительно никакой.

I>DSL это не пересказ dragon book, это навроде антологии вычислительных моделей. Из книги дракона только одна или две главы.

Ок, спасиб!
Re[4]: паттерны экслюзивно для .net c#
От: -n1l-  
Дата: 27.03.14 16:29
Оценка:
Может я сути не понял, но я выложил справочник которым пользовался для того, что бы быстро въехать в тему по определенному шаблону проектирования.
Это не мое автороство. Но знаю точно, что много скопипастено с вики.
Re[7]: паттерны экслюзивно для .net c#
От: Nuseraro Россия  
Дата: 28.03.14 03:54
Оценка:
S>Неа, тут та же путаница: рефакторинг — это общее описание проблемы ("фиговый код, нужно улучшить"). Замена стратегии на Func/Action — это конкрентый инструмент.

Но эту проблему можно решить самыми различными способами: дописать комментариев, написать внешнюю документацию, переписать код.

Рефакторинг — проблема тяжелого к редактированию/поддержке кода + решение в виде улучшение его внутренней структуры. Вот и Фаулер пишет:

Рефакторинг представляет собой процесс такого изменения программной системы, при котором не
меняется внешнее поведение кода, но улучшается его внутренняя структура.

Можно говорить о том, что понимание проблемы важнее, а главное, первичнее, специфичного решения, но неправильно говорить, что решение вообще не важно.
Homo Guglens
Re[9]: паттерны экслюзивно для .net c#
От: Nuseraro Россия  
Дата: 28.03.14 05:43
Оценка:
Хе-хе вижу мы разговариваем на одном языке, но называем одними словами разные вещи. Без большого желания понять друг друга пользы мы не получим
Homo Guglens
Re[10]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 28.03.14 06:21
Оценка:
Здравствуйте, Nuseraro, Вы писали:

N>Хе-хе вижу мы разговариваем на одном языке, но называем одними словами разные вещи. Без большого желания понять друг друга пользы мы не получим


Ну, речь у нас о паттернах, поэтому я стараюсь придерживаться классики — терминологии из GoF

Тут постоянно по ветке путаются практически применимые решения, как топикстартер просил, эксклюзивно для шарпа и "решения" в стиле

решение в виде улучшения его внутренней структуры

aka

- Сова, расскажи — а как нам стать ежиками?
— Мое дело — стратегия!



Поэтому и путаница.

FDG-Рихтер и прочая суровая матчасть рассказывает в основном про решение проблем на практике. Фаулер, GoF, Кен etc — "про стратегию". Конечно, можно утверждать что разницы никакой, но тогда и смысла в обсуждении вообще никакого.
Re[7]: паттерны экслюзивно для .net c#
От: Sinclair Россия https://github.com/evilguest/
Дата: 31.03.14 06:12
Оценка:
Здравствуйте, Sinix, Вы писали:
S>Ну блин, это не паттерн в терминах оригинального GoF/Фаулера. Иначе мы так дойдём до "с++ — это сборник паттернов для ассемблера" и паттерн у нас превратится в баззворд, который обозначает так много, что не обозначает ничего.
Вы так говорите, как будто это плохо. Но С/С++ — это и есть набор паттернов для ассемблера. Точнее, С — для ассемблера, а С++ — для С.
Есть типовые проблемы, есть типовые решения. Иногда типовое решение типовой проблемы встраивают сразу в язык.
Например, в Java property — это паттерн, а в Delphi — конструкция языка. Publisher/Subscriber в Delphi — это паттерн (встроенные события там слишком убоги), а в C# — это конструкция языка. И так далее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 31.03.14 06:57
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>Ну блин, это не паттерн в терминах оригинального GoF/Фаулера. Иначе мы так дойдём до "с++ — это сборник паттернов для ассемблера" и паттерн у нас превратится в баззворд, который обозначает так много, что не обозначает ничего.

S>Вы так говорите, как будто это плохо. Но С/С++ — это и есть набор паттернов для ассемблера. Точнее, С — для ассемблера, а С++ — для С.

По большому счёту да, но тогда мы уходим в область философии, где все правы, но по-разному
Обычно всё-таки под паттернами понимают термины из gof/фаулера.

S>Есть типовые проблемы, есть типовые решения. Иногда типовое решение типовой проблемы встраивают сразу в язык.

S>Например, в Java property — это паттерн, а в Delphi — конструкция языка. Publisher/Subscriber в Delphi — это паттерн (встроенные события там слишком убоги), а в C# — это конструкция языка. И так далее.

Угу. Но:
1. Если всё это обзывать паттернами, то как отличать благие пожелания по, например, обсерверу в GoF от железобетонной реализации event-ов в c#?
2. Мы начинаем путать паттерны как описание проблемы (выше кучу раз упоминался пост
Автор: XopoSHiy
Дата: 14.04.10
от XopoSHiy) и паттерны как инструмент для решения проблем. Они не обязательно относятся как один-к-одному, достаточно вспомнить холивары на тему "вот код — это посредник, фасад, мост или адаптер?" без приведения проблемы, которую этот код пытается решить.
3. В результате путаницы появляются кошмарики типа вот этого (pdf, ссылка от -n1l-). Посмотрите примеры, там буквально каждый из разряда "обнять и плакать"
Re[9]: События
От: Qbit86 Кипр
Дата: 31.03.14 07:34
Оценка:
Здравствуйте, Sinix, Вы писали:

S>>Publisher/Subscriber в Delphi — это паттерн (встроенные события там слишком убоги), а в C# — это конструкция языка.


Вы так говорите, будто в C# события не убоги.

S>1. Если всё это обзывать паттернами, то как отличать благие пожелания по, например, обсерверу в GoF от железобетонной реализации event-ов в c#?


Что такое «железобетонная реализация event'ов» в C#? Вместо неё гораздо приятнее использовать Обсервер из Rx, который как раз примерно по GoF.
Глаза у меня добрые, но рубашка — смирительная!
Re[10]: События
От: Sinix  
Дата: 31.03.14 08:23
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Вы так говорите, будто в C# события не убоги.

Если их использовать по назначению — нет, не убоги.

Q>Что такое «железобетонная реализация event'ов» в C#?

Для обсервера gof я с ходу могу предложить варианта 4 реализации, причём общего у них будет только то, что они позволяют получать оповещения.
Когда мы говорим про события шарпа, то уточнений про что мы собственно говорим обычно делать не надо

Q>Вместо неё гораздо приятнее использовать Обсервер из Rx, который как раз примерно по GoF.

У обычных событий и у IObservable сценарии использования практически не пересекаются, поэтому утверждать что A однозначно лучше B не выйдет.
Re[11]: События
От: Qbit86 Кипр
Дата: 31.03.14 08:30
Оценка:
Здравствуйте, Sinix, Вы писали:

Q>>Вы так говорите, будто в C# события не убоги.

S>Если их использовать по назначению — нет, не убоги.

Ну и какое у них назначение?

S>У обычных событий и у IObservable сценарии использования практически не пересекаются, поэтому утверждать что A однозначно лучше B не выйдет.


Сценарии использования обычных событий строго включены в сценарии использования IObservable. Если б не легаси в повсеместном использовании встроенных событий стандартными и сторонними библиотеками, пользоваться встроенными событиями смысла вообще нет.
Глаза у меня добрые, но рубашка — смирительная!
Re[12]: События
От: Sinix  
Дата: 31.03.14 09:08
Оценка:
Здравствуйте, Qbit86, Вы писали:

S>>Если их использовать по назначению — нет, не убоги.

Q>Ну и какое у них назначение?

Для событий — привязка дополнительного кода для компонент (в основном ui-компонент) для обработки единичных событий.
Для observable — управление последовательностью однотипных событий.


S>>У обычных событий и у IObservable сценарии использования практически не пересекаются, поэтому утверждать что A однозначно лучше B не выйдет.

Q>Сценарии использования обычных событий строго включены в сценарии использования IObservable.

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

Проблем (явных и неявных) всплывает куча. В основном:
1. Пользователи API начинают накручивать сложные сценарии со своими шедулерами там, где поставщик API их не ждёт. В результате на ровном месте возникают очень неприятные race conditions, которые очень любят всплывать непосредственно у клиентов.
2. Последовательности начинают использовать как события — с "тяжёлым" кодом в подписчиках, бросанием исключения в надежде на "перехватится выше по стеку", запуском асинхронных задач и "отменой" последовательностей. Работает, но поддерживаемость кода падает в разы.
3. Необходимость протаскивать disposable для отписки. Каждый решал проблему по своему, получалось не всегда.

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


Чтобы совсем не было оффтопом. С большинством "универсальных" паттернов выходит ровно та же фигня: вместо готового инструмента изобретаем универсальный, а затем допиливаем подпорками до того, что можно решить на голом шарпе. Всей разницы: получили ещё один велосипед для изучения
Re[13]: События
От: Qbit86 Кипр
Дата: 31.03.14 10:44
Оценка:
Здравствуйте, Sinix, Вы писали:

S>1. Пользователи API начинают накручивать сложные сценарии со своими шедулерами там, где поставщик API их не ждёт. В результате на ровном месте возникают очень неприятные race conditions, которые очень любят всплывать непосредственно у клиентов.


Так это и с обычными событиями можно наворотить. Звучит так: «Давайте запретим вилки, так как дети могут их засунуть в розетки; взамен будем пользоваться вязальными спицами.»

S>2. Последовательности начинают использовать как события — с "тяжёлым" кодом в подписчиках


Не вижу, каким образом «.Subscribe(...)» заставляет пользователей использовать более тяжелый код, а «+= ...» — нет. В первом случае хотя бы лямбды можно использовать.

S>бросанием исключения в надежде на "перехватится выше по стеку"


То ли дело стандартные события, где исключение в одном из обработчиков внезапно влияет на остальных подписчиков.

S>3. Необходимость протаскивать disposable для отписки.


Это совсем смешно. Ты всерьёз утверждаешь, что протаскивать и источник, и подписчик событий проще, чем один только безликий IDisposable?

S>По факту дешевле выходит не создавать себе проблем на ровном месте и использовать специализированный инструмент — события.


Увы, иногда дешевле. В этом вся суть консервации принятых некогда кривых решений.
Глаза у меня добрые, но рубашка — смирительная!
Re[14]: События
От: Sinix  
Дата: 31.03.14 11:24
Оценка:
Здравствуйте, Qbit86, Вы писали:

S>>1. Пользователи API начинают накручивать сложные сценарии со своими шедулерами там, где поставщик API их не ждёт. В результате на ровном месте возникают очень неприятные race conditions, которые очень любят всплывать непосредственно у клиентов.

Q>Так это и с обычными событиями можно наворотить. Звучит так: «Давайте запретим вилки, так как дети могут их засунуть в розетки; взамен будем пользоваться вязальными спицами.»
Нет. Для событий достаточно
someObj.SomeEvent += SomeHandler;


Для Rx подобного сахара нет и не предвидится по той же причине, по которой нет сахара для infoof. В результате клиенты обычно подрубают к себе в проект System.Reactive и начинают ваять свои последовательности т.к. "это ж легко". Если API выставляет события там, где они по логике больше подходят, такой фигни не возникает.

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

S>>2. Последовательности начинают использовать как события — с "тяжёлым" кодом в подписчиках

Q>Не вижу, каким образом «.Subscribe(...)» заставляет пользователей использовать более тяжелый код, а «+= ...» — нет.
Пойнт не в этом. Обычные события такую штуку легко переживают, т.к. редко используются для обслуживания "горячего" потока данных. Observable — далеко не всегда. Пользователи начинают путаться и дуть на воду, т.е. запускать свой код через отдельный шедулер и тем самым порождают ещё больше race conditions.

Q>То ли дело стандартные события, где исключение в одном из обработчиков внезапно влияет на остальных подписчиков.

Напоминаю, речь про типовой для событий сценарий aka компонент-подписчик. "Остальных подписчиков" в 99.999% случаев просто не бывает.

S>>3. Необходимость протаскивать disposable для отписки.

Q>Это совсем смешно. Ты всерьёз утверждаешь, что протаскивать и источник, и подписчик событий проще, чем один только безликий IDisposable?
Его вообще не надо протаскивать, источник как правило доступен всё время жизни подписчика.
Re[9]: паттерны экслюзивно для .net c#
От: Sinclair Россия https://github.com/evilguest/
Дата: 31.03.14 13:35
Оценка:
Здравствуйте, Sinix, Вы писали:

S>По большому счёту да, но тогда мы уходим в область философии, где все правы, но по-разному

Нет, мы уходим в область научного подхода к решению проблем.
S>Обычно всё-таки под паттернами понимают термины из gof/фаулера.
Это очень странный подход. Всё равно, как под термином "задача" понимать ровно задания из Демидовича, а всё остальное считать философией.

S>Угу. Но:

S>1. Если всё это обзывать паттернами, то как отличать благие пожелания по, например, обсерверу в GoF от железобетонной реализации event-ов в c#?
Очень просто: также, как вы отличаете int i=0; в вашей программе от понятия "переменная".
Ещё раз подчеркну: event в C# — это уже не паттерн, это конструкция языка. Эта конструкция реализует некоторое архитектурное решение, которое в языках без нативной поддержки event-ов называется publisher/subscriber.

S>2. Мы начинаем путать паттерны как описание проблемы (выше кучу раз упоминался пост
Автор: XopoSHiy
Дата: 14.04.10
от XopoSHiy) и паттерны как инструмент для решения проблем.

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

S>3. В результате путаницы появляются кошмарики типа вот этого (pdf, ссылка от -n1l-). Посмотрите примеры, там буквально каждый из разряда "обнять и плакать"

Ну, это уже чистый постмодернизм — искусство ради искусства.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 01.04.14 04:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>>Но С/С++ — это и есть набор паттернов для ассемблера

S>>По большому счёту да, но тогда мы уходим в область философии, где все правы, но по-разному
S>Нет, мы уходим в область научного подхода к решению проблем.

Странный спор какой-то получается.
С одной стороны, очевидно, что называть абстракции GoF, конкретные рекомендации из FDG и ещё более конкретные конструкции языка одним термином — прямой путь к замыливанию контекста.
С другой — мне уже три человека продолжают доказывать, что всё едино, хотя на практике, я уверен, сами такой терминологией никогда не пользуются

В общем я самоустраняюсь, т.к. смысла в продолжении никакого не вижу. Участникам спасибо, приятно было поспорить!
Re[11]: паттерны экслюзивно для .net c#
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.04.14 06:10
Оценка:
Здравствуйте, Sinix, Вы писали:

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

По-моему, вы как-то превратно понимаете аргументацию. Вы можете ткнуть в то место, где я предлагаю вам называть конструкции языка паттернами?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 01.04.14 06:15
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>По-моему, вы как-то превратно понимаете аргументацию. Вы можете ткнуть в то место, где я предлагаю вам называть конструкции языка паттернами?

S>Иначе мы так дойдём до "с++ — это сборник паттернов для ассемблера" и паттерн у нас превратится в баззворд, который обозначает так много, что не обозначает ничего.
Вы так говорите, как будто это плохо. Но С/С++ — это и есть набор паттернов для ассемблера. Точнее, С — для ассемблера, а С++ — для С.

Re[14]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 01.04.14 10:12
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Это, по-моему, элементарные всё вещи.

Таак, теперь моя очередь недоумевать

С начала ветки я пишу ровно о том же. Вот основные цитаты, чтоб не размазывать:

По-моему, единственный работающий способ использовать паттерны — не вспоминать про них вовсе. Гораздо полезней изучить Рихтера и Framework Design Guidelines и использовать здравый смысл и знание матчасти.

...

I>FDG это сборник паттернов в чистом виде с той лишь разнией, что паттернам не даются громкие названия, как у фаулера или гоф.
Нет. От слова совсем. Разница примерно такая же, как между прекраснодушным МакКоннелом и хардкорным Рихтером

...

N>Я вот хотел бы написать статейку про те наработки, которые знаю в вопросах паттернов ... А я вот например применяю "Замена стратегии на Func/Action" и обратно. Или "Перенос метода из класса в extension для этого класса" и обратно.
По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо.


Собственно, о чём мы спорим?
Re[15]: паттерны экслюзивно для .net c#
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.04.14 04:07
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Собственно, о чём мы спорим?

А, ну я как обычно — влез в середину разговора, пока у меня крутится скрипт, и докопался до отдельной фразы, вырванной из контекста.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: паттерны экслюзивно для .net c#
От: Sinix  
Дата: 02.04.14 04:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


S>>Собственно, о чём мы спорим?

S>А, ну я как обычно — влез в середину разговора, пока у меня крутится скрипт, и докопался до отдельной фразы, вырванной из контекста.
Опс

Ну, я той же фигнёй бывает страдаю Ничего страшного, поспорить всё равно приятно было!
Re[5]: паттерны экслюзивно для .net c#
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.05.15 10:17
Оценка:
Здравствуйте, Sinix, Вы писали:

ссылка
Автор: XopoSHiy
Дата: 14.04.10
на сообщение от XopoSHiy, процитирую
S>

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

S>Всё сообщение стоит прочитать целиком, оно маленькое

Сообщение маленькое, но неверное. У GoF, начнем с самого главного, вообще нет внятного описания проблемы, нигде, ни разу. Сходу подаётся решение, а до самой проблемы надо еще докопаться. Проблема описывается в терминах её решения.
Re[7]: паттерны экслюзивно для .net c#
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.05.15 10:22
Оценка:
Здравствуйте, Sinix, Вы писали:

N>>Возможны ли случаи, когда замена стратегии на Func/Action улучшит внутреннюю структуру кода не меняя внешнего поведения? Я надеюсь все согласятся, что да. А стало быть это рефакторинг.

S>Неа, тут та же путаница: рефакторинг — это общее описание проблемы ("фиговый код, нужно улучшить"). Замена стратегии на Func/Action — это конкрентый инструмент.

Рефакторинг вдруг стал общим описанием проблемы ?

S>Если их смешивать, то получается путаница, как с фасадом-медиатором-посредником-мостом. Решение по большому счёту одно и то же, проблемы разные.


Оно и видно, что в твоей трактовке рефакторинг это улучшайзер вида "фиговый код, нужно улучшить".

На самом деле рефакторинг всего лишь изменения одного лишь [микро|макро]дизайна без изменения других аспектов.

например, переименовать xyz в requiredEntries — рефакторинг. Обратное изменение, то есть requiredEntries в xyz так же есть рефакторинг.


N>>Именно, сначала вырабатывается паттерн, что если нам нужен цикл "10 раз", то объявляем переменную вначале, делаем тут же её if проверку, потом в конце прибавить переменную, написать комментарий

S>Ну блин, это не паттерн в терминах оригинального GoF/Фаулера. Иначе мы так дойдём до "с++ — это сборник паттернов для ассемблера" и паттерн у нас превратится в баззворд, который обозначает так много, что не обозначает ничего.

Правильно. Паттерны в терминах GoF вообще мало чего стоят. Все языковые фичи в детстве были какими то паттернами. И паттерн действительно есть баззворд, который совсем мало чего значит, ну примерно как стиль.
Одно дело — сигнал, событие, однонаправленый, двунаправленый, широковещательный другое дело — обсервер, шина и тд и тд. Первые — категорически хорошо. Вторые — категорическое зло, если встречаются вместо первых.
Re[2]: паттерны экслюзивно для .net c#
От: Evgeny.Panasyuk Россия  
Дата: 06.05.15 12:59
Оценка:
Здравствуйте, SergeyT., Вы писали:

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

ST> void WithReadLock(this ReaderWriterLockSlim rwLock, Action action)

Это ты функцию принимающую одно замыкание обозвал "локальным методом шаблона"
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.