Здравствуйте, Sinclair, Вы писали:
S>>С другой — мне уже три человека продолжают доказывать, что всё едино, хотя на практике, я уверен, сами такой терминологией никогда не пользуются S>По-моему, вы как-то превратно понимаете аргументацию. Вы можете ткнуть в то место, где я предлагаю вам называть конструкции языка паттернами?
S>Иначе мы так дойдём до "с++ — это сборник паттернов для ассемблера" и паттерн у нас превратится в баззворд, который обозначает так много, что не обозначает ничего.
Вы так говорите, как будто это плохо. Но С/С++ — это и есть набор паттернов для ассемблера. Точнее, С — для ассемблера, а С++ — для С.
Здравствуйте, -rsdn-, Вы писали:
R>нужны примеры с учетом платформы и языка программирования R>в частности интересно что такое связность от связанность (cohesion & coupling)
Тут есть кое-что по шаблонам Gof с примерами на C#
Здравствуйте, Sinix, Вы писали: S>
Ещё раз повторяю, медленно: то, что на одном языке реализуется при помощи паттерна, на другом языке может быть реализовано языковой конструкцией.
Понимаете? Это никак не делает термин "паттерн" баззвордом, который не обозначает ничего.
Это делает некоторые паттерны неактуальными в языках, оборудованных соответствующими конструкциями.
То есть, например, если кто-то фигачит в Delphi или C# парные методы типа getMouthWidth / setMouthWidth, не вводя Property, его надо немедленно удавить логарифмической линейкой.
Если кто-то в C# начинает городить иерархию классов publisher/subscriber — то же самое.
Или если кто-то начинает в С фигачить цикл на основе goto.
Всё это никак не отменяет важности и полезности паттернов вроде "цикл" в программах на RISC-ассемблерах.
И всё это никак не означает какой-то святости паттернов, описанных как GoF, так и Фаулером.
Если у вас нет тех проблем, которые решаются предложенными ими паттернами — не нужны и паттерны. Если есть готовые средства решения проблем — паттерны опять не нужны, можно просто взять готовые средства.
Это, по-моему, элементарные всё вещи.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Это, по-моему, элементарные всё вещи.
Таак, теперь моя очередь недоумевать
С начала ветки я пишу ровно о том же. Вот основные цитаты, чтоб не размазывать:
По-моему, единственный работающий способ использовать паттерны — не вспоминать про них вовсе. Гораздо полезней изучить Рихтера и Framework Design Guidelines и использовать здравый смысл и знание матчасти.
...
I>FDG это сборник паттернов в чистом виде с той лишь разнией, что паттернам не даются громкие названия, как у фаулера или гоф.
Нет. От слова совсем. Разница примерно такая же, как между прекраснодушным МакКоннелом и хардкорным Рихтером
...
N>Я вот хотел бы написать статейку про те наработки, которые знаю в вопросах паттернов ... А я вот например применяю "Замена стратегии на Func/Action" и обратно. Или "Перенос метода из класса в extension для этого класса" и обратно.
По-моему, называть возможности языка паттернами — это уже перебор. Паттернов Инкрементор и Цикл нам не надо.
Здравствуйте, Sinix, Вы писали:
S>Собственно, о чём мы спорим?
А, ну я как обычно — влез в середину разговора, пока у меня крутится скрипт, и докопался до отдельной фразы, вырванной из контекста.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sinix, Вы писали:
S>>Собственно, о чём мы спорим? S>А, ну я как обычно — влез в середину разговора, пока у меня крутится скрипт, и докопался до отдельной фразы, вырванной из контекста.
Опс
Ну, я той же фигнёй бывает страдаю Ничего страшного, поспорить всё равно приятно было!
S>Задача книги — всего лишь дать разработчикам общий язык. Паттерн у них — это в первую очередь описание проблемы. И четкого описания проблемы для хоть сколько-то опытного разработчика достаточно, чтобы изобрести решение самостоятельно. Описание проблемы — это самое главное, что нужно запомнить из этой книжки! Но это первое, что обычно забывают после прочтения. Зато диаграммы классов все зазубривают наизусть.
S>Всё сообщение стоит прочитать целиком, оно маленькое
Сообщение маленькое, но неверное. У GoF, начнем с самого главного, вообще нет внятного описания проблемы, нигде, ни разу. Сходу подаётся решение, а до самой проблемы надо еще докопаться. Проблема описывается в терминах её решения.
Здравствуйте, Sinix, Вы писали:
N>>Возможны ли случаи, когда замена стратегии на Func/Action улучшит внутреннюю структуру кода не меняя внешнего поведения? Я надеюсь все согласятся, что да. А стало быть это рефакторинг. S>Неа, тут та же путаница: рефакторинг — это общее описание проблемы ("фиговый код, нужно улучшить"). Замена стратегии на Func/Action — это конкрентый инструмент.
Рефакторинг вдруг стал общим описанием проблемы ?
S>Если их смешивать, то получается путаница, как с фасадом-медиатором-посредником-мостом. Решение по большому счёту одно и то же, проблемы разные.
Оно и видно, что в твоей трактовке рефакторинг это улучшайзер вида "фиговый код, нужно улучшить".
На самом деле рефакторинг всего лишь изменения одного лишь [микро|макро]дизайна без изменения других аспектов.
например, переименовать xyz в requiredEntries — рефакторинг. Обратное изменение, то есть requiredEntries в xyz так же есть рефакторинг.
N>>Именно, сначала вырабатывается паттерн, что если нам нужен цикл "10 раз", то объявляем переменную вначале, делаем тут же её if проверку, потом в конце прибавить переменную, написать комментарий S>Ну блин, это не паттерн в терминах оригинального GoF/Фаулера. Иначе мы так дойдём до "с++ — это сборник паттернов для ассемблера" и паттерн у нас превратится в баззворд, который обозначает так много, что не обозначает ничего.
Правильно. Паттерны в терминах GoF вообще мало чего стоят. Все языковые фичи в детстве были какими то паттернами. И паттерн действительно есть баззворд, который совсем мало чего значит, ну примерно как стиль.
Одно дело — сигнал, событие, однонаправленый, двунаправленый, широковещательный другое дело — обсервер, шина и тд и тд. Первые — категорически хорошо. Вторые — категорическое зло, если встречаются вместо первых.
Здравствуйте, SergeyT., Вы писали:
ST>Подход на основе делегатов является очень популярным решением, хотя и применяется зачастую локально в классе (я назвал его локальным методом шаблона). ST> void WithReadLock(this ReaderWriterLockSlim rwLock, Action action)
Это ты функцию принимающую одно замыкание обозвал "локальным методом шаблона"
