Re: Сергей Тепляков книжку написал!
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 13.04.15 15:28
Оценка: 254 (7) +2 :))) :))) :))) :)
Здравствуйте, LaptevVV, Вы писали:

Тот неловкий момент, когда о поступлении своей книги в продажу узнаешь с rsdn-а
Валерий, спасибо большое!

LVV>Паттерны проектирования на платформе .NET

LVV>http://www.ozon.ru/context/detail/id/31789305/
LVV>На Озоне есть оглавление и фрагменты текста.
LVV>Описаны основные паттерны из книги Банды 4 и SOLID.
Сергей Тепляков книжку написал!
От: LaptevVV Россия  
Дата: 12.04.15 10:03
Оценка: 205 (12) +2
Паттерны проектирования на платформе .NET
http://www.ozon.ru/context/detail/id/31789305/
На Озоне есть оглавление и фрагменты текста.
Описаны основные паттерны из книги Банды 4 и SOLID.

Предварительный заказ.
Я — уже...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Сергей Тепляков книжку написал!
От: Qulac Россия  
Дата: 12.04.15 20:27
Оценка: 21 (2) +5
Здравствуйте, LaptevVV, Вы писали:

LVV>Паттерны проектирования на платформе .NET

LVV>http://www.ozon.ru/context/detail/id/31789305/
LVV>На Озоне есть оглавление и фрагменты текста.
LVV>Описаны основные паттерны из книги Банды 4 и SOLID.

LVV>Предварительный заказ.

LVV>Я — уже...

Тема паттернов уже заезжена, что дальше ехать некуда...
Программа – это мысли спрессованные в код
Re[2]: Сергей Тепляков книжку написал!
От: mtnl  
Дата: 13.04.15 03:44
Оценка: +4
Здравствуйте, Qulac, Вы писали:

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


LVV>>Паттерны проектирования на платформе .NET

LVV>>http://www.ozon.ru/context/detail/id/31789305/
LVV>>На Озоне есть оглавление и фрагменты текста.
LVV>>Описаны основные паттерны из книги Банды 4 и SOLID.

LVV>>Предварительный заказ.

LVV>>Я — уже...

Q>Тема паттернов уже заезжена, что дальше ехать некуда...


Для вас может заезженная, а студентам ещё на собеседование идти
Re: Сергей Тепляков книжку написал!
От: mapnik США http://www.hooli.xyz/
Дата: 13.04.15 06:53
Оценка: :)))
Здравствуйте, LaptevVV, Вы писали:

LVV>Предварительный заказ.

LVV>Я — уже...

Профессор, вы как человек умудренный опытом и уже писавший подобные литературные произведения просто обязаны поподробнее рассказать о маститом авторе, выпустившем эту прекрасную книгу.
Кто такой, где работал до последнего времени...
Re: Глава 5. Паттерн «Наблюдатель»
От: Qbit86 Кипр
Дата: 11.05.15 14:32
Оценка: 14 (2)
В мотивации не упомянута ошибка в архитектуре встроенных событий .NET, усложняющая отписку (тем самым косвенно поощряя утечки):
// Подписка:
subject.SomeEvent += (sender, e) => { ... };

// Отписка:
subject.SomeEvent -= ???

вместо правильного
// Подписка:
IDisposable token = subject.SomeEvent += (sender, e) => { ... };

// Отписка:
token.Dispose();


В Rx так и сделано; хотя вот Эрик Мейер недавно написал: «In the original Rx .NET I made the mistake to have `Subscribe` return an `IDisposable` instead of making `IObserver` implement `IDisposable`»
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Сергей Тепляков книжку написал!
От: LaptevVV Россия  
Дата: 13.06.15 17:34
Оценка: 8 (1) +1
LVV>>Паттерны проектирования на платформе .NET
V>Жалею что сразу вместе с новостью на хабре не купил печатный вариант.
V>Теперь всё время нет в продаже.
На Озоне можно сделать оповещение о появлении книжки в продаже.
Если много таких требований будет, то могут сделать допечатку.

Вон книжка Вирта по алгоритмам несколько раз допечатывалась.
И Рефакторинг — регулярно.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Сергей Тепляков книжку написал!
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 27.05.15 17:29
Оценка: 6 (2)
Здравствуйте, breee breee, Вы писали:

BB>Здравствуйте, SergeyT., Вы писали:


ST>>Тот неловкий момент, когда о поступлении своей книги в продажу узнаешь с rsdn-а


BB>Добрый день.

BB>Читаю сейчас Вашу книгу, нравится, но есть такой вопрос-пожелание. Вы часто в тексте приводите ссылки на свои или чьи-то статьи, к которым хотелось бы позднее вернуться. Было бы очень удобно, чтобы где-нибудь, например, в Вашем блоге был полный перечень этих ссылок в том порядке, в котором они встречаются в книге. Сейчас по прочтении трети книги возвращаться и сканировать текст на наличие ссылок довольно проблематично.

Завел багу/задачу здесь. Сделаю.
Re[3]: Глава 2. Паттерн «Шаблонный метод»
От: Qbit86 Кипр
Дата: 12.05.15 00:11
Оценка: 5 (1) +1
Здравствуйте, SergeyT., Вы писали:

ST>Но я решил ее не включать, поскольку NVI — это достаточно редкий паттерн в .NET-е. Я в живую не разу не видел его активного применения.


На мой взгляд, NVI не столько паттерн, сколько некое «идеальное» применение наследования и полиморфизма в ООП. Сродни правилу не плодить глобальных переменных или не злоупотреблять goto, только ещё не устоявшееся.

ST>В моем примере, я выделил только шаги первого уровня, оставив шаги второго уровня на усмотрения наследнику. Хорошо это или плохо, сказать сложно, но на практике, я бы правда остановился бы именно на этом, а не стал бы городить огород еще и с выделением еще более мелких шагов. В реальности, переопределение даже этих шагов — это дело достаточно редкое, городить еще один уровень абстракции — ИМХО, оверкил.


Тут вопрос не в общей применимости паттерна Шаблонный Метод и насколько исчерпывающими должны быть подшаги. Просто попутно возникла другая, объективная проблема: непонятно, надо ли наследнику звать base.DisposeXxx(); и если вдруг не позовёт, то получим утечку. Она может возникнуть и в других ситуациях. Дизайн, который недопускает определённой потенциальной ошибки со стороны пользователя, лучше дизайна, который допускает. Метод типа DisposeManagedResources() был перегружен задачами: выполнял и роль точки настройки (переопределение в потомках), и интерфейс использования (вызов в потомках). При следовании идиоме NVI нет конфликтующих ролей.

А структура может быть такой же плоской, без лишнего уровня:
#region "Interface for inheritors"

protected virtual void DisposeNativeResourcesCore()
{
    // Intended to be empty.
}

protected virtual void DisposeManagedResourcesCore()
{
    // Intended to be empty.
}

#endregion

#region "Interface for callers"

public /*non-virtual*/ void Dispose()
{
    // Dispose own native resources:
    Release(_buffer);
    ...

    // Dispose inheritors' native resources:
    DisposeNativeResourcesCore();

    // Dispose own managed resources:
    _handle?.Dispose();
    ...

    // Dispose inheritors' managed resources:
    DisposeManagedResourcesCore();

    GC.SuppressFinalize(this);
}

#endregion
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Сергей Тепляков книжку написал!
От: dalmal  
Дата: 12.04.15 20:33
Оценка: +2
Здравствуйте, Qulac, Вы писали:

Q>Тема паттернов уже заезжена, что дальше ехать некуда...

Не согласен. Хороших книжек довольно мало.
Re[2]: Сергей Тепляков книжку написал!
От: ShaggyOwl Россия http://www.rsdn.org
Дата: 13.04.15 07:03
Оценка: +2
Здравствуйте, mapnik, Вы писали:

M>Кто такой, где работал до последнего времени...


Почувствуй себя профессором, посмотри профиль на рсдн

http://rsdn.ru/account/info/34036
http://rsdn.ru/Forum/?uid=34036&ArticleOnly=1
Хорошо там, где мы есть! :)
Re: Глава 6. Паттерн «Посетитель»
От: Qbit86 Кипр
Дата: 12.05.15 07:17
Оценка: +2
Я эту главу ещё не читал, но уже готов осуждать! Посетитель мой горячо любимый паттерн (хотя не помню, когда его использовал, и вообще скрипач не нужен), но никто не может его внятно описать.

Никто!
Глаза у меня добрые, но рубашка — смирительная!
Re: Сергей Тепляков книжку написал!
От: LaptevVV Россия  
Дата: 22.04.15 18:30
Оценка: 51 (1)
Уже можно заказывать не предварительно!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Сергей Тепляков книжку написал!
От: LaptevVV Россия  
Дата: 28.04.15 16:03
Оценка: 34 (1)
I>Судя по примеру Стратегия подход ничем принципиально от GoF не отличается. Т.е. компиляция на заезженую тему. С учетом того, что у GoF телега впереди лошади, т.е. постановка проблемы через описание её решения, книга представляет интерес для только для определенного контингента.
Я уже получил, начал читать.
Ты не прав.
1. Если мы всех программеров поделим на касты: юниор, постюниор, мидл, постмидл, эксперт, — то книжка написана как минимум постмидлом для мидлов.
Начинающим и студентам будет весьма сложно. Чел должен иметь от 3 до 5 лет опыта, чтобы читать. Причем, желательно опыта Явы или Додиеза с фреймворками.
2. В книжке есть сквозной пример: простое приложение импорта лог-файлов для последующего полнотекстового поиска. На нем все паттерны и показываются.
3. Паттерны не просто описываются, а сравниваются их разные реализации. В том числе и с помощью механизмов Додиеза — делегаты, например.
Да еще паттерны сравниваются между собой.
4. В каждой главке есть упоминание о применении данного паттерна в составе NETframework.

Ну и что не понравилось.
1. Коды напечатаны очень плохо. Очень много пустых строк. Да еще интервал между строками больше, чем интервал в тексте.
Не знаю, с чем связано — макет такой был, что ли? Или уже в типографии накосячили...
2. В одном месте принцип подстановки Лисков назван принципом замещения Лисков — как будто переводил с английского переводчик — не программист...

Дочитаю — отпишусь еще.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Тепляков молодец
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.04.15 21:05
Оценка: 24 (1)
Здравствуйте, Qbit86, Вы писали:

I>>Судя по примеру Стратегия подход ничем принципиально от GoF не отличается. Т.е. компиляция на заезженую тему. С учетом того, что у GoF телега впереди лошади, т.е. постановка проблемы через описание её решения


Q>Может, мы разные отрывки читали?


Смотри сам — назначение подаётся в терминах решения. Мотивация — снова в терминах решения. А где описание того, какую проблему решает эта самая стратегия ?

Q>Много внимания уделено отличиям современных реализаций от классического GoF-варианта: как .NET-специфичным, так и принципиальным. Примеры отсылают к стандартным классам в BCL. В наличие уместные философские отступления («выделять интерфейс или нет»).


Это не интересно. Факт в том, что проблема по прежнему подаётся через её решение, а потому толпы адептов по прежнему будут пытаться применять паттерны вместо решения.
Re[2]: Сергей Тепляков книжку написал!
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 12.06.15 16:12
Оценка: 8 (1)
Здравствуйте, Venom, Вы писали:

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


LVV>>Паттерны проектирования на платформе .NET


V>Жалею что сразу вместе с новостью на хабре не купил печатный вариант.

V>Теперь всё время нет в продаже.

Мда... А мне издатель написал, что допечатывать летом, скорее всего не будут, поскольку идет сезонный спад и они боятся простоев (пролежев?) книги на складах. Так что есть все шансы джать аж до осени, если не получится найти где-то в локальных или тырнет-магазинах сейчас.
Re[3]: Глава 2. Паттерн «Шаблонный метод»
От: koodeer  
Дата: 12.05.15 11:28
Оценка: 5 (1)
Здравствуйте, SergeyT., Вы писали:

ST>У меня в исходном варианте даже врезка такая была. Но я решил ее не включать, поскольку NVI — это достаточно редкий паттерн в .NET-е. Я в живую не разу не видел его активного применения.


Цитата из книги Трэя Нэша "C# 2010 Ускоренный курс для профессионалов":

Шаблон NVI широко применяется в библиотеках .NET Framework, и по совершенно очевидным причинам он кочует из руководства в руководство по проектированию библиотек Microsoft.

Сам я не берусь судить, насколько это правда. Оставим на совести автора.

Там же кстати, упомянуто private virtual из C++ в контексте NVI.
Re: Глава 2. Паттерн «Шаблонный метод»
От: Qbit86 Кипр
Дата: 11.05.15 11:30
Оценка: 1 (1)
В главе про Template Method не раскрыта важнейшая тема про NVI (Non-Virtual Interface), прекрасно (на целых две страницы) расписанная в книжке Саттера и Александреску.

Рекомендованная реализация паттерна Dispose Pattern, на мой взгляд, некорректна. Цитата к листингу 2.9: «Автору производного класса будет четко понятно, что можно делать в переопрделенном методе, а что — нет». Вопрос: откуда автору производного класса будет понятно, нужно ли вызывать в переопределённом методе DisposeNativeResources() этот же метод базового класса?

Чтобы избежать подобных вопросов как раз и применяется паттерн Шаблонный Метод, но в примере он почему-то не используется до конца!
Должно быть (имена утрированы):
private /*non-virtual*/ void DisposeNativeResources()
{
    ReleaseBuffer(_buffer);
    DisposeNativeResourcesCore_OverrideIfYouWant();
}

protected virtual /*non-abstract but empty*/ void DisposeNativeResourcesCore_OverrideIfYouWant()
{
    // Этот метод абстрактный, тут не должно быть никакой реализации.
    // Автор производного класса может переопределить этот шаг, а может не переопределять.
    // Он может вызывать этот метод, может не вызывать. Без разницы, метод же пустой.
    // Буффер этого класса в любом случае освободится; ошибка невызова метода базового класса невозможна.
}
Глаза у меня добрые, но рубашка — смирительная!
Re: Глава 4. Паттерн «Итератор»
От: Qbit86 Кипр
Дата: 11.05.15 13:13
Оценка: 1 (1)
Не кажется ли вам, что более естественным интерфейсом C#-like-итератора был бы не такой:
MoveNext(): bool
Current: T

а такой:
GetNext(): Option<T>

?

Теоретически, если игнорировать метод Reset() и интерфейс IDisposable, то в принципе интерфейс итератора вырождается до одного метода, так что интерфейс итерируемого может выглядеть лаконичнее:
GetIterator(): Action<Option<T>>
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: Сергей Тепляков книжку написал!
От: Sinix  
Дата: 25.05.15 10:09
Оценка: 1 (1)
Здравствуйте, breee breee, Вы писали:

BB>Читаю сейчас Вашу книгу, нравится, но есть такой вопрос-пожелание. Вы часто в тексте приводите ссылки на свои или чьи-то статьи, к которым хотелось бы позднее вернуться. Было бы очень удобно, чтобы где-нибудь, например, в Вашем блоге был полный перечень этих ссылок в том порядке, в котором они встречаются в книге. Сейчас по прочтении трети книги возвращаться и сканировать текст на наличие ссылок довольно проблематично.


В большинстве свежих книжек делается проще: заводится свой url shortener вида SergeyTeplyakovPatternsBook.com/123, где 123 — номер ссылки. И на всякий случай в конце книги, после индекса, приводится нумерованный список "номер ссылки — оригинальный адрес". Чтобы, если что, все ссылки за один приём распознать.
Re[4]: Глава 6. Паттерн «Посетитель», Expression problem
От: Qbit86 Кипр
Дата: 27.05.15 19:53
Оценка: 1 (1)
Здравствуйте, SergeyT., Вы писали:

Имхо, полезно явно упомянуть про связь паттерна с т.н. Expression problem:
1) ООП:
  a) Клиентам иерархии классов легко её расширять новыми вариантами.
  b) Клиентам иерархии классов невозможно её расширять новыми полиморфными операциями.


А нам хочется наоборот:

2) ПМ:
  a) Клиентам иерархии классов легко её расширять новыми полиморфными операциями.
  b) Клиентам иерархии классов невозможно её расширять новыми вариантами.


Всё, что делает паттерн Посетитель, это выворачивает наизнанку иерархию вариантов, и создаёт параллельную иерархию «команд». В ней исходным полиморфным операциям соответствуют один к одному классы посетителей. А исходным классам вариантов соответствуют один к одному полиморфные методы Visit(). Т.о. транспонируя исходную иерархию, мы переходим от сложной ситуации 2) к решаемой задаче 1).
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Тепляков молодец
От: Qbit86 Кипр
Дата: 27.04.15 19:15
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Судя по примеру Стратегия подход ничем принципиально от GoF не отличается. Т.е. компиляция на заезженую тему. С учетом того, что у GoF телега впереди лошади, т.е. постановка проблемы через описание её решения


Может, мы разные отрывки читали?

Много внимания уделено отличиям современных реализаций от классического GoF-варианта: как .NET-специфичным, так и принципиальным. Примеры отсылают к стандартным классам в BCL. В наличие уместные философские отступления («выделять интерфейс или нет»).

Если бы в моё подчинение вдруг передали бы студентов-джуниоров, я бы предпочёл, чтобы про паттерн Стратегия они прочитали в книжке Теплякова, и НЕ читали в книжке GoF.

Жду доставки, чтобы оценить описание других паттернов.

I>книга представляет интерес для только для определенного контингента.


Rehashing fundamentals ещё никогда не вредил.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Глава 5. Паттерн «Наблюдатель»
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 11.05.15 23:36
Оценка: +1
Здравствуйте, Qbit86, Вы писали:

Q>В мотивации не упомянута ошибка в архитектуре встроенных событий .NET, усложняющая отписку (тем самым косвенно поощряя утечки):

Q>[cs]
Q>// Подписка:
Q>subject.SomeEvent += (sender, e) => { ... };

Спасибо, учту.

Но это не ошибка в архитектуре встроенных событий в .NET. Они проектировались за 5-6 лет до появления анонимных методов, которые оказались несовместимыми с процессом подписки отписки.

Для сценариев, для которых изначально разрабатывались события, отписка от делегата именно с помощью -= является более удобной. Вспомните, винформы. Наличие disposable отписки привело бы к появлению кучи дополнительных полей, управлять которыми было бы не сильно удобно.
Re[2]: Сергей Тепляков книжку написал!
От: breee breee  
Дата: 25.05.15 09:36
Оценка: +1
Здравствуйте, SergeyT., Вы писали:

ST>Тот неловкий момент, когда о поступлении своей книги в продажу узнаешь с rsdn-а


Добрый день.
Читаю сейчас Вашу книгу, нравится, но есть такой вопрос-пожелание. Вы часто в тексте приводите ссылки на свои или чьи-то статьи, к которым хотелось бы позднее вернуться. Было бы очень удобно, чтобы где-нибудь, например, в Вашем блоге был полный перечень этих ссылок в том порядке, в котором они встречаются в книге. Сейчас по прочтении трети книги возвращаться и сканировать текст на наличие ссылок довольно проблематично.
Re[6]: Спойлеры!
От: Qbit86 Кипр
Дата: 27.05.15 22:28
Оценка: :)
Здравствуйте, SergeyT., Вы писали:

ST>Про Expression Problem говорится в главе про принцип Открыт-Закрыт. Большая часть философских рассуждений по поводу ООП vs. FP находится именно в главе про Открыт-Закрыт.


Такое надо писать под тегом <spoiler>! Не все ещё дочитали!
Глаза у меня добрые, но рубашка — смирительная!
Re[7]: Спойлеры!
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 27.05.15 23:32
Оценка: :)
Здравствуйте, Qbit86, Вы писали:

ST>>Про Expression Problem говорится в главе про принцип Открыт-Закрыт. Большая часть философских рассуждений по поводу ООП vs. FP находится именно в главе про Открыт-Закрыт.


Q>Такое надо писать под тегом <spoiler>! Не все ещё дочитали!


Виноват-с Просто раз уж речь зашла за Expression Problem, то не смог оставить этот момент без внимания. Буду аккуратнее в следующий раз
Re[2]: Сергей Тепляков книжку написал!
От: LaptevVV Россия  
Дата: 13.04.15 07:10
Оценка:
M>Профессор, вы как человек умудренный опытом и уже писавший подобные литературные произведения просто обязаны поподробнее рассказать о маститом авторе, выпустившем эту прекрасную книгу.
M>Кто такой, где работал до последнего времени...
Читайте: http://www.sergeyteplyakov.blogspot.ru/
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Сергей Тепляков книжку написал!
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 13.04.15 15:29
Оценка:
Здравствуйте, mapnik, Вы писали:

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

M>Кто такой, где работал до последнего времени...

Да я и сам о себе могу рассказать

* Профиль на rsdn
* Блог
* Где работал до последнего времени и где работаю сейчас
* Немного о том, как до этого дошел

Так что если есть вопросы: то всегда пожалуйста. Хоть в личку, хоть на форуме.
Re[2]: Сергей Тепляков книжку написал!
От: LaptevVV Россия  
Дата: 13.04.15 16:10
Оценка:
ST>Тот неловкий момент, когда о поступлении своей книги в продажу узнаешь с rsdn-а
ST>Валерий, спасибо большое!
Еще не в продажу — только анонс.
Но я всегда анонсы заказываю — чтоб не прозевать.
Если что — с тебя автограф...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Сергей Тепляков книжку написал!
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 13.04.15 16:26
Оценка:
Здравствуйте, LaptevVV, Вы писали:

ST>>Тот неловкий момент, когда о поступлении своей книги в продажу узнаешь с rsdn-а

ST>>Валерий, спасибо большое!
LVV>Еще не в продажу — только анонс.

Да, я это и имел ввиду. Просто я не знал, что книга уже где-то появилась до того момента, пока не зашел на rsdn

LVV>Но я всегда анонсы заказываю — чтоб не прозевать.


Мысль дельная.

LVV>Если что — с тебя автограф...


Договорились
Re: Сергей Тепляков книжку написал!
От: Abyx Россия  
Дата: 13.04.15 19:10
Оценка:
Здравствуйте, LaptevVV, Вы писали:

Вот этот Сергей Тепляков — http://ru.stackoverflow.com/a/415932/177684 ?
Ясно-понятно.
In Zen We Trust
Re: Антипринципы
От: AK107  
Дата: 17.04.15 04:56
Оценка:
Ну зачем, если выше по всему тексту оглавления используется слово "Паттерн" ? Ну есть же Антипаттерн
Отредактировано 17.04.2015 4:56 AK107 . Предыдущая версия .
Re: Сергей Тепляков книжку написал!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.04.15 17:45
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Паттерны проектирования на платформе .NET

LVV>http://www.ozon.ru/context/detail/id/31789305/
LVV>На Озоне есть оглавление и фрагменты текста.
LVV>Описаны основные паттерны из книги Банды 4 и SOLID.

Судя по примеру Стратегия подход ничем принципиально от GoF не отличается. Т.е. компиляция на заезженую тему. С учетом того, что у GoF телега впереди лошади, т.е. постановка проблемы через описание её решения, книга представляет интерес для только для определенного контингента.
Re[3]: Сергей Тепляков книжку написал!
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 28.04.15 16:25
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Ну и что не понравилось.

LVV>1. Коды напечатаны очень плохо. Очень много пустых строк. Да еще интервал между строками больше, чем интервал в тексте.
LVV>Не знаю, с чем связано — макет такой был, что ли? Или уже в типографии накосячили...

Да, это такой макет, и я не придал этому значения

LVV>2. В одном месте принцип подстановки Лисков назван принципом замещения Лисков — как будто переводил с английского переводчик — не программист...


А вот это уже мой косяк. У меня в голове он почему-то называется именно "принципом замещения". Исправлю.

Запостил багу: https://github.com/SergeyTeplyakov/DesignPatternsBookIssues/issues/1
Будем ченить.

LVV>Дочитаю — отпишусь еще.

Спасибо
Re[3]: Сергей Тепляков книжку написал!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.04.15 19:29
Оценка:
Здравствуйте, LaptevVV, Вы писали:

I>>Судя по примеру Стратегия подход ничем принципиально от GoF не отличается. Т.е. компиляция на заезженую тему. С учетом того, что у GoF телега впереди лошади, т.е. постановка проблемы через описание её решения, книга представляет интерес для только для определенного контингента.

LVV>Я уже получил, начал читать.
LVV>Ты не прав.
LVV>1. Если мы всех программеров поделим на касты: юниор, постюниор, мидл, постмидл, эксперт, — то книжка написана как минимум постмидлом для мидлов.

В этой книге продолжается тема GoF, фактически подмена решения проблемы и проектирование на перебор паттернов. Кому ты это адресуешь, совершенно неинтересно.

LVV>2. В книжке есть сквозной пример: простое приложение импорта лог-файлов для последующего полнотекстового поиска. На нем все паттерны и показываются.


Плохой пример. Нужны реальные проблемы, а не высосаные из пальца. Вот скажем у Джошуа Кериевски, Физерса и того же Кента Бека очень четкий подход, резко отличный от GoF. Посмотри туда для начала.
Re[4]: Сергей Тепляков книжку написал!
От: LaptevVV Россия  
Дата: 29.04.15 03:53
Оценка:
LVV>>1. Если мы всех программеров поделим на касты: юниор, постюниор, мидл, постмидл, эксперт, — то книжка написана как минимум постмидлом для мидлов.
I>В этой книге продолжается тема GoF, фактически подмена решения проблемы и проектирование на перебор паттернов. Кому ты это адресуешь, совершенно неинтересно.
Не. Адресат — важен. Прежде, чем книжку писать — важно определиться с тем, кому книжка предназначена. Вот я четко знал, что пишу для своих студентов.
Соответственно и строил изложение.
Здесь книжка как минимум для постюниоров — студенты мало что поймут.
LVV>>2. В книжке есть сквозной пример: простое приложение импорта лог-файлов для последующего полнотекстового поиска. На нем все паттерны и показываются.
I>Плохой пример. Нужны реальные проблемы, а не высосаные из пальца. Вот скажем у Джошуа Кериевски, Физерса и того же Кента Бека очень четкий подход, резко отличный от GoF. Посмотри туда для начала.
Ну, если лог-файлы существуют — значит это кому-нибудь нужно?
Физерс — это кто?
Остальных — читал.
Но они паттерны стали в реальных задачах прописывать только после книжки банды 4.
Объясняя практическую природу паттернов.
А книжка банды — это диссер Гаммы...
Совершенно академаческий подход.
Или справочник...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Сергей Тепляков книжку написал!
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 29.04.15 04:20
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Паттерны проектирования на платформе .NET

LVV>http://www.ozon.ru/context/detail/id/31789305/
LVV>На Озоне есть оглавление и фрагменты текста.
LVV>Описаны основные паттерны из книги Банды 4 и SOLID.

Этой книги не читал, осуждать не буду, но, единственное нормальное описание паттернов которе я когда либо встречал было в POSA, все остальное какое-то невероятно унылое УГ, включая Банду 4-х. Да, я говорю не про содержание, а про манер изложения.
Re[5]: Сергей Тепляков книжку написал!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.04.15 06:43
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Не. Адресат — важен. Прежде, чем книжку писать — важно определиться с тем, кому книжка предназначена. Вот я четко знал, что пишу для своих студентов.

LVV>Соответственно и строил изложение.
LVV>Здесь книжка как минимум для постюниоров — студенты мало что поймут.

Здесь книга для фанатичных адептов паттернов.

I>>Плохой пример. Нужны реальные проблемы, а не высосаные из пальца. Вот скажем у Джошуа Кериевски, Физерса и того же Кента Бека очень четкий подход, резко отличный от GoF. Посмотри туда для начала.

LVV>Ну, если лог-файлы существуют — значит это кому-нибудь нужно?
LVV>Физерс — это кто?

Майкл Физерс. Legacy Code

LVV>Но они паттерны стали в реальных задачах прописывать только после книжки банды 4.


Вообще говоря GoF не изобретали паттерны. Они всего то структурировали имеющиеся решения.
Re[6]: Сергей Тепляков книжку написал!
От: LaptevVV Россия  
Дата: 29.04.15 11:54
Оценка:
LVV>>Физерс — это кто?
I>Майкл Физерс. Legacy Code
А, понятно. Спасибо.
LVV>>Но они паттерны стали в реальных задачах прописывать только после книжки банды 4.
I>Вообще говоря GoF не изобретали паттерны. Они всего то структурировали имеющиеся решения.
Всякая наука начинается с классификации...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Сергей Тепляков книжку написал!
От: HolyNick  
Дата: 29.04.15 14:59
Оценка:
Ну, что Вы.)
А выучить по десять пунктов за и против (всего, наверно, около 1000 наберется) использования конкретного паттерна. Что может быть интереснее.)) Не можешь(хочешь) думать — развивай память))
Re[2]: Глава 2. Паттерн «Шаблонный метод»
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 11.05.15 23:33
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>В главе про Template Method не раскрыта важнейшая тема про NVI (Non-Virtual Interface), прекрасно (на целых две страницы) расписанная в книжке Саттера и Александреску.


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

Q>Рекомендованная реализация паттерна Dispose Pattern, на мой взгляд, некорректна. Цитата к листингу 2.9: «Автору производного класса будет четко понятно, что можно делать в переопрделенном методе, а что — нет». Вопрос: откуда автору производного класса будет понятно, нужно ли вызывать в переопределённом методе DisposeNativeResources() этот же метод базового класса?


Q>Чтобы избежать подобных вопросов как раз и применяется паттерн Шаблонный Метод, но в примере он почему-то не используется до конца!

Q>Должно быть (имена утрированы):
Q>
Q>private /*non-virtual*/ void DisposeNativeResources()
Q>{
Q>    ReleaseBuffer(_buffer);
Q>    DisposeNativeResourcesCore_OverrideIfYouWant();
Q>}

Q>protected virtual /*non-abstract but empty*/ void DisposeNativeResourcesCore_OverrideIfYouWant()
Q>{
Q>    // Этот метод абстрактный, тут не должно быть никакой реализации.
Q>    // Автор производного класса может переопределить этот шаг, а может не переопределять.
Q>    // Он может вызывать этот метод, может не вызывать. Без разницы, метод же пустой.
Q>    // Буффер этого класса в любом случае освободится; ошибка невызова метода базового класса невозможна.
Q>}
Q>


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

В моем примере, я выделил только шаги первого уровня, оставив шаги второго уровня на усмотрения наследнику. Хорошо это или плохо, сказать сложно, но на практике, я бы правда остановился бы именно на этом, а не стал бы городить огород еще и с выделением еще более мелких шагов. В реальности, переопределение даже этих шагов — это дело достаточно редкое, городить еще один уровень абстракции — ИМХО, оверкил.
Re[3]: CompsiteDisposable
От: Qbit86 Кипр
Дата: 12.05.15 00:31
Оценка:
Здравствуйте, SergeyT., Вы писали:

ST>Наличие disposable отписки привело бы к появлению кучи дополнительных полей, управлять которыми было бы не сильно удобно.


Ну не куча, а одно поле типа CompsiteDisposable. То есть мы подписываемся и сразу же кладём «напоминалку» об отложенной отписке:
    var s = subject.SomeEvent.Subscribe(e => {...});
    _subscriptions.Add(s);
...
public void Dispose()
{
    _subscriptions.Dispose();
}

Отписка не отторжена от подписки; её легче не потерять, если не откладывать на потом, а сразу запланировать.
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: Глава 2. Паттерн «Шаблонный метод»
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 12.05.15 01:37
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, SergeyT., Вы писали:


ST>>Но я решил ее не включать, поскольку NVI — это достаточно редкий паттерн в .NET-е. Я в живую не разу не видел его активного применения.


Q>На мой взгляд, NVI не столько паттерн, сколько некое «идеальное» применение наследования и полиморфизма в ООП. Сродни правилу не плодить глобальных переменных или не злоупотреблять goto, только ещё не устоявшееся.


Можно назвать это патертном, идиомой или идеальным применением наследования и полимфорфизма в ООП. Проблема в том, что это не слишком применимо на практике в .NET.
Когда я писал на С++, то после книги Саттера начал активно применять эту идиому на практике. В .NET-е я практически ее не применяю и не вижу ее применения сообществом.

Q>Тут вопрос не в общей применимости паттерна Шаблонный Метод и насколько исчерпывающими должны быть подшаги. Просто попутно возникла другая, объективная проблема: непонятно, надо ли наследнику звать base.DisposeXxx(); и если вдруг не позовёт, то получим утечку. Она может возникнуть и в других ситуациях. Дизайн, который недопускает определённой потенциальной ошибки со стороны пользователя, лучше дизайна, который допускает. Метод типа DisposeManagedResources() был перегружен задачами: выполнял и роль точки настройки (переопределение в потомках), и интерфейс использования (вызов в потомках). При следовании идиоме NVI нет конфликтующих ролей.


На всякий случай напомню, что в моем коде нет нарушения NVI, поскольку методы DisposeNative/DisposeManaged методы являются защищенными.


Q>А структура может быть такой же плоской, без лишнего уровня:

Q>
Q>#region "Interface for inheritors"

Q>protected virtual void DisposeNativeResourcesCore()
Q>{
Q>    // Intended to be empty.
Q>}

Q>protected virtual void DisposeManagedResourcesCore()
Q>{
Q>    // Intended to be empty.
Q>}

Q>#endregion

Q>#region "Interface for callers"

Q>public /*non-virtual*/ void Dispose()
Q>{
Q>    // Dispose own native resources:
Q>    Release(_buffer);
Q>    ...

Q>    // Dispose inheritors' native resources:
Q>    DisposeNativeResourcesCore();

Q>    // Dispose own managed resources:
Q>    _handle?.Dispose();
Q>    ...

Q>    // Dispose inheritors' managed resources:
Q>    DisposeManagedResourcesCore();

Q>    GC.SuppressFinalize(this);
Q>}

Q>#endregion
Q>


Здесь все сложно С одной стороны, приведенный подход решает проблему "а нужно ли вызывать базовый метод", но решает он лишь на один уровень наследников. Ведь теперь, если у приведенного класса появится два уровня наследования, то мы столкнемся с той же самой проблемой: а нужно ли наследнику второго уровня вызывать DisposeNative/DisposeManaged или нет. Можно конечно, следовать шаблонному методу постоянно и на каждом уровне наследования делать переопределенный метод sealed и добавлять еще пару виртуальных методов DisposenativeResourcesCoreLevel2/DisposeManagedResorucesCoreLevel. Но стоит ли оно того? Я не уверен.

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

Есть очень простой способ проверить валидность аргументов тех или иных аргументов.

Вы лично используете предложенный вами подход?

Я даже свой не использую на практике, поскольку на практике смешивания управляемых и управляемых ресурсов не происходит! Я же привел свой вариант, как пример, насколько шаблонный метод позволил бы многим понять намного быстрее разницу между управляемыми и неуправляемыми ресурсами.
Re[3]: Сергей Тепляков книжку написал!
От: мыщъх США http://nezumi-lab.org
Дата: 12.05.15 03:59
Оценка:
Здравствуйте, LaptevVV, Вы писали:

I>>Судя по примеру Стратегия подход ничем принципиально от GoF не отличается. Т.е. компиляция на заезженую тему. С учетом того, что у GoF телега впереди лошади, т.е. постановка проблемы через описание её решения, книга представляет интерес для только для определенного контингента.

LVV>Я уже получил, начал читать.
вы мне порвали шаблон сикель. вы рекомендовали книгу _до_ того как начали ее читать?!
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[4]: Сергей Тепляков книжку написал!
От: LaptevVV Россия  
Дата: 12.05.15 05:18
Оценка:
I>>>Судя по примеру Стратегия подход ничем принципиально от GoF не отличается. Т.е. компиляция на заезженую тему. С учетом того, что у GoF телега впереди лошади, т.е. постановка проблемы через описание её решения, книга представляет интерес для только для определенного контингента.
LVV>>Я уже получил, начал читать.
М>вы мне порвали шаблон сикель. вы рекомендовали книгу _до_ того как начали ее читать?!
На сайте магазина был фрагмент — народ прочитал.
А я не рекомендовал, а сообщил.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: NVI
От: Qbit86 Кипр
Дата: 12.05.15 06:45
Оценка:
Здравствуйте, SergeyT., Вы писали:

Q>>На мой взгляд, NVI не столько паттерн, сколько некое «идеальное» применение наследования и полиморфизма в ООП. Сродни правилу не плодить глобальных переменных или не злоупотреблять goto, только ещё не устоявшееся.

ST>Проблема в том, что это не слишком применимо на практике в .NET. Когда я писал на С++, то после книги Саттера начал активно применять эту идиому на практике.

Так а что такого изменилось в ООП с переходом от C++ к C#, что аргументы Саттера перестали работать? Разве что в кривом и косом C++ была приятная дополнительная фича private virtual (о которой, мне кажется, мало кто знает).

ST>В .NET-е я практически ее не применяю и не вижу ее применения сообществом.


Да я и в C++ не особо-то видел её применение сообществом. Мало ли, о чём там сообщество знает или не знает; это не должно мешать сеять доброе и вечное :)

ST>На всякий случай напомню, что в моем коде нет нарушения NVI, поскольку методы DisposeNative/DisposeManaged методы являются защищенными.


Они мало того, что могут быть вызваны в потомках (без private virtual от этого не уйти). Они ещё и должны быть вызваны в потомках. То есть они являются частью интерфейса вызова, при этом являются виртуальными; это противоречит букве N в NVI.

ST>Здесь все сложно:) С одной стороны, приведенный подход решает проблему "а нужно ли вызывать базовый метод", но решает он лишь на один уровень наследников.


Решить хотя бы на один уровень лучше, чем вообще не решить. Рашать эту проблему для внуков уже на ответственности авторов классов-наследников, и это норма.

ST>Есть очень простой способ проверить валидность аргументов тех или иных аргументов.

ST>Вы лично используете предложенный вами подход?

Да, когда я делаю иерархию классов, всегда начинаю с NVI. Это изначально чуть больше кода в базовом классе (полиморфные функции расслоены на callable и overridable ипостаси), но всегда окупается; проще в наследниках, и можно добавлять непереопределяемые и неотторжимые шаги в методы-оболочки базового класса. Например, в базовом классе в невиртуальных методах может происходить проверка аргументов на границе API «if (argument == null) ...», а в наследниках в переопределённых «виртуальных ядрах» валидность аргументов энфорсится «Debug.Assert(argument != null)».
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: Хорошая книжка
От: Qbit86 Кипр
Дата: 12.05.15 07:23
Оценка:
Здравствуйте, мыщъх, Вы писали:

М>вы мне порвали шаблон сикель. вы рекомендовали книгу _до_ того как начали ее читать?!


Не понял, при чём тут сикель, но я уже начал читать. Щетаю, надабрать.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Сергей Тепляков книжку написал!
От: elmal  
Дата: 12.05.15 07:42
Оценка:
Здравствуйте, Qulac, Вы писали:

Q>Тема паттернов уже заезжена, что дальше ехать некуда...

Ээээ. Есть ли хоть одна книжка по best практикам применения и неприменения паттернов? А то я никогда в жизни ни один паттерн не применял в том виде, в каком они описаны в книжках. Всегда это либо комбинация паттернов. Например не синглтон, как он описан, а синглтон в зависимости от параметров. Разные параметры, разная конфигурация — разные инстансы. Одинаковые конфигурации — одинаковые индексы. Фабрика тоже, когда она мне была нужна, она была нужна вместе с инициализацией объектов, для инициализации приходилось всякие реестры делать, когда объекты при создании регистрируют себя в реестре, и соответственно фабрика в момент создания конкретного объекта учитывает соответствующую информацию. Визитор я никогда в жизни в коде не называл визитором. И по смыслу это просто всегда была лямбда.
Re[5]: Хорошая книжка
От: мыщъх США http://nezumi-lab.org
Дата: 12.05.15 08:17
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, мыщъх, Вы писали:


М>>вы мне порвали шаблон сикель. вы рекомендовали книгу _до_ того как начали ее читать?!


Q>Не понял, при чём тут сикель, но я уже начал читать. Щетаю, надабрать.

Сикль (евр. рас. שקל) — древнееврейская мера драг. металлов
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[2]: Глава 4. Паттерн «Итератор»
От: Jack128  
Дата: 12.05.15 09:04
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Теоретически, если игнорировать метод Reset() и интерфейс IDisposable, то в принципе интерфейс итератора вырождается до одного метода, так что интерфейс итерируемого может выглядеть лаконичнее:

Q>
Q>GetIterator(): Action<Option<T>>
Q>


Ключевые слова для гугления: IEnumerator vs IObserver Push vs Pull iterators
Re[3]: Pull-итераторы
От: Qbit86 Кипр
Дата: 12.05.15 09:13
Оценка:
Здравствуйте, Jack128, Вы писали:

Q>>Теоретически, если игнорировать метод Reset() и интерфейс IDisposable, то в принципе интерфейс итератора вырождается до одного метода, так что интерфейс итерируемого может выглядеть лаконичнее:

Q>>
GetIterator(): Action<Option<T>>


J>Ключевые слова для гугления: IEnumerator vs IObserver Push vs Pull iterators


В моём вопросе речь идёт только про pull-итераторы посредством Action<Option<T>> вместо IEnumerator<T>.
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: Func<Option<T>>
От: Qbit86 Кипр
Дата: 12.05.15 09:15
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>В моём вопросе речь идёт только про pull-итераторы посредством Action<Option<T>> вместо IEnumerator<T>.


Точнее, Func<Option<T>>; неправильно сформулировал сигнатуру в терминах C#.
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: Pull-итераторы
От: Jack128  
Дата: 13.05.15 09:19
Оценка:
Здравствуйте, Qbit86, Вы писали:

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


Q>>>Теоретически, если игнорировать метод Reset() и интерфейс IDisposable, то в принципе интерфейс итератора вырождается до одного метода, так что интерфейс итерируемого может выглядеть лаконичнее:

Q>>>
GetIterator(): Action<Option<T>>


J>>Ключевые слова для гугления: IEnumerator vs IObserver Push vs Pull iterators


Q>В моём вопросе речь идёт только про pull-итераторы посредством Action<Option<T>> вместо IEnumerator<T>.

Хм.
Еще раз посмотрел на твой интерфейс и понял, что не понял как это будет работать -)
var action = collection.GetIterator();
что я теперь должен делать с этим action'ом чтоб получить элементы коллекции ?
Re[5]: Function<T>
От: Qbit86 Кипр
Дата: 13.05.15 09:27
Оценка:
Здравствуйте, Jack128, Вы писали:

Q>>В моём вопросе речь идёт только про pull-итераторы посредством Action<Option<T>> вместо IEnumerator<T>.

J>Еще раз посмотрел на твой интерфейс и понял, что не понял как это будет работать -)
J>var action = collection.GetIterator();
J>что я теперь должен делать с этим action'ом чтоб получить элементы коллекции ?

Я ниже привёл исправленную сигнатуру, Function<> вместо Action<>. То есть итератором является возвращённое замыкание, invoke'ая которое получаем очередные элементы, завёрнутые в Option<T> (Maybe<T>). Перебираем до тех пор, пока очередной возващённый элемент не будет Option<T>.None.
Глаза у меня добрые, но рубашка — смирительная!
Re[6]: Function<T>
От: Jack128  
Дата: 13.05.15 10:57
Оценка:
Здравствуйте, Qbit86, Вы писали:


Q>Я ниже привёл исправленную сигнатуру, Function<> вместо Action<>. То есть итератором является возвращённое замыкание, invoke'ая которое получаем очередные элементы, завёрнутые в Option<T> (Maybe<T>). Перебираем до тех пор, пока очередной возващённый элемент не будет Option<T>.None.

А, не заметил. Ну тогда конечно можно. Только всё равно выкидывать Dispose нельзя. Плюс нужно замену этому трюку искать.
Re[7]: Function<T>
От: Qbit86 Кипр
Дата: 13.05.15 11:40
Оценка:
Здравствуйте, Jack128, Вы писали:

J>А, не заметил. Ну тогда конечно можно. Только всё равно выкидывать Dispose нельзя. Плюс нужно замену этому трюку искать.


Не суть, можно интерфейс до одного метода не выхолащивать, оставить и Dispose(), и Reset(). Просто вместо пары методов MoveNext()/Current использовать один GetNext(), результат которого может как давать значение, так и являться признаком окончания. Duck typing'у не помеха.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Глава 6. Паттерн «Посетитель»
От: Qbit86 Кипр
Дата: 18.05.15 19:38
Оценка:
Q>Я эту главу ещё не читал, но уже готов осуждать! Посетитель мой горячо любимый паттерн (хотя не помню, когда его использовал, и вообще скрипач не нужен), но никто не может его внятно описать.

Неплохая глава.

1) В листинге 6.4 приводится т.н. «функциональная версия паттерна „Посетитель“» ака «самописное сопоставление с образцом». Ты пишешь: «Мы можем добавить несколько перегруженных методов `Match`, которые будут принимать не все возможные типы иерархии, а лишь некоторые наиболее часто используемые». Как ты относишься к варианту передачи словаря методов вместо нескольких фиксированных списков? Сопоставление тогда вырождается в динамический поиск в ручной explicit vtable вместо статически проверяемых «свитчей»-простыней. (Пример пишу без проверки компилятором, мог что-нибудь упустить.)
void Match(IDictionary<Type, Action<LogEntry>> vtable)
{
    // Lookup instead of “switch”.
    Action<LogEntry> action;
    if (vtable.TryGetValue(this.GetType(), out action))
    {
        action(this);
    }
    else
    {
        throw new InvalidOperationException("Unknown LogEntry type.");
    }
}
...
void SaveLogEntry(LogEntry logEntry)
{
    var vtable = new Dictionary<Type, Action<LogEntry>>
    {
        { typeof(ExceptionLogEntry), SaveException },
        { typeof(SimpleLogEntry), SaveSimpleLogEntry },
    }
    logEntry.Match(vtable);
}


2) В листинге 6.1 в методе SaveLogEntry() что-то не в порядке с веткой `else`. Должно быть
if (simpleLogEntry != null)
    SaveSimpleLogEntry(simpleLogEntry);
else
    throw new InvalidOperationException(...);

А лучше сделать метод «плоским», добавив `return`ы вместо `else`.

3) Комментарий названия паттерна от Скотта Мейерса в статье «My Most Important C++ Aha! Moments...Ever»: «Then, one day, I made a fundamental realization: the Visitor Pattern has nothing to do with visitation.»
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Сергей Тепляков книжку написал!
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.05.15 15:33
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Этой книги не читал, осуждать не буду,


Зачем тогда в эту тему писать было?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Глава 5. Паттерн «Наблюдатель»
От: ӍїϛϮϠǷiя-ȺҜ Россия  
Дата: 25.05.15 22:55
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>В мотивации не упомянута ошибка в архитектуре встроенных событий .NET, усложняющая отписку (тем самым косвенно поощряя утечки):

Q>IDisposable token = subject.SomeEvent += (sender, e) => { ... };

Q>// Отписка:

Q>token.Dispose();
Q>[/cs]
кошмар что творится в современном ООП... это уже всё реализовано в Delphi7 15-летней давности.

p.s. давно не занимаюсь программированием сам, но с тех пор ничего не поменялось видимо, кроме названий Free и Dispose.
Re[3]: Delphi 7
От: Qbit86 Кипр
Дата: 25.05.15 23:03
Оценка:
Здравствуйте, ӍїϛϮϠǷiя-ȺҜ, Вы писали:

ӍȺ>кошмар что творится в современном ООП... это уже всё реализовано в Delphi7 15-летней давности.


Что именно реализовано? Приведи хоть синтаксис, а то в сети гуглится только какая-то формошлёпская лабуда в button1_Click-стиле.
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: Сергей Тепляков книжку написал!
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 26.05.15 02:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Зачем тогда в эту тему писать было?


Когда данный пост только появился, написать по сути книги не мог ни кто, так как книги еще не было в продаже. Тем не менее, данный пост послужил не плохой стартовой точкой обсуждения книг по паттернам и паттернов как таковых.

Искренне Ваш КО.
Re[4]: Сергей Тепляков книжку написал!
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.05.15 11:04
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Когда данный пост только появился, написать по сути книги не мог ни кто, так как книги еще не было в продаже. Тем не менее, данный пост послужил не плохой стартовой точкой обсуждения книг по паттернам и паттернов как таковых.


Хочу заметить уважаемому КО, что его сообщение не только не несет смысловой нагрузки, но и является некорректным, если не сказать "оскорбительным".

Нечего сказать, проходи мимо, а не наезжай на то, что не видел. Я вот ничего не могу сказать и не говорю. Уважать надо коллег, как минимум.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Сергей Тепляков книжку написал!
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 26.05.15 14:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Хочу заметить уважаемому КО, что его сообщение не только не несет смысловой нагрузки,


Сообщение несет смысловую нагрузку так как: 1) выражает мнение участника форума о книгах по паттернам как таковых, 2) уточняет это мнение информацией о том, что не все книги по паттернам, виденные участником форума, УГ.

VD>но и является некорректным, если не сказать "оскорбительным".


Тут КО может сделать только что-то типа этого

VD>Нечего сказать, проходи мимо, а не наезжай на то, что не видел. Я вот ничего не могу сказать и не говорю. Уважать надо коллег, как минимум.


Влад, я боюсь что после "Политики", тебе наезды уже везде мерещится начали. Если у тебя есть желание что-то мне высказать, не стесняйся, пиши: alex@sysdev.me. Ни к чему устраивать публичные разборки.
Re[6]: Сергей Тепляков книжку написал!
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.05.15 14:28
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Сообщение несет смысловую нагрузку так как: 1) выражает мнение участника форума о книгах по паттернам как таковых, 2) уточняет это мнение информацией о том, что не все книги по паттернам, виденные участником форума, УГ.


Ну, можешь и дальше упираться сколько тебе угодно. Я тебе донес информацию о том, как твое сообщение выглядит со стороны.

KP>Тут КО может сделать только что-то типа этого


Оно и понятно. Хорошо ты хоть ненамеренно это делаешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Сергей Тепляков книжку написал!
От: HrorH  
Дата: 27.05.15 14:42
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, можешь и дальше упираться сколько тебе угодно. Я тебе донес информацию о том, как твое сообщение выглядит со стороны.


Я вот из этого поста узнал про POSA.
Но неужели кто-то читал весь пятитомник?
И насчет того, что манера изложения книг по паттернам не идеальна, это верно.
Re[3]: Глава 6. Паттерн «Посетитель»
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 27.05.15 17:27
Оценка:
Здравствуйте, Qbit86, Вы писали:

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


Q>Неплохая глава.


Спасибо

Q>1) В листинге 6.4 приводится т.н. «функциональная версия паттерна „Посетитель“» ака «самописное сопоставление с образцом». Ты пишешь: «Мы можем добавить несколько перегруженных методов `Match`, которые будут принимать не все возможные типы иерархии, а лишь некоторые наиболее часто используемые». Как ты относишься к варианту передачи словаря методов вместо нескольких фиксированных списков? Сопоставление тогда вырождается в динамический поиск в ручной explicit vtable вместо статически проверяемых «свитчей»-простыней. (Пример пишу без проверки компилятором, мог что-нибудь упустить.)


Q>void SaveLogEntry(LogEntry logEntry)

Q>{
Q> var vtable = new Dictionary<Type, Action<LogEntry>>
Q> {
Q> { typeof(ExceptionLogEntry), SaveException },
Q> { typeof(SimpleLogEntry), SaveSimpleLogEntry },
Q> }
Q> logEntry.Match(vtable);
Q>}
Q>[/cs]

Моя идея была в том, чтобы упростить жизнь поотребителя визитора, а не его разработчика. Предложенный вариант вполне работоспособный, но сигнатура метода Match теперь уже не говорит, какие типы корректны/валидны, а какие — нет. Я заморачивался с таким pattern-matching-ом для бедных, когда у меня есть простая и стабильная иерархия и десятки мест ее использования (вот реальный пример). Добваление словаря — обобщает решение, но перекладывает ответственность на клиента. А именно этого я и хотел избежать.

Я ОК использовать такой подход в реализации метода Match, но не на стороне клиента.

Q>2) В листинге 6.1 в методе SaveLogEntry() что-то не в порядке с веткой `else`. Должно быть

Q>
Q>if (simpleLogEntry != null)
Q>    SaveSimpleLogEntry(simpleLogEntry);
Q>else
Q>    throw new InvalidOperationException(...);
Q>

Q>А лучше сделать метод «плоским», добавив `return`ы вместо `else`.

Q>3) Комментарий названия паттерна от Скотта Мейерса в статье «My Most Important C++ Aha! Moments...Ever»: «Then, one day, I made a fundamental realization: the Visitor Pattern has nothing to do with visitation.»


Завел баги сюда: https://github.com/SergeyTeplyakov/DesignPatternsBookIssues/issues/3

Можно смело добавлять прямо в туда, но можно постить и здесь.
Re[4]: Глава 6. Паттерн «Посетитель». Non-void signature
От: Qbit86 Кипр
Дата: 27.05.15 19:23
Оценка:
Здравствуйте, SergeyT., Вы писали:

ST>Завел баги сюда: https://github.com/SergeyTeplyakov/DesignPatternsBookIssues/issues/3

ST>Можно смело добавлять прямо в туда, но можно постить и здесь.

Ок, если будут очевидные типографские огрехи, то можно и в issue tracker тихонько. Но какие-то более обсуждательные вещи уместнее публиковать на форуме. Цитата про «has nothing to do with visitation» к таким относилась, её не надо в issue tracker :)

Ещё хотелось бы пример с менее тривиальной сигнатурой, скажем, с возвращаемым результатом. Начну с твоего примера было/стало (немного искажу оригинальные названия классов/методов). Нам хочется на иерархию ILogEntry навесить полиморфный «метод» Save (псевдокод):
ILogEntry logEntry = GetConcreteLogEntry();
logEntry«.Save()»;


Здесь я ёлочками выделил вызов «внешнего полиморфного» метода (мы не можем внедрить новый собственный виртуальный метод в устойчивую иерархию). С паттерном Посетитель клиентский код перепишется так:
logEntry.Accept(new SaveVisitor());


Но что делать, если мы хотим навесить метод с нетривиальной сигнатурой? Как будут выглядеть классы конкретных посетителей в случае такого метода Foo(int, string): double
double d = logEntry«.Foo(1729, "Hello!")»;

?
Глаза у меня добрые, но рубашка — смирительная!
Re[5]: Глава 6. Паттерн «Посетитель», Expression problem
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 27.05.15 21:11
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Имхо, полезно явно упомянуть про связь паттерна с т.н. Expression problem:


Про Expression Problem говорится в главе про принцип Открыт-Закрыт. Там получилось небольшое дублирование с одной стороны, и размазанность информации — с другой. Большая часть философских рассуждений по поводу ООП vs. FP находится именно в главе про Открыт-Закрыт.
Re[5]: Глава 6. Паттерн «Посетитель». Non-void signature
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 27.05.15 21:15
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Ещё хотелось бы пример с менее тривиальной сигнатурой, скажем, с возвращаемым результатом. Начну с твоего примера было/стало (немного искажу оригинальные названия классов/методов). Нам хочется на иерархию ILogEntry навесить полиморфный «метод» Save (псевдокод):

Q>
Q>ILogEntry logEntry = GetConcreteLogEntry();
Q>logEntry«.Save()»;
Q>


Q>Здесь я ёлочками выделил вызов «внешнего полиморфного» метода (мы не можем внедрить новый собственный виртуальный метод в устойчивую иерархию). С паттерном Посетитель клиентский код перепишется так:

Q>
Q>logEntry.Accept(new SaveVisitor());
Q>


Q>Но что делать, если мы хотим навесить метод с нетривиальной сигнатурой? Как будут выглядеть классы конкретных посетителей в случае такого метода Foo(int, string): double

Q>
Q>double d = logEntry«.Foo(1729, "Hello!")»;
Q>

Q>?

Я, наверное, не включил подобный пример ради экономии места. В случае визитора с паттерн-матчингом это решается путем того, что варианты сопоставления представляют собой Func<T, TResult>, что позволяет делать именно то, что тебе нужно. А в ОО визиторе, я обычно делаю фасадный метод, который дергает визитор, который дергает за счет двойной диспетчирезации нужный метод, который уже, обновляет состояние, локальное для фасада. И потом уже это значение уходит вызывающей стороне. Как идея, можно расширить подобным примером.
Re[6]: Глава 6. Паттерн «Посетитель». Non-void signature
От: Qbit86 Кипр
Дата: 27.05.15 22:24
Оценка:
Здравствуйте, SergeyT., Вы писали:

Q>>Но что делать, если мы хотим навесить метод с нетривиальной сигнатурой? Как будут выглядеть классы конкретных посетителей в случае такого метода Foo(int, string): double

Q>>
Q>>double d = logEntry«.Foo(1729, "Hello!")»;
Q>>


ST>Я, наверное, не включил подобный пример ради экономии места. В случае визитора с паттерн-матчингом это решается путем того, что варианты сопоставления представляют собой Func<T, TResult>, что позволяет делать именно то, что тебе нужно. А в ОО визиторе, я обычно делаю фасадный метод, который дергает визитор, который дергает за счет двойной диспетчирезации нужный метод, который уже, обновляет состояние, локальное для фасада. И потом уже это значение уходит вызывающей стороне. Как идея, можно расширить подобным примером.


Я думал, предполагается вариант проще, где конкретный Visitor просто замыкает в себе входные и выходной параметр. Грубо говоря, код перепишется так:
ILogEntryVisitor foo = new FooVisitor(1729, "Hello!");
logEntry.Accept(foo);
double d = foo.Result;

Или ты это внутри фасада и имел в виду?
Глаза у меня добрые, но рубашка — смирительная!
Re[7]: Глава 6. Паттерн «Посетитель». Non-void signature
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 27.05.15 23:31
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Я думал, предполагается вариант проще, где конкретный Visitor просто замыкает в себе входные и выходной параметр. Грубо говоря, код перепишется так:

Q>
Q>ILogEntryVisitor foo = new FooVisitor(1729, "Hello!");
Q>logEntry.Accept(foo);
Q>double d = foo.Result;
Q>


Q>Или ты это внутри фасада и имел в виду?


Именно это. Просто спрятать за фасадом, чтобы сам факт наличия визитора скрыть с глаз долой.
Re: Сергей Тепляков книжку написал!
От: Venom  
Дата: 10.06.15 03:44
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Паттерны проектирования на платформе .NET


Жалею что сразу вместе с новостью на хабре не купил печатный вариант.
Теперь всё время нет в продаже.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.