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

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

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

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

Завел багу/задачу здесь. Сделаю.

Здравствуйте, 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!")»;

?

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

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

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

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

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

Всё, что делает паттерн Посетитель, это выворачивает наизнанку иерархию вариантов, и создаёт параллельную иерархию «команд». В ней исходным полиморфным операциям соответствуют один к одному классы посетителей. А исходным классам вариантов соответствуют один к одному полиморфные методы Visit(). Т.о. транспонируя исходную иерархию, мы переходим от сложной ситуации 2) к решаемой задаче 1).

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

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

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

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

Здравствуйте, 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;

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

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

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

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

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

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

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

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

Именно это. Просто спрятать за фасадом, чтобы сам факт наличия визитора скрыть с глаз долой.

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

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

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

Виноват-с Просто раз уж речь зашла за Expression Problem, то не смог оставить этот момент без внимания. Буду аккуратнее в следующий раз

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

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

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

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

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

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

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

Мда... А мне издатель написал, что допечатывать летом, скорее всего не будут, поскольку идет сезонный спад и они боятся простоев (пролежев?) книги на складах. Так что есть все шансы джать аж до осени, если не получится найти где-то в локальных или тырнет-магазинах сейчас.

LVV>>Паттерны проектирования на платформе .NET
V>Жалею что сразу вместе с новостью на хабре не купил печатный вариант.
V>Теперь всё время нет в продаже.
На Озоне можно сделать оповещение о появлении книжки в продаже.
Если много таких требований будет, то могут сделать допечатку.

Вон книжка Вирта по алгоритмам несколько раз допечатывалась.
И Рефакторинг — регулярно.