Здравствуйте, -rsdn-, Вы писали:
R>нужны примеры с учетом платформы и языка программирования
По-моему, единственный работающий способ использовать паттерны — не вспоминать про них вовсе. Гораздо полезней изучить Рихтера и Framework Design Guidelines и использовать здравый смысл и знание матчасти.
R>в частности интересно что такое связность от связанность (cohesion & coupling)
Кстати, cohesion обычно как сцепление переводится.
Если на пальцах:
* сoupling — это мера, определяющая, насколько различные модули приложения зависят один от другого,
* cohesion — насколько функционал отдельного модуля однороден.
Конкретные примеры для дотнета можно глянуть вот тут (перевод конечно ужасен, вот оригинал). Но я бы не воспринимал их слишком буквально.
Гораздо проще описать cohesion-vs-coupling в терминах разделения ответственности ака "слона едят по кусочкам".
Сильное сцепление (cohesion) означает, что каждый модуль (сборка, класс, метод — не важно) или сосредоточен на решении одной донельзя конкретной задачи, или разбивает её на несколько подзадач, каждую из которых делегирует другому модулю.
Слабая связанность (coupling) означает, что делегировав задачу, исходный модуль не пытается вмешиваться в дальнейший процесс её решения и не завязывается на конкретные детали реализации модулей, которым он передал кусочки исходной задачи.
Смысл такого разделения — в локализации ответственности и в уменьшении исправлений в зависимом коде.
Здравствуйте, Sinix, Вы писали:
R>>нужны примеры с учетом платформы и языка программирования S>По-моему, единственный работающий способ использовать паттерны — не вспоминать про них вовсе. Гораздо полезней изучить Рихтера и Framework Design Guidelines и использовать здравый смысл и знание матчасти.
FDG это сборник паттернов в чистом виде с той лишь разнией, что паттернам не даются громкие названия, как у фаулера или гоф.
Здравствуйте, Ikemefula, Вы писали:
I>FDG это сборник паттернов в чистом виде с той лишь разнией, что паттернам не даются громкие названия, как у фаулера или гоф.
Нет. От слова совсем. Разница примерно такая же, как между прекраснодушным МакКоннелом и хардкорным Рихтером
Про фаулерологию очено хорошо написал XopoSHiy вот тут
. Ни прибавить, ни отнять
Framework design guidelines, напротив, приземлена и прагматична: почти все рекомендации не допускают различных толкований, не описывают велосипедов, их можно подтвердить примерами, нарушения — поймать статическим анализом.
Re: паттерны экслюзивно для .net c#
От:
Аноним
Дата:
24.03.14 17:59
Оценка:
Здравствуйте, -rsdn-, Вы писали:
R>нужны примеры с учетом платформы и языка программирования R>в частности интересно что такое связность от связанность (cohesion & coupling)
Здравствуйте, Sinix, Вы писали:
I>>FDG это сборник паттернов в чистом виде с той лишь разнией, что паттернам не даются громкие названия, как у фаулера или гоф. S>Нет. От слова совсем. Разница примерно такая же, как между прекраснодушным МакКоннелом и хардкорным Рихтером
S>Про фаулерологию очено хорошо написал XopoSHiy вот тут
. Ни прибавить, ни отнять S>Framework design guidelines, напротив, приземлена и прагматична: почти все рекомендации не допускают различных толкований, не описывают велосипедов, их можно подтвердить примерами, нарушения — поймать статическим анализом.
Фдг это всё равно паттерны, только немного другие.
По формулировке мне казалось, что вопрос про те паттерны, которые реализуются именно на .NET за счет особенностей языка.
GoFовские — треть устарели, треть внедрилась внутрь языков и не актуальна, и только треть рабочая. GoF — это про работу с объектами у которых очень сложное внутреннее устройство при простом интерфейса. Во времена когда она писалась этого было очень много. Теперь — реже. В бизнес-разработке — ещё реже. Поэтому "GoF не нужен", точнее спектр его эффективности уже совсем не тот что ранее. Хотя конечно тем кто вообще не знаком с паттерн-подходом читать надо, это же про системное мышление, а оно важно.
Я вот хотел бы написать статейку про те наработки, которые знаю в вопросах паттернов и рефакторингов специфичных для СиШарпа, но косноязычен По сути те же JetBrains их изучают и применяют, только у них книжки нет. Например у них есть, "Convert foreach-clause to LINQ" и обратно. А я вот например применяю "Замена стратегии на Func/Action" и обратно. Или "Перенос метода из класса в extension для этого класса" и обратно.
Здравствуйте, Nuseraro, Вы писали:
N>Я вот хотел бы написать статейку про те наработки, которые знаю в вопросах паттернов и рефакторингов специфичных для СиШарпа, но косноязычен По сути те же JetBrains их изучают и применяют, только у них книжки нет. Например у них есть, "Convert foreach-clause to LINQ" и обратно. А я вот например применяю "Замена стратегии на Func/Action" и обратно. Или "Перенос метода из класса в extension для этого класса" и обратно.
По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо.
Здравствуйте, Sinix, Вы писали:
S>По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо.
Не совсем понял, я вроде и не называл.
Бывает что паттерн становится возможностью языка. Кстати наверное даже цикл for как раз и вырос в свое время из "паттерна" goto+inc+if. А вот цикл foreach ну вы знаете.
Здравствуйте, Nuseraro, Вы писали:
S>>По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо. N>Не совсем понял, я вроде и не называл.
Ну, речь была про "паттерны и рефакторинги специфичные для СиШарпа", как пример приводились "Замена стратегии на Func/Action" и обратно и "Перенос метода из класса в extension для этого класса"
Это всё никак не относится к паттернам и рефакторингам в классическом понимании, скорее к знанию особенностей языка.
N>Бывает что паттерн становится возможностью языка. Кстати наверное даже цикл for как раз и вырос в свое время из "паттерна" goto+inc+if. А вот цикл foreach ну вы знаете.
Неа. Паттерн — это скорее описание типовой проблемы+способ решения в качестве иллюстрации. Выше была ссылка
Задача книги — всего лишь дать разработчикам общий язык. Паттерн у них — это в первую очередь описание проблемы. И четкого описания проблемы для хоть сколько-то опытного разработчика достаточно, чтобы изобрести решение самостоятельно. Описание проблемы — это самое главное, что нужно запомнить из этой книжки! Но это первое, что обычно забывают после прочтения. Зато диаграммы классов все зазубривают наизусть.
Всё сообщение стоит прочитать целиком, оно маленькое
Возможности языка, напротив, это инструмент для решения типовых проблем. Который тоже надо использовать с осторожностью, особенно если исправление рекомендуется решарпером (раз уж про него зашла речь). Иногда слепое следование рекомендациям скорее вредят, чем помогают. Пример — всё та же свёртка циклов в linq или замена лямбды на method group
Здравствуйте, Sinix, Вы писали:
N>>Я вот хотел бы написать статейку про те наработки, которые знаю в вопросах паттернов и рефакторингов специфичных для СиШарпа, но косноязычен По сути те же JetBrains их изучают и применяют, только у них книжки нет. Например у них есть, "Convert foreach-clause to LINQ" и обратно. А я вот например применяю "Замена стратегии на Func/Action" и обратно. Или "Перенос метода из класса в extension для этого класса" и обратно.
S>По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо.
Если нет async/await, то в асинхронном коде во весь рост плодятся паттерны инкремент, цыкл и все что угодно:
Вот например асинхронный последовательный foreach на промисах
var task = Promise.join(Promise.map(array, function(item){
return Something(item);
}, Promise.resolve()));
Итого, паттерн это просто некоторая фича которая поддерживается на уровне библиотеки. По простому — типовое решение конкретной типовой проблемы.
Согласуется, что характерно, и с GOF, и с Фаулером, и с Кентом Беком, и даже с FDG.
Здравствуйте, Sinix, Вы писали:
S>>>По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо. N>>Не совсем понял, я вроде и не называл. S>Ну, речь была про "паттерны и рефакторинги специфичные для СиШарпа", как пример приводились "Замена стратегии на Func/Action" и обратно и "Перенос метода из класса в extension для этого класса"
S>Это всё никак не относится к паттернам и рефакторингам в классическом понимании, скорее к знанию особенностей языка.
N>>Бывает что паттерн становится возможностью языка. Кстати наверное даже цикл for как раз и вырос в свое время из "паттерна" goto+inc+if. А вот цикл foreach ну вы знаете. S>Неа. Паттерн — это скорее описание типовой проблемы+способ решения в качестве иллюстрации. Выше была ссылка
Это GOF-паттерны в пересказе от XopoSHiy. Рассуждения применимы исключительно к GOF и ни к чему более, а между тем паттерны есть вообще везде.
На самом деле типовую проблему можно решить десятком разных способов и каждое решение будет типовым. С тз GOF не ясно, не то один паттерн, не то десять разных. А если открыть Джошуа Кериевски, Фаулера и Кента Бека, то все становится предельно простым и понятным — типовое решение типовой проблемы. Практически как в университете — один и тот же предел (типовая задача) решается самым разными способами, каждый из которых типовой.
ВОт и получается, что паттерны GOF непойми что, а отсюда не надо удивляться, что каждый понимает непойми что непойми как.
ВОт берем например книгу Фаулера про DSL и видим, что один и тот же пример идет почти через всю книгу. Опаньки, сразу ясно, что надо выбирать тот, который лучше подходит в конкретной ситуации.
Здравствуйте, Sinix, Вы писали:
S>Ну, речь была про "паттерны и рефакторинги специфичные для СиШарпа", как пример приводились "Замена стратегии на Func/Action" и обратно и "Перенос метода из класса в extension для этого класса" S>Это всё никак не относится к паттернам и рефакторингам в классическом понимании, скорее к знанию особенностей языка.
Рефакторинг представляет собой процесс такого изменения программной системы, при котором не
меняется внешнее поведение кода, но улучшается его внутренняя структура.
Возможны ли случаи, когда замена стратегии на Func/Action улучшит внутреннюю структуру кода не меняя внешнего поведения? Я надеюсь все согласятся, что да. А стало быть это рефакторинг.
N>>Бывает что паттерн становится возможностью языка. Кстати наверное даже цикл for как раз и вырос в свое время из "паттерна" goto+inc+if. А вот цикл foreach ну вы знаете.
Именно, сначала вырабатывается паттерн, что если нам нужен цикл "10 раз", то объявляем переменную вначале, делаем тут же её if проверку, потом в конце прибавить переменную, написать комментарий //next, и сделать goto. И типа всегда если тебе нужен цикл поступать именно так. Потом это начинает так регулярно повторятся, что разработчики языка решают — а не упростить ли нам жизнь наших пользователей? И вставляют новую возможность языка, которая позволяет решать ту же проблему "напрямую" (Или как в немерле, сами пользователи добавляют,не сдержался). Вряд ли все возможности языка так получились, но история характерная.
на сообщение от XopoSHiy, процитирую
I>Это GOF-паттерны в пересказе от XopoSHiy. Рассуждения применимы исключительно к GOF и ни к чему более, а между тем паттерны есть вообще везде.
Тогда паттерны у тебя вырождаются в баззворд, который не несёт никакой нагрузки. Т.к. он может обозначать и типовые проблемы, как в GoF/Фаулере, и инструмент для решения проблем (как у Nuseraro), и рекомендации по проектированию API (как в FDG).
Если в таком ключе обсуждать, у нас вообще дикая путаница выйдет.
I>На самом деле типовую проблему можно решить десятком разных способов и каждое решение будет типовым. С тз GOF не ясно, не то один паттерн, не то десять разных.
По-моему (тут я согласен с XopoSHiy), неясность возникает если читать GoF как готовый решебник. А если смотреть на описание проблемы (кстати это первый пункт в описании каждого паттерна), то становится понятно, что неоднозначность не в самой книжке, а в том, с какой стороны мы смортрим на проблему.
I> А если открыть Джошуа Кериевски, Фаулера и Кента Бека, то все становится предельно простым и понятным — типовое решение типовой проблемы. Практически как в университете — один и тот же предел (типовая задача) решается самым разными способами, каждый из которых типовой.
Ну... Фаулер (я про enterprise applications) и Бек (рефакторинг что-то-там), если воспринимать их буквально, вообще до карго-культа доводят из-за чрезмерной категоричности и чёрно-белого "устарело==плохо", "передовое==хорошо". Я бы их рассматривал как чтение для общего развития, не как учебник уровня Рихтера-Танненбаума-Руссиновича. Кериевски только пролистывал. Он меня не зацепил, так что сказать ничего не могу
I>ВОт и получается, что паттерны GOF непойми что, а отсюда не надо удивляться, что каждый понимает непойми что непойми как. I>ВОт берем например книгу Фаулера про DSL и видим, что один и тот же пример идет почти через всю книгу. Опаньки, сразу ясно, что надо выбирать тот, который лучше подходит в конкретной ситуации.
Не читал но осуждаю, судя по оглавлению и превью — там вообще про классические паттерны речь не идёт, один-в-один пересказ dragon book с упором на особенности DSL.
Здравствуйте, Nuseraro, Вы писали:
N>Возможны ли случаи, когда замена стратегии на Func/Action улучшит внутреннюю структуру кода не меняя внешнего поведения? Я надеюсь все согласятся, что да. А стало быть это рефакторинг.
Неа, тут та же путаница: рефакторинг — это общее описание проблемы ("фиговый код, нужно улучшить"). Замена стратегии на Func/Action — это конкрентый инструмент.
Если их смешивать, то получается путаница, как с фасадом-медиатором-посредником-мостом. Решение по большому счёту одно и то же, проблемы разные.
N>>>Бывает что паттерн становится возможностью языка. Кстати наверное даже цикл for как раз и вырос в свое время из "паттерна" goto+inc+if. А вот цикл foreach ну вы знаете. N>Именно, сначала вырабатывается паттерн, что если нам нужен цикл "10 раз", то объявляем переменную вначале, делаем тут же её if проверку, потом в конце прибавить переменную, написать комментарий
Ну блин, это не паттерн в терминах оригинального GoF/Фаулера. Иначе мы так дойдём до "с++ — это сборник паттернов для ассемблера" и паттерн у нас превратится в баззворд, который обозначает так много, что не обозначает ничего.
Здравствуйте, -n1l-, Вы писали:
N>Забыл ссылку. N>вот
Объём работы впечатляет, но у меня два вопроса:
Если смотреть на цель — чем оно отличается от оригинального GoF?
Если смотреть на минусы и на реализацию, то большинство паттернов (навскидку — фабричный метод, ленивая инициализация, синглтон, наблюдатель и т.д.) — это скорее антипаттерны, т.к. на "чистом" c# то же самое делается проще и красивее.
В общем, выглядит как пересказ GoF для явы -> GoF для c# человеком, который практически не знает c#.
