Здравствуйте, gandjustas, Вы писали:
I>>>>Еще раз — покажи пример с __мулиметодами__ которые ____мультиметоды_ а не костыли. Так понятно ?
I>>Т.е. костыли резко перстали быть костылями ? Правильно тебя понял ? G>Такое ощущение что у тебя какие-то голоса в голове которые тебе подсказывают непонятно что.
Смотри внимательно
Твои слова: "визитор — костыль в отсутствии мультиметодов."
Мои "покажи пример с __мулиметодами__ которые ____мультиметоды_ а не костыли"
Здравствуйте, Vaako, Вы писали:
I>>Т.е. костыли резко перстали быть костылями ? Правильно тебя понял ?
V>Ты не прав в отношении gandjustas!!!!! V>По его словам Патерны всегда рулят, это те кто формулируют задачу по применению паттернов глючат. Щас задача была сформулирована буз костылей потому и пример что реньше не катил щас прокатил. Понимаешь, это ведь формальная логика блин. Если задача решается неправильно — измени условие задачи, ну и одновременно назови своих критиков лапухами. gandjustas вот даже слова знает заморские или не умеет их на русский перевсти. Лучше с ним не спорить он всегда прав, даже когда неправ. Он из тех рыцарей что вскакивают на коня и готовы скакать сразу во всех направлениях. Сформулируют ему задачу применить фабрику — он применит, сформулируют визитора — применит визитора. Главное чтобы задачу ктото другой сформулировал, чтобы было кого обвинить в непрофессионализме.
Ну что ты, у него ведь столько сертификатов !!!!!!!
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Vaako, Вы писали:
I>>>Т.е. костыли резко перстали быть костылями ? Правильно тебя понял ?
V>>Ты не прав в отношении gandjustas!!!!! V>>По его словам Патерны всегда рулят, это те кто формулируют задачу по применению паттернов глючат. Щас задача была сформулирована буз костылей потому и пример что реньше не катил щас прокатил. Понимаешь, это ведь формальная логика блин. Если задача решается неправильно — измени условие задачи, ну и одновременно назови своих критиков лапухами. gandjustas вот даже слова знает заморские или не умеет их на русский перевсти. Лучше с ним не спорить он всегда прав, даже когда неправ. Он из тех рыцарей что вскакивают на коня и готовы скакать сразу во всех направлениях. Сформулируют ему задачу применить фабрику — он применит, сформулируют визитора — применит визитора. Главное чтобы задачу ктото другой сформулировал, чтобы было кого обвинить в непрофессионализме.
I> Ну что ты, у него ведь столько сертификатов !!!!!!!
Ой блин, с кем я связался. Но это очень хорошая черта выставлять всё лучшее и умалчивать трудные моменты. И пусть кто-то возразит! Паттерны рулят везде оулят, особенно у программистов от Microsoft !!! Там вообще рулез полный.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>>>Еще раз — покажи пример с __мулиметодами__ которые ____мультиметоды_ а не костыли. Так понятно ?
I>>>Т.е. костыли резко перстали быть костылями ? Правильно тебя понял ? G>>Такое ощущение что у тебя какие-то голоса в голове которые тебе подсказывают непонятно что.
I>Смотри внимательно
I>Твои слова: "визитор — костыль в отсутствии мультиметодов."
I>Мои "покажи пример с __мулиметодами__ которые ____мультиметоды_ а не костыли"
I>И у кого из нас голоса в голове ?
Ну конечно не у меня. Я посмотрел переписку с тобой. У тебя понимание паттерна визитор сильно отличается от того что в GOF написано. Ты в одной из тем приводил свой "визитор" который вообще не требует двойной диспетчеризации. То есть ни разу не визитор вообще.
Здравствуйте, gandjustas, Вы писали:
I>>Твои слова: "визитор — костыль в отсутствии мультиметодов."
I>>Мои "покажи пример с __мулиметодами__ которые ____мультиметоды_ а не костыли"
I>>И у кого из нас голоса в голове ?
G>Ну конечно не у меня. Я посмотрел переписку с тобой. У тебя понимание паттерна визитор сильно отличается от того что в GOF написано. Ты в одной из тем приводил свой "визитор" который вообще не требует двойной диспетчеризации. То есть ни разу не визитор вообще.
Вообще говоря визиторы мерещились именно тебе и именно ты оспаривал двойную диспетчеризацию. Смори
Про обход графа на лямбдах — то был просто dfs в котором именно ты углядел visitor
Смотри "I>а визитор это вроде обфускации, что бы gandjustasа проверить."
А теперь про двойную диспетчеризацию в той же теме — выделеное это мои слова
I>Чушь. Открываешь любую книгу и читаешь — операции над объектной структурой. Общий корень может быть а может и не быть. А вот двойная диспетчеризация будет обязательно.
Давай пойдем от обратного. Представим что нет ничего общего между различными типам A, B и надо выполнить обход структуры, которую они представляют.
Для общности представим что каждый из типов A и B имеет ссылки на объекты типов A и B.
Далее как будет выглядеть обход. Так как нет общего предка, то будет две точки входа: функции VisitA и VisitB. При обходе каждая из них будет вызывать isitA и VisitB при необходимости.
Ну вот и нету двойной диспетчеризации, даже одинарной нет. Если конечно воспользоваться статическим полиморфизмом, то вполне можно сделать статическую одинарную диспетчеризацию, но это совершенно необязательно.
Кстати для визитора в определении GOF двойная диспетчеризация — не цель, а средство. Цель — отвязать операции со структурой от самой структуры, чтобы операции можно было менять произвольно.
Как видишь это именно я говорил про двойную диспетчеризацию и именно ты это оспаривал
Вобщем, судя по всему, база баззводров у тебя иссякла
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Твои слова: "визитор — костыль в отсутствии мультиметодов."
I>>>Мои "покажи пример с __мулиметодами__ которые ____мультиметоды_ а не костыли"
I>>>И у кого из нас голоса в голове ?
G>>Ну конечно не у меня. Я посмотрел переписку с тобой. У тебя понимание паттерна визитор сильно отличается от того что в GOF написано. Ты в одной из тем приводил свой "визитор" который вообще не требует двойной диспетчеризации. То есть ни разу не визитор вообще.
I>Вообще говоря визиторы мерещились именно тебе и именно ты оспаривал двойную диспетчеризацию. Смори
I>Про обход графа на лямбдах — то был просто dfs в котором именно ты углядел visitor
I>Смотри "I>а визитор это вроде обфускации, что бы gandjustasа проверить."
Только не было там визитора. Это снова голоса в твоей голове.
I>А теперь про двойную диспетчеризацию в той же теме — выделеное это мои слова I>Как видишь это именно я говорил про двойную диспетчеризацию и именно ты это оспаривал
Да, и двойной диспетчеризации там не было.Ты же понимаешь что когда говорят о множественной диспетчеризации, то имеют ввиду её в раннтайме. В компайл-тайме не интересует. Но голоса в голове тебе мешают это понять. С другой стороны когда тебе приводят пример множественной диспетчеризации ты видишь что угодно, только не её.
I>Вобщем, судя по всему, база баззводров у тебя иссякла
Судя по всему ты все равно не понимаешь ничего.
Здравствуйте, gandjustas, Вы писали:
I>>Вообще говоря визиторы мерещились именно тебе и именно ты оспаривал двойную диспетчеризацию. Смори
I>>Про обход графа на лямбдах — то был просто dfs в котором именно ты углядел visitor
I>>Смотри "I>а визитор это вроде обфускации, что бы gandjustasа проверить." G>Только не было там визитора. Это снова голоса в твоей голове.
В том то и дело что не было, о чем я и пишу "то был просто dfs в котором именно ты углядел visitor"
I>>А теперь про двойную диспетчеризацию в той же теме — выделеное это мои слова I>>Как видишь это именно я говорил про двойную диспетчеризацию и именно ты это оспаривал G>Да, и двойной диспетчеризации там не было.Ты же понимаешь что когда говорят о множественной диспетчеризации, то имеют ввиду её в раннтайме. В компайл-тайме не интересует.
Ты хорошо понимаешь, что означает фраза "А вот двойная диспетчеризация будет обязательно." ? Мы все еще про визитор ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Вообще говоря визиторы мерещились именно тебе и именно ты оспаривал двойную диспетчеризацию. Смори
I>>>Про обход графа на лямбдах — то был просто dfs в котором именно ты углядел visitor
I>>>Смотри "I>а визитор это вроде обфускации, что бы gandjustasа проверить." G>>Только не было там визитора. Это снова голоса в твоей голове.
I>В том то и дело что не было, о чем я и пишу "то был просто dfs в котором именно ты углядел visitor"
Это еще до твоего dfs было. Тут
G>>>>>Чтобы получить надежность кода на уровне статического варианта тебе нужно написать для этого дела тест.
I>>>>Зато в с#, C++ придется городить всякие визиторы.
G>>>И часто тебе приходится их городить? Я визиторы писал пару раз в жизни всего. Еще несколько раз пользовался готовыми.
I>>мне вот обходы всякие приходится писать чуть не постоянно
G>Обходы и визиторы — не одно и то же
Визитор в итоге ты так и не показал и тебе несколько человек пытались объяснить что такое визитор. Но ты прислушиваешься исключительно к голосам в своей голове.
I>>>А теперь про двойную диспетчеризацию в той же теме — выделеное это мои слова I>>>Как видишь это именно я говорил про двойную диспетчеризацию и именно ты это оспаривал G>>Да, и двойной диспетчеризации там не было.Ты же понимаешь что когда говорят о множественной диспетчеризации, то имеют ввиду её в раннтайме. В компайл-тайме не интересует. I>Ты хорошо понимаешь, что означает фраза "А вот двойная диспетчеризация будет обязательно." ? Мы все еще про визитор ?
Открываешь любую книгу и читаешь — операции над объектной структурой. Общий корень может быть а может и не быть. А вот двойная диспетчеризация будет обязательно.
Здравствуйте, gandjustas, Вы писали:
I>>В том то и дело что не было, о чем я и пишу "то был просто dfs в котором именно ты углядел visitor" G>Это еще до твоего dfs было. Тут
G>>>>>>Чтобы получить надежность кода на уровне статического варианта тебе нужно написать для этого дела тест.
I>>>>>Зато в с#, C++ придется городить всякие визиторы.
G>>>>И часто тебе приходится их городить? Я визиторы писал пару раз в жизни всего. Еще несколько раз пользовался готовыми.
I>>>мне вот обходы всякие приходится писать чуть не постоянно
G>>Обходы и визиторы — не одно и то же
G>Визитор в итоге ты так и не показал и тебе несколько человек пытались объяснить что такое визитор. Но ты прислушиваешься исключительно к голосам в своей голове.
Изначально речь шла про статику и динамику, а обходы и визиторы только как пример.
И часто тебе приходится их городить? Я визиторы писал пару раз в жизни всего. Еще несколько раз пользовался готовыми.
Если уж касаться темы обхода сложных структур, то я лучше F# (статически типизированный однако) возьму, там pattern-matching есть.
Собтсвенно после этого я тебе и сказал что обходы нужны постоянно.
G>Вот тут
G>Открываешь любую книгу и читаешь — операции над объектной структурой. Общий корень может быть а может и не быть. А вот двойная диспетчеризация будет обязательно.
Здравствуйте, Ikemefula, Вы писали:
I>Изначально речь шла про статику и динамику, а обходы и визиторы только как пример.
Я же тебе привожу часть диалога. Ты пытаешься выкручиваться.
G>>Открываешь любую книгу и читаешь — операции над объектной структурой. Общий корень может быть а может и не быть. А вот двойная диспетчеризация будет обязательно.
. Но твои голоса в голове все продолжают твердить непонятно что.
I>Ты сам свой ответ перечитай — ты родил визитор без двойной диспетчеризации
Значит ты не понимаешь сути паттерна визитор. Иди читай книжки, потом возвращайся.
Здравствуйте, gandjustas, Вы писали:
I>>Ты сам свой ответ перечитай — ты родил визитор без двойной диспетчеризации G>Значит ты не понимаешь сути паттерна визитор. Иди читай книжки, потом возвращайся.
Читаем местного деятеля:
"Ты в одной из тем приводил свой "визитор" который вообще не требует двойной диспетчеризации. То есть ни разу не визитор вообще."
Этот же деятель родил визитор без двойной диспетчеризации.
Этот же деятель выдал "Значит ты не понимаешь сути паттерна визитор. Иди читай книжки, потом возвращайся."
Y>Настоящая проблема мне видится в том, что даже прочитав несколько книжек, скорее всего "понять" эти принципы не получится. Y>Действительно их "понять" получится только столкнувшись с проблемами, которые они решают. Т.е. нужен собственный опыт.
+1. Можно объяснять, но ни в коем случае не через заумные теоретические размышления о пользе принципов, а через практические примеры проблем от их неиспользования.
От фразы в курилке
"эти ***сы вставили отсылку нотификаций прямо в dao на сохранении, так мне им теперь до следующего билда заглушку mail-клиента подкладывать приходится"
до понимания SRP всего полшага.
Re: Объясните принцип SOLID
От:
Аноним
Дата:
12.04.11 17:29
Оценка:
Мне все принципы понятны, кроме SRP. На первый взгляд, этот принцип вообще противоречит ООП, так как предлагает выделять классы, отталкиваясь от обязанностей, в то время как определяющей идеей ООП, как я понимаю, является выделение классов в зависимости от данных. Выделение структурных единиц в зависимости от обязанностей — это вроде как функциональный или процедурный дизайн.
Да и вообще, "обязанность" класса зависит от того, как ее сформулировать. То есть такая формулировка этого принцип уводит нас полностью в интуитивную гуманитарную область.
Например, класс Integer (целое число, в абстрактном языке программирования), классы Float, Double, String, File, Database, MicrosoftWordApplication и т.д. Какая-такая у каждого из этих классов единственная обязанность? Да у него их могут быть тысячи, и вроде это никак не противоречит ООП.
Можно, конечно, сказать, что единственная обязанность класса Integer — хранить целое число, String — хранить строку, но это неправда, так как они предоставляют потенциально огромное количество операций, и как раз главной идеей ООП и является то, что мы эти операции ассоциируем с данным объектом, то есть мы группируем в объекте все операции, связанные общими данными.
Здравствуйте, Аноним, Вы писали:
А>Мне все принципы понятны, кроме SRP. На первый взгляд, этот принцип вообще противоречит ООП, так как предлагает выделять классы, отталкиваясь от обязанностей, в то время как определяющей идеей ООП, как я понимаю, является выделение классов в зависимости от данных.
Вообще-то в ООп никогда таких идей не было. Эти идеи были придуманы сильно позже Бучами и Мейерами и названы OOAD.
А>Выделение структурных единиц в зависимости от обязанностей — это вроде как функциональный или процедурный дизайн.
Функциональный дизайн не противоречит ОО-техникам написания кода.
А>Да и вообще, "обязанность" класса зависит от того, как ее сформулировать. То есть такая формулировка этого принцип уводит нас полностью в интуитивную гуманитарную область.
Не верно. Всегда есть "истина" в виде решаемой проблемы.
А>Например, класс Integer (целое число, в абстрактном языке программирования), классы Float, Double, String, File, Database, MicrosoftWordApplication и т.д. Какая-такая у каждого из этих классов единственная обязанность? Да у него их могут быть тысячи, и вроде это никак не противоречит ООП.
См выше. Понимать обязанности (ответственности, reason to change) классов без понимания решаемых задач — нельзя.
А>Можно, конечно, сказать, что единственная обязанность класса Integer — хранить целое число, String — хранить строку, но это неправда, так как они предоставляют потенциально огромное количество операций, и как раз главной идеей ООП и является то, что мы эти операции ассоциируем с данным объектом, то есть мы группируем в объекте все операции, связанные общими данными.
Как раз Integer и String очень хороший пример. У них нет вообще ни одного reason to change, то есть они идеальны с точки зрения SRP.
А>Разве не так?
Не так.
А>Мне все принципы понятны, кроме SRP. На первый взгляд, этот принцип вообще противоречит ООП, так как предлагает выделять классы, отталкиваясь от обязанностей, в то время как определяющей идеей ООП, как я понимаю, является выделение классов в зависимости от данных. Выделение структурных единиц в зависимости от обязанностей — это вроде как функциональный или процедурный дизайн.
Нет. Хотя, глядя на то, что пишет большинство, становиться понятно, что класс — это "данные + методы их обработки" ООП — оно совсем про другое.
Re[3]: Объясните принцип SOLID
От:
Аноним
Дата:
15.04.11 17:24
Оценка:
Здравствуйте, -VaS-, Вы писали:
VS>Нет. Хотя, глядя на то, что пишет большинство, становиться понятно, что класс — это "данные + методы их обработки" ООП — оно совсем про другое.
Ну сформулируй, пожалуйста, о чем оно, если не трудно. Только не надо, пожалуйста, отсылок вроде "читай книги по ООП, там все написано". Книги я обязательно прочитаю, но раз ты это понимаешь, ты же можешь это сформулировать, так? Я же сформулировал четко и конкретно свое неправильное понимание, а ты, если не трудно, сформулируй правильное. Спасибо.
Re[3]: Объясните принцип SOLID
От:
Аноним
Дата:
15.04.11 17:35
Оценка:
Здравствуйте, gandjustas, Вы писали:
А>>Мне все принципы понятны, кроме SRP. На первый взгляд, этот принцип вообще противоречит ООП, так как предлагает выделять классы, отталкиваясь от обязанностей, в то время как определяющей идеей ООП, как я понимаю, является выделение классов в зависимости от данных. G>Вообще-то в ООп никогда таких идей не было. Эти идеи были придуманы сильно позже Бучами и Мейерами и названы OOAD.
А какие были идеи?
А>>Выделение структурных единиц в зависимости от обязанностей — это вроде как функциональный или процедурный дизайн. G>Функциональный дизайн не противоречит ОО-техникам написания кода.
Ну я говорил конкретно про то, по какому принципу выделять классы в архитектуре.
А>>Да и вообще, "обязанность" класса зависит от того, как ее сформулировать. То есть такая формулировка этого принцип уводит нас полностью в интуитивную гуманитарную область. G>Не верно. Всегда есть "истина" в виде решаемой проблемы.
Приводить примеры у меня получается плохо, ну не знаю, скажем класс String:
1) "у класса String одна обязанность — он хранит строку";
2) "у класса String множество не связанных между собой обязанностей — хранение строк, копирование строк, сравнение строк, в том числе с учетом локализации (еще и эта функциональность сюда затесалась), поиск подстрок, еще и регулярные выражения туда можно присобачить и т.д. И поводов поменять его у меня тысячи. Значит нарушен SRP?".
Не знаю, может пример не очень хороший, но примерно это я имел в виду: в зависимости от формулировки у нас SRP либо нарушается, либо нет.
А>>Можно, конечно, сказать, что единственная обязанность класса Integer — хранить целое число, String — хранить строку, но это неправда, так как они предоставляют потенциально огромное количество операций, и как раз главной идеей ООП и является то, что мы эти операции ассоциируем с данным объектом, то есть мы группируем в объекте все операции, связанные общими данными. G>Как раз Integer и String очень хороший пример. У них нет вообще ни одного reason to change, то есть они идеальны с точки зрения SRP.
Долго напрягал мозг, но так и не понял, что такое "причина для изменения", и как ее определить формально. Про String я привел пример выше, так что я не понимаю, почему это у String нет причин для изменения.
Здравствуйте, Аноним, Вы писали:
А>2) "у класса String множество не связанных между собой обязанностей — хранение строк, копирование строк, сравнение строк, в том числе с учетом локализации (еще и эта функциональность сюда затесалась), поиск подстрок, еще и регулярные выражения туда можно присобачить и т.д. И поводов поменять его у меня тысячи. Значит нарушен SRP?".
У строки нет обязанности хранить строки. Строка хранит в себе данные (символы) из которых она состоит, если она не пуста. Копирование, сравнение строк, поиск подстрок — совершенно логичные операции для строки, как для владельца данных (символов) с которыми фактически происходят манипуляции, потому что строка в данном случае является информационным экспертом для выполнения этих операций.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
А>1) "у класса String одна обязанность — он хранит строку";
А>2) "у класса String множество не связанных между собой обязанностей — хранение строк, копирование строк, сравнение строк, в том числе с учетом локализации (еще и эта функциональность сюда затесалась), поиск подстрок, еще и регулярные выражения туда можно присобачить и т.д. И поводов поменять его у меня тысячи. Значит нарушен SRP?".
Оба примера — плохи.
Обязанность "хранить" для строки нехарактерна.
Есть обязанности по манипуляции строкой. В разных реализациях строковых библиотек у строки могут быть разные обязанности. К примеру, можно ограничиться возможностью итерировать символы, из которых состоит строка — IEnumerable<char>. Это позволяет заменять реализацию на основе, скажем, char[] на, скажем, rope.
В других реализациях у строки может быть обязанность возвращать символ в произвольной позиции.
Ортогонально к этому — возможности по модификации строки in-place. Возможности по взятию подстроки, конкатенации строк, и т.п.
Операции типа поиска подстрок, очевидно, перегружают строку. Для поиска достаточно иметь IEnumerable<char>. Сравнение строк — вообще кошмарно сложная вещь. Уж очень невнятно для строк определены понятия эквивалентности и порядка.
Лучше держать такие вещи в отдельных внешних классах. SRP в полный рост.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Аноним, Вы писали:
А>Ну сформулируй, пожалуйста, о чем оно, если не трудно. Только не надо, пожалуйста, отсылок вроде "читай книги по ООП, там все написано". Книги я обязательно прочитаю, но раз ты это понимаешь, ты же можешь это сформулировать, так? Я же сформулировал четко и конкретно свое неправильное понимание, а ты, если не трудно, сформулируй правильное. Спасибо.
Определяющей идеей ООП являются понятия идентифицируемости объектов, наличия у них поведения, и состояния для обеспечения изменчивости поведения.
Поведение здесь первично. Оно напрямую связано с обязанностями. Это максимально далеко от идеи "приклеить к данным удобные для них методы".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Ну что ты, у него ведь столько сертификатов !!!!!!!
