General policy и бритва Оккама

[singalen]

Обсуждаю статью voidbent-а (он же Вова Фролов) "General policy pattern".
Она относится к class metaprogramming, на основе C++.
Идея в том, чтобы в некоей библиотеке сложить все классы compile-time policy в один и какие выгоды это даёт.
Спор в комментах.

Comments

[singalen]

Я пытался читать. Не понял, в чём главная идея: в том, что полиси задаётся параметрами шаблона? Так этот приём уже давно используется: есть traits, есть allocators.

[singalen]

главная идея в том что-бы все полиси и трейтсы передавать одним параметром темплейта во все сущности которые в обобщённой библиотеке есть.
--
void

[singalen]

Это применимо, только если всем классам нужны все полиси сразу. Если кому-то нужен только allocator, а другому только traits, то general policy становится лишней сущностью.

[singalen]

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

[anonymous]

Кстати а причём тут бритва Оккама? :)

C General Policy можно провести очень чёткую анологию из жизни.

У Александреску Loki напоминает государство в котором есть куча всевозможных книг. В книгах написанны разные законы. Все книги лежат в разных местах. Каждый человек знает только те законы "которые нужны только ему". Законы постоянно меняються и все давным-давно в них запутались.

General Policy выглядит как конституция в которой написаны и структурированны все законы.

---
void

[anonymous]

General Policy выглядит как конституция в которой написаны и структурированны все законы.

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

---
void

[singalen]

Бритва Оккама всегда причём.

[anonymous]

Бритва Оккама всегда причём.

Как ты там говорил. "компонент, "который будет всё делать"?" :)

[moxhatblu]

ГП в основном расчитана на то что вся система или хотя-бы не меньше чем компонент используют одну ГП
Это как раз и есть большой недостаток ГП.

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

Если система так построена, что в одном месте она работает с char а в другом c wchar, в одном с дефалтовыми аллокаторами, а в другом со специальными, то даже без ГП у тебя возникнет проблема что всем этим "местам" будет очень трудно друг с другом взаимодействовать
Дело в том, что в большой системе неизбежно возникает куча мест с отклонениями от "генеральной линии партии", то бишь от всесистемного ГП. То в одном месте нужно вместо Юникода пропихивать обычные char для совместимости со сторонней либой. То появляется какой-то класс, для которого выделять память стандартным образом чересчур неэффективно. То <сам придумай

[moxhatblu]

ЖЖ не дал ответить на пост в трэде :-( Вова, это ответ на твой пост http://singalen.livejournal.com/69702.html?thread=330054#t330054

[voidbent]

Мы смотрим на ГП с разных точек зрения. По-моему ГП предполагает что отклонения от "Генеральной линни партии" происходят НУ ОЧЕ-Е-Е-Е-НЬ редко. И когда они всё таки происходят, то таки да - надо писать ещё один класс ГП. Ты смотришь на ГП с той точки срения, что отклонения от ГП происходят НУ ОЧЕ-Е-Е-Е-ЕНЬ часто и нам этих ГП нужно по 50 на каждый класс. Как я уже говорил для твоего случая целесообразнее использовать полиморфизм времени выполнения, а не времени компиляции. Т.е. строить не полиси иерархию классов например

[voidbent]

Кстати о динамике.
Насколько ценным был бы ГП паттерн если бы кто-то заимплеменил type factory, о котором я говорил, и ГП стал-бы ещё одним велосипедом с квадратными колёсами, предназначенным решать проблемы связанные с динамикой?

[moxhatblu]

1. Написание библиотеки - не самоцель. Она ж пишется, чтобы её использовать :-)

2. Механизм замены dll'ек - довольно точная аналогия использования библиотеки, у которой единственная возможность настройки полиси - через ГП.

3. В случае с ГП, вся система будет вынуждена использовать этот самый super-puper-mega-wide.

[voidbent]

1. Угу. И ГП позволяет использовать такую библиотеку в широком спектре программ, потому что решения не хардкодятся а выносяться в отдельные полиси.
Кстати ГП придумывался не сам по себе а в контексте создания TR2. Я хотел показать что старыми методами (полиси) будет очень трудно создать библиотеку такого масштаба.

2. Не понял.

3. Нет. В случае с ГП вся система может использовать что угодно. super-puper-mega-wide будет использовать вся наша библиотека. Кстати вся система у себя тоже этот аспект может не хардкодить через ГП.

[moxhatblu]

1. Может быть. Хотя, вообще я пока не очень уверен в такой уж жуткой полезности ГП.

2. Что именно непонятно? Спрашивай, объясню.

3. В случае с ГП вся система может использовать что угодно.
Ну расскажи мне, каким образом. Есть у нас STL, и мы пользуем ГП, в котором сказано "использовать для строк wide char". И вот в один прекрасный момент нам понадобился тип символа "только цифра". Написали мы этот класс, написали трейты к нему и хотим теперь создать строку из наших замечательных символов. А система нам "фиг вам, я STL'ные строки умею создавать только из wide char. У меня ГП такая". И как с этим быть?

[voidbent]

1. Может быть. Хотя, вообще я пока не очень уверен в такой уж жуткой полезности ГП.
Возможно это потому что ты никогда не писал библиотек которые понимают 4 и больше полиси?

2. Механизм замены dll'ек - довольно точная аналогия использования библиотеки, у которой единственная возможность настройки полиси - через ГП.

2. Что именно непонятно? Спрашивай, объясню.

Ничего не понятно. ГП с dll'ками не умеет работать я это сто раз говорил.