Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Проблема не в "посетителе", она более глобальна. Посетитель — костыль. Есть и другие, некостыльные паттерны. Фабрика например. Вот покажи на примере фабрики что она затрудняет.
V>Фабрика усложнит использование переменной i V>int i; V>for(i=0; i<10; i++) V>{ V> cout << i; V>}
Не понял, а где тут фабрика?
V>а если серьезно, то надо думать прежде чем применять любой паттерн.
Вообще надо думать прежде чем что-то сделать. Все об этом знают, но не все думают.
V>Если мы будем отбрасывать все случаи где паттерн использован неверно и неправильно, то действительно останутся только сулчаи успешного применения паттерна, что дает недалеким людям утверждать что паттерн полезен во всех без исключения случаях.
То есть проблема таки не в паттернах и исходная посылка не верна?
G>>Логической цепочки вообще не понял, причем тут драйверы и обучение? Ты уводишь тему разговора. G>>Скажи какие недостатки от встроенной в язык множественной диспетчеризации. G>>Если двойная диспетчеризация не подходит для решения конкретной задачи, то это не проблема двойной диспетчеризации, не так ли? G>>Аналогично использование любого паттерна, не подходящего для задачи ничего не улучшит, но это ведь не проблема паттернов.
V>Там опечатка, я первый раз хотел сказать паттерны вместо драйверов а потом не смог откорректировать. V>ЕСли двойная деспетчеризация не подходит для решения конкретной задачи, то значит она не может восприниматься как принцип программирования. Это просто прием один из многих, которые используются от случая к случаю. А принцип должен давать положительный эффект везде и всегда. Он должен быть практически законом, указывающем то, как программист обязан мыслить. Именно так позиционируют себя паттерны. Если перед применением принципа надо 10 раз подумать, то это не принцип, а нюанс текущей реализации коими и являются паттерны. Просто абстракция выше класса и объекта состоящая из нескольких классов и\или объектов.
Ты путаешь паттерны с принципами. Перечитай мартина, GOF и фаулера. Особое внимание удели тем главам где написано о применимости.
Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Тут действительно нет мультиметодов G>>Покажи как выглядят мультиметоды чтоли.
V>Судя по википедии ты прав. V>здесь V>http://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B5%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0_%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B9<br />
<span class='lineQuote level1'>V></span> V>Мультиме́тод (англ. multimethod) или мно́жественная диспетчериза́ция (англ. multiple dispatch) — механизм, позволяющий выбрать одну из нескольких функций в зависимости от динамических типов или значений аргументов.
То есть мультиметоды есть?
V>В данном случае, естественно, следует отличать мультиметоды от статической перегрузки, так как, в отличие от последней, диспетчеризация происходит в рантайме. V>У визитора таки статическая перегрузка, так что визитор это не мультиметоды
Да, визитор — это костыль в отсутствии мультиметодов. Почитай внимательнее фрагмент кода, который я запостил. Так могли бы выглядеть мeльтиметоды в C#(N+1), сейчас аналогичное можно повторить через dynamic.
Здравствуйте, gandjustas, Вы писали:
V>>Фабрика усложнит использование переменной i V>>int i; V>>for(i=0; i<10; i++) V>>{ V>> cout << i; V>>} G>Не понял, а где тут фабрика?
Что не понятно? В таких случаях для выделения памяти под переменную "i" обычно фабрику не применяют, хотя теоретически это вполне возможно. По твоим словам раз фабрика полезна, значит и в таких случаях должна применятся.
V>>а если серьезно, то надо думать прежде чем применять любой паттерн. G>Вообще надо думать прежде чем что-то сделать. Все об этом знают, но не все думают.
Самое глупое оправдание из всех возможных. Это значит, что в падавляющем количестве случаев паттерны и принципы приносят вред, но есть случаи серъезного выигрыша производительности программиста от применения паттернов. Значит ситуация с паттернами не такая тривиальная как вы формулируете.
V>>Если мы будем отбрасывать все случаи где паттерн использован неверно и неправильно, то действительно останутся только сулчаи успешного применения паттерна, что дает недалеким людям утверждать что паттерн полезен во всех без исключения случаях. G>То есть проблема таки не в паттернах и исходная посылка не верна?
Есть желание рассуждать о паттернах не обращая внимания на контр-примеры, ну и рассуждайте. Никто вам это запретить не может.
G>Ты путаешь паттерны с принципами. Перечитай мартина, GOF и фаулера. Особое внимание удели тем главам где написано о применимости.
А ты набери опыт применения паттернов в серьезных проектах. Может тогда придет понимание, что применить паттерн можно разным образом и речь идет не о том применять или нет, а о том как именно. Потому желание обсуждать паттерны и принципы без относительно конкретных примеров есть метафизика или еще чего по хуже. Но вера в "абсолютную силу и пользу паттернов" есть необходимое промежуточное состояние для любого программиста
Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Фабрика усложнит использование переменной i V>>>int i; V>>>for(i=0; i<10; i++) V>>>{ V>>> cout << i; V>>>} G>>Не понял, а где тут фабрика? V>Что не понятно? В таких случаях для выделения памяти под переменную "i" обычно фабрику не применяют, хотя теоретически это вполне возможно. По твоим словам раз фабрика полезна, значит и в таких случаях должна применятся.
Ты передергиваешь. Любой паттерн нужен для решения конкретной задачи. Нету задачи — использование паттерна бессмысленно. Ты приводишь пример, в котром нету задачи, которая решается конкретным паттерном.
То что у тебя не такая задача — не проблема паттерна.
V>>>а если серьезно, то надо думать прежде чем применять любой паттерн. G>>Вообще надо думать прежде чем что-то сделать. Все об этом знают, но не все думают. V>Самое глупое оправдание из всех возможных. Это значит, что в падавляющем количестве случаев паттерны и принципы приносят вред, но есть случаи серъезного выигрыша производительности программиста от применения паттернов. Значит ситуация с паттернами не такая тривиальная как вы формулируете.
Ну приведи пример, где паттерн приносит вред. То есть есть походящая для паттерна задача и его применение реально что-то ухудшает. Только не визитор, у визитора проблема не в самом патетрне.
V>>>Если мы будем отбрасывать все случаи где паттерн использован неверно и неправильно, то действительно останутся только сулчаи успешного применения паттерна, что дает недалеким людям утверждать что паттерн полезен во всех без исключения случаях. G>>То есть проблема таки не в паттернах и исходная посылка не верна? V>Есть желание рассуждать о паттернах не обращая внимания на контр-примеры, ну и рассуждайте. Никто вам это запретить не может.
А ты не приводишь контр-примеры. То что ты приводишь не выполняет предусловия. Ботай матлогику.
G>>Ты путаешь паттерны с принципами. Перечитай мартина, GOF и фаулера. Особое внимание удели тем главам где написано о применимости. V>А ты набери опыт применения паттернов в серьезных проектах.
У меня-то как раз опыт есть, а у тебя видимо нет. Ты приводишь пример для фабрики, даже не понимая зачем фабрика нужна.
V>Может тогда придет понимание, что применить паттерн можно разным образом и речь идет не о том применять или нет, а о том как именно.
"Как именно применять паттерны" зависит от ситуации, а не от паттернов видимо.
V>Потому желание обсуждать паттерны и принципы без относительно конкретных примеров есть метафизика или еще чего по хуже.
Этим ты и занимаешься судя по куску кода выше.
V>Но вера в "абсолютную силу и пользу паттернов" есть необходимое промежуточное состояние для любого программиста
Ага, разочарвание в том что паттерны не сделали твой код идеальным — тоже. Ниче, продолжай изучать вопрос, тогда поймешь что сами по себе паттерны полезны, а бездумное из применение — вредно.
Здравствуйте, gandjustas, Вы писали:
I>>>>И где тут мультиметоды ? Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно
G>>>Визитор и есть костыль в отсутствии мультиметодов.
I>>Я просил показать решение на мултиметодах. Есть чего показать ? G>Я тебе и показал? Ты не видишь отличия мультиметодов от визитора? Попробуй тогда взять какой-нить готовый визитор и попытайся расширить структуру классов, которые обрабатывает визитор.
Я тебя попросил показать __мултиметоды__.
Не можешь, не хочешь — так и пиши — не могу, не хочу и тд. Не надо галиматью всякую писать.
G>Естественно, в соответствии с OCP ты не имеешь доступа к исходному коду существующих классов.
G>Потом тоже самое с мультиметодами.
Здравствуйте, gandjustas, Вы писали:
V>>Тут действительно нет мультиметодов G>Покажи как выглядят мультиметоды чтоли.
Очень смешно. Ты сам начал рассказывать сказки про мултиметоды, а на предложение показать эти мультиметоды у тебянашелся "достойный" ответ : "Покажи как выглядят мультиметоды чтоли."
Здравствуйте, gandjustas, Вы писали:
V>>Мультиме́тод (англ. multimethod) или мно́жественная диспетчериза́ция (англ. multiple dispatch) — механизм, позволяющий выбрать одну из нескольких функций в зависимости от динамических типов или значений аргументов. G>То есть мультиметоды есть?
V>>В данном случае, естественно, следует отличать мультиметоды от статической перегрузки, так как, в отличие от последней, диспетчеризация происходит в рантайме. V>>У визитора таки статическая перегрузка, так что визитор это не мультиметоды
G>Да, визитор — это костыль в отсутствии мультиметодов. Почитай внимательнее фрагмент кода, который я запостил. Так могли бы выглядеть мeльтиметоды в C#(N+1), сейчас аналогичное можно повторить через dynamic.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>>>И где тут мультиметоды ? Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно
G>>>>Визитор и есть костыль в отсутствии мультиметодов.
I>>>Я просил показать решение на мултиметодах. Есть чего показать ? G>>Я тебе и показал? Ты не видишь отличия мультиметодов от визитора? Попробуй тогда взять какой-нить готовый визитор и попытайся расширить структуру классов, которые обрабатывает визитор.
I>Я тебя попросил показать __мултиметоды__.
I>Не можешь, не хочешь — так и пиши — не могу, не хочу и тд. Не надо галиматью всякую писать.
Ты вообще понимаешь что такое мультиметоды? Читай внимательнее что я тебе написал.
G>>Естественно, в соответствии с OCP ты не имеешь доступа к исходному коду существующих классов. G>>Потом тоже самое с мультиметодами. I>Покажи сначала эти мультиметоды.
Ты походу вообще не читаешь что тебе пишут. Перечитай внимательно мои посты, а до этого загляни в википедию чтобы узнать что такое мультиметоды.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
V>>>Тут действительно нет мультиметодов G>>Покажи как выглядят мультиметоды чтоли.
I>Очень смешно. Ты сам начал рассказывать сказки про мултиметоды, а на предложение показать эти мультиметоды у тебянашелся "достойный" ответ : "Покажи как выглядят мультиметоды чтоли."
I>
Читай дальше, чувак ошибся. Он, также как и ты, только слышал о мультиметодах, но не представляет что это.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
V>>>Мультиме́тод (англ. multimethod) или мно́жественная диспетчериза́ция (англ. multiple dispatch) — механизм, позволяющий выбрать одну из нескольких функций в зависимости от динамических типов или значений аргументов. G>>То есть мультиметоды есть?
V>>>В данном случае, естественно, следует отличать мультиметоды от статической перегрузки, так как, в отличие от последней, диспетчеризация происходит в рантайме. V>>>У визитора таки статическая перегрузка, так что визитор это не мультиметоды
G>>Да, визитор — это костыль в отсутствии мультиметодов. Почитай внимательнее фрагмент кода, который я запостил. Так могли бы выглядеть мeльтиметоды в C#(N+1), сейчас аналогичное можно повторить через dynamic.
I>Так костыль или мультиметоды ?
Мультиметоды — средство решения expression problem в ООП. визитор — костыль в отсутствии мультиметодов. Что ее непонятно? Я тебе уже третий раз кажись это пишу. Когда до тебя дойдет?
Здравствуйте, gandjustas, Вы писали:
I>>Так костыль или мультиметоды ?
G>Мультиметоды — средство решения expression problem в ООП. визитор — костыль в отсутствии мультиметодов. Что ее непонятно? Я тебе уже третий раз кажись это пишу. Когда до тебя дойдет?
Еще раз — покажи пример с __мулиметодами__ которые ____мультиметоды_ а не костыли. Так понятно ?
Здравствуйте, gandjustas, Вы писали:
I>>Не можешь, не хочешь — так и пиши — не могу, не хочу и тд. Не надо галиматью всякую писать.
G>Ты вообще понимаешь что такое мультиметоды? Читай внимательнее что я тебе написал.
Я пока что понимаю, что ты не в состоянии ответить на простой вопрос.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Так костыль или мультиметоды ?
G>>Мультиметоды — средство решения expression problem в ООП. визитор — костыль в отсутствии мультиметодов. Что ее непонятно? Я тебе уже третий раз кажись это пишу. Когда до тебя дойдет?
I>Еще раз — покажи пример с __мулиметодами__ которые ____мультиметоды_ а не костыли. Так понятно ?
Еще раз:
abstract class A {}
class B:A {}
class C:A {}
public abstract class BaseVisitor
{
public abstract void Visit(A obj);
}
public class Visitor:BaseVisitor
{
public override void Visit(B obj) {} //Это мультиметод, диспетчеризация по неявному аргументу this и первому параметруpublic override void Visit(C obj) {} //Это мультиметод, диспетчеризация по неявному аргументу this и первому параметру
}
И я без проблем могу добавить как классы, наследники A. Так и новые визиторы, мультиметоды помогают отвязать одно от другого.
Понятно?
Здравствуйте, gandjustas, Вы писали:
G>Читай дальше, чувак ошибся. Он, также как и ты, только слышал о мультиметодах, но не представляет что это.
Ты это так понял да? Ну твое дело, тока у тебя таки точно мультиметодов не было, а разговоры как бы они выглядели если бы в С# реализовывались — это для детского садика оставь. По определению мультиметод это второе название двойной диспетчеризации и именно ты все запутал. У тебя банальный визитор со статической диспетчеризацией, что не есть мультиметод по определению.
Здравствуйте, gandjustas, Вы писали:
I>>Еще раз — покажи пример с __мулиметодами__ которые ____мультиметоды_ а не костыли. Так понятно ? G>Еще раз:
G>
G>abstract class A {}
G>class B:A {}
G>class C:A {}
G>public abstract class BaseVisitor
G>{
G> public abstract void Visit(A obj);
G>}
G>public class Visitor:BaseVisitor
G>{
G> public override void Visit(B obj) {} //Это мультиметод, диспетчеризация по неявному аргументу this и первому параметру
G> public override void Visit(C obj) {} //Это мультиметод, диспетчеризация по неявному аргументу this и первому параметру
G>}
G>
G>И я без проблем могу добавить как классы, наследники A. Так и новые визиторы, мультиметоды помогают отвязать одно от другого. G>Понятно?
Т.е. костыли резко перстали быть костылями ? Правильно тебя понял ?
Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Читай дальше, чувак ошибся. Он, также как и ты, только слышал о мультиметодах, но не представляет что это.
V>Ты это так понял да?
Да, ты ошибся.
V>Ну твое дело, тока у тебя таки точно мультиметодов не было, а разговоры как бы они выглядели если бы в С# реализовывались — это для детского садика оставь.
Как-то не считаю целесообразным для предмета разговора втыкать код на эзотерических языках. При желании ты и сам можешь перевести три строчки на нужный тебе язык.
V>По определению мультиметод это второе название двойной диспетчеризации и именно ты все запутал.
Мультиметоды — это множественная дисипетчерезация, встроенная в язык. Когда втроенной в язык возможности нет можно писать typetest руками, но это слишком ненадежно или реализовывать паттерн визитор, но это не решает expression problem.
В C#4 можно воспользоваться dynamic, он typetest автоматизирует.
V>У тебя банальный визитор со статической диспетчеризацией, что не есть мультиметод по определению.
То есть ты код даже смотрел судя по всему.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Еще раз — покажи пример с __мулиметодами__ которые ____мультиметоды_ а не костыли. Так понятно ? G>>Еще раз:
G>>
G>>abstract class A {}
G>>class B:A {}
G>>class C:A {}
G>>public abstract class BaseVisitor
G>>{
G>> public abstract void Visit(A obj);
G>>}
G>>public class Visitor:BaseVisitor
G>>{
G>> public override void Visit(B obj) {} //Это мультиметод, диспетчеризация по неявному аргументу this и первому параметру
G>> public override void Visit(C obj) {} //Это мультиметод, диспетчеризация по неявному аргументу this и первому параметру
G>>}
G>>
G>>И я без проблем могу добавить как классы, наследники A. Так и новые визиторы, мультиметоды помогают отвязать одно от другого. G>>Понятно?
I>Т.е. костыли резко перстали быть костылями ? Правильно тебя понял ?
Такое ощущение что у тебя какие-то голоса в голове которые тебе подсказывают непонятно что.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Еще раз — покажи пример с __мулиметодами__ которые ____мультиметоды_ а не костыли. Так понятно ? G>>Еще раз:
G>>
G>>abstract class A {}
G>>class B:A {}
G>>class C:A {}
G>>public abstract class BaseVisitor
G>>{
G>> public abstract void Visit(A obj);
G>>}
G>>public class Visitor:BaseVisitor
G>>{
G>> public override void Visit(B obj) {} //Это мультиметод, диспетчеризация по неявному аргументу this и первому параметру
G>> public override void Visit(C obj) {} //Это мультиметод, диспетчеризация по неявному аргументу this и первому параметру
G>>}
G>>
G>>И я без проблем могу добавить как классы, наследники A. Так и новые визиторы, мультиметоды помогают отвязать одно от другого. G>>Понятно?
I>Т.е. костыли резко перстали быть костылями ? Правильно тебя понял ?
Ты не прав в отношении gandjustas!!!!!
По его словам Патерны всегда рулят, это те кто формулируют задачу по применению паттернов глючат. Щас задача была сформулирована буз костылей потому и пример что реньше не катил щас прокатил. Понимаешь, это ведь формальная логика блин. Если задача решается неправильно — измени условие задачи, ну и одновременно назови своих критиков лапухами. gandjustas вот даже слова знает заморские или не умеет их на русский перевсти. Лучше с ним не спорить он всегда прав, даже когда неправ. Он из тех рыцарей что вскакивают на коня и готовы скакать сразу во всех направлениях. Сформулируют ему задачу применить фабрику — он применит, сформулируют визитора — применит визитора. Главное чтобы задачу ктото другой сформулировал, чтобы было кого обвинить в непрофессионализме.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Vaako, Вы писали:
V>>Здравствуйте, gandjustas, Вы писали:
G>>>Читай дальше, чувак ошибся. Он, также как и ты, только слышал о мультиметодах, но не представляет что это.
V>>Ты это так понял да? G>Да, ты ошибся.
V>>Ну твое дело, тока у тебя таки точно мультиметодов не было, а разговоры как бы они выглядели если бы в С# реализовывались — это для детского садика оставь. G>Как-то не считаю целесообразным для предмета разговора втыкать код на эзотерических языках. При желании ты и сам можешь перевести три строчки на нужный тебе язык.
V>>По определению мультиметод это второе название двойной диспетчеризации и именно ты все запутал. G>Мультиметоды — это множественная дисипетчерезация, встроенная в язык. Когда втроенной в язык возможности нет можно писать typetest руками, но это слишком ненадежно или реализовывать паттерн визитор, но это не решает expression problem. G>В C#4 можно воспользоваться dynamic, он typetest автоматизирует.
V>>У тебя банальный визитор со статической диспетчеризацией, что не есть мультиметод по определению. G>То есть ты код даже смотрел судя по всему.
Неа, я мысли напрямую читал подключившись к всемирному разуму
Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно 
