G>О том что эти принципы были придуманы хзкогда, а до сих пор внятного объяснения найти трудно, а чтобы понять пять буковок нужно прочитать минимум несколько заумных книжек.
Настоящая проблема мне видится в том, что даже прочитав несколько книжек, скорее всего "понять" эти принципы не получится.
Действительно их "понять" получится только столкнувшись с проблемами, которые они решают. Т.е. нужен собственный опыт.
После 15 лет использования ООП прихожу к тому же выводу: парадигма ООП — полная бредятина, не имеющая ничего общего с реальностью. Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое.
Здравствуйте, Аноним, Вы писали:
А>1. Принцип единственности ответственности На каждый объект должна быть возложена одна единственная ответственность.
А>Что значит ответственность ? Допустим есть объект Box — у него несколько методов Scale() , Move() получается он отвечает уже за 2 действия. Или три свойства Width, Top, Height — отвечает за 3 параметра. А также Width, Top, Heigth могут быть не просто Integer, а объектами типа SizeMeasure, получается что Box будет отвечать за состояние 3х объектов.
Ответственность можно понимать как назначение объекта. Т.е., если объект класса Box отвечает за положение ящика в пространстве, то отвечать за отрисовку этого ящика на экране или сохранение состояния в файл он уже не должен. Как уже сказали, одна ответственность = одна причина изменения класса. При таком подходе изменяя у класса Box логику расположение в пространстве мы не можем повредить логику сохранения, так как она будет в отдельном классе.
На практике такое разделение помогает чётче понять предметную область, способствует более качественному анализу. В процессе разработке одна ответственность может разделиться на несколько — это нормальное явление, главное при этом соответствующим образом разделить класс.
А>2.Принцип открытости/закрытости Программные сущности … должны быть открыты для расширения, но закрыты для изменения.
А>Не понятно, как можно открыть сущность для изменения ? Допустим есть класс с методами, изменить его можно только изменив исходный текст, перекрытие методов возможно но уже в другом классе, а текущий никак не изменить, кроме редактирования исходного кода.
Возьмём тот же класс Box, допустим его ответственность — расположение ящика в пространстве. Класс имеет ограниченное число методов для изменения положения — Scale и Move. Рано или поздно, возможно в другом проекте, нам потребуется средство для поворота ящика.
Согласно принципу OCP мы должны ещё на этапе проектирования класса Box добавить в него метод Transform(), которые принимает, например, матрицу трансформации координат, т.е. позволяет осуществить любое преобразование. Если этого не сделать, то для реализации поворота ящика нам нужно править исходный код класса Box, что не есть хорошо.
Вообще говоря, суть принципа в том, чтобы предвидеть направления расширения ответственности класса и в данных направлениях реализовывать класс так, чтобы расширение не требовало изменения исходного кода. Естественно, всё предвидеть невозможно, и в один прекрасный момент в код класса всё-таки придётся вмешиваться. Принцип позволяет уменьшить вероятность такого вмешательства.
А>3. Принцип подстановки Лисков Объекты в программе могут быть заменены их наследниками без изменения свойств программы. А>И к чему это интересно ? Зачем заменять объект наследником, не изменяя поведение наследника, а другое поведение наследника — это разве не новое/улучшенное/ухудщеное свойство программы. Если нет, то зачем создавать наследника который не меняет свойств программы.
Тут уже написали про предусловия постусловия.
Суть в том, что тот код, который работает с базовым классом, рассчитывает на некоторое поведение, если производный класс будет нарушать это поведение, то ничего хорошего не получится.
Например, в базовом классе Box сеттер свойства Width изменяет ширину и только ширину. А в производном классе Cube, мы решили, что в сторона куба будет задаваться только свойством Height, а сеттер Width ничего изменять не будет. Это и есть нарушение LSP. Аналогично будет, если при изменении свойства Width будет изменяться ещё и Height.
А>4. А>Принцип изоляции интерфейса Много специализированных интерфейсов лучше, чем один универсальный.
А>Тоже странно, получается по этому правилу нужно делать на каждую сущность свой интерфейс, т.к. допустим есть команда ICommand, у нее 2 метода Execute и CanExecute, интерфейс достаточно универсальный, подходит для всех команд, но каждая команда имеет свои особенности, и получается согласно этому правилу на них нужно плодить специализированные интерфейсы. И в чем будет практическое удобство от этого ?
Можно сказать, что ISP — это принцип единственности ответственности для интерфейсов. Каждый интерфейс должен описывать один аспект поведения, выделенный на основе какой-либо надобности. Т.е., интерфейсы мы должны проектировать не "от класса", а от способов использования класса; на каждое использование мы делаем отдельный интерфейс, даже не смотря на то, что все эти интерфейсы будут реализованы в одном классе.
Например, пусть выполнение некоторых команд можно прерывать. ISP запрещает нам добавлять в ICommand метод Cancel, а вместо этого предлагает создать интерфейс ICancelable. Тот код, который отвечает за прерывание выполнения команды по нажатию Esc, будет хранить ссылку не на ICommand, а на ICancelable.
А> А>5.Принцип инверсии зависимостей Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. А>
А>А это как понимать , получается например слой над драйверами не должен от них зависеть, а как извините обращаться к драйверу не завися от его интерфейса.
По DI в сети достаточно много информации.
Пусть верхний стой — программа, нижний слой — драйвер. Программа взаимодействует с драйвером, получает от него информацию. Драйвер ничего не знает о программе его использующей.
Принцип зависимости на основе абстракций предлагает нам выделить интерфейс IDriver (или базовый класс DriverBase) и построить слой программы так, чтобы он зависел от этого интерфейса (т.е. от абстракции), а не от самого драйвера (реализации). Тогда изменения в коде драйвера не потребуют перекомпиляции программы. При этом, сам интерфейс IDriver (или базовый класс) не должен находиться в том же модуле (сборке, файле), что и драйвер. Он может находиться в отдельном модуле или в модуле с программой.
На мой взгляд на практике главное не переусердствовать с выделением абстракций. Абстракции хороши на межмодульном (межуровневом, межслойном и т.п.) уровне, внутри отдельно взятого самостоятельного модуля тотальное выделение абстракций только мешает.
Здравствуйте, 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" обычно фабрику не применяют, хотя теоретически это вполне возможно. По твоим словам раз фабрика полезна, значит и в таких случаях должна применятся. G>>Ты передергиваешь. Любой паттерн нужен для решения конкретной задачи. Нету задачи — использование паттерна бессмысленно. Ты приводишь пример, в котром нету задачи, которая решается конкретным паттерном. G>>То что у тебя не такая задача — не проблема паттерна. V>Если проблемы применения паттерна не связывать с паттерном, то с чем тогда свзязывать? С кривыми руками программиста?
Именно
V>Сформируй объективно причины почему в моей примере применять паттерн фабрика для переменной i неразумно, может тогда начнешь с логикой дружить.
Я дружу с логикой, а у тебя с этим проблемы. Ты написал код, вот ты и обосновывай.
V>Может даже до тебя дойдет, что четкой границы нет ни не может быть, так чтоб вот в этой сложной ситуации нужно применять фабрику, а для всех более простых ситуаций фабрику применять нельзя. Всё программирование состоит из компромиссов, у всякого проектного решения есть свои + и -. А если читать только книжки то действительно, нет недостатков у паттернов. Продолжай читать книжки.
Я уже прочитал нужные книги. Решения знаешь почему так называются? Потому что они решают определенную задачу. Если нет задачи, то типовое решение применять незачем.
G>>Ну приведи пример, где паттерн приносит вред. То есть есть походящая для паттерна задача и его применение реально что-то ухудшает. Только не визитор, у визитора проблема не в самом патетрне. V>Ага, у тебя "подходящая" уже неявно предполагает что ничего плохого нету
Именно, см выше про "решение".
V>Пример с фабрикой для переменной i тебя не удовлетворил? Ты не знаешь как туда прикрутить фабрику? Надеюсь это для тебя посильно в принципе иначе просто нет смысла продолжать. Рассматривая паттерны мы не имеем права игнорировать визитор.
Начни с простого, опиши задачу, которая в твоем примере решается фабрикой.
V>Твоя трактовка проблем визитора меня просто шокирует.
Это не моя трактовка. Expression problem существует объективно, паттерн visitor существует именно из-за нее. То что ты находишь недостатки в визиторе говорит лишь о том что в некоторых языках expression problem не решается.
G>>У меня-то как раз опыт есть, а у тебя видимо нет. Ты приводишь пример для фабрики, даже не понимая зачем фабрика нужна. V>Так всё таки есть у паттернов цели, преимущества и недостатки?
Еще раз: паттерны решают задачи. Нету задачи — паттерн лепить бессмысленно.
V>В приведенном мной примере паттерн фабрика может быть применен. Точка. Никаких других точек зрения не рассматривается.
Ты не повторяй утверждение, ты его обоснуй. Приведи задачу, которая решается фабрикой в твоем примере.
Здравствуйте, iZEN, Вы писали:
ZEN>После 15 лет использования ООП прихожу к тому же выводу: парадигма ООП — полная бредятина, не имеющая ничего общего с реальностью. Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое.
Поддерживаю, у мартин Р. Чистый код... хорошое пояснение по поводу одного из аспектов. Я так понимаю что любой паттерн проектирования улучшая что-то другое ухудшает и нет никаких принципов,
следовать которым нужно любой ценой. Думаю тут дело даже не в компромисах, а в полном отсутствии однозначного решения любой проблемной ситуации. Неопределенность или даже принцип неопределенностей лучше подходит.
Антисимметрия да иных/объектов
Два предыдущих примера показывают, чем объекты отличаются от структур
данных. Объекты скрывают свои данные за абстракциями и предоставляют функции,
работающие с этими данными. Структуры данных раскрывают свои данные и не
имеют осмысленных функций. А теперь еще раз перечитайте эти определения.
Обратите внимание на то, как они дополняют друг друга, фактически являясь
противоположностями. Различия могут показаться тривиальными, но они
приводят к далеко идущим последствиям.
...(пример)...
(1) У проблемы существуют обходные решения, хорошо известные опытным объектно-
ориентированным программистам: например, паттерн ПОСЕТИТЕЛЬ или двойная
диспетчеризация. Но у этих приемов имеются собственные издержки, к тому же они обычно
возвращают структуру к состоянию процедурной программы.
И снова мы наблюдаем взаимодополняющую природу этих двух определений.
В этом проявляется основополагающая дихотомия между объектами и
структурами данных.
Процедурный код (код, использующий структуры данных) позволяет легко
добавлять новые функции без изменения существующих структур данных. Объектно —
ориентированный код, напротив, упрощает добавление новых классов без
изменения существующих функций.
Обратные утверждения также истинны.
Процедурный код усложняет добавление новых структур данных, потому что оно
требует изменения всех функций. Объектно-ориентированный код усложняет
добавление новых функций, потому что для этого должны измениться все классы.
Таким образом, то, что сложно в ОО, просто в процедурном программировании,
а то, что сложно в процедурном программировании, просто в ОО!
В любой сложной системе возникают ситуации, когда вместо новых функций
в систему требуется включить новые типы данных. Для таких ситуаций объекты
и объектно-ориентированное программирование особенно уместны. Впрочем,
бывает и обратное — вместо новых типов данных требуется добавить новые
функции. Тогда лучше подходит процедурный код и структуры данных.
Опытные программисты хорошо знают: представление о том, что все данные
должны представляться в виде объектов — миф. Иногда предпочтительны
простые структуры данных и процедуры, работающие с ними.
Здравствуйте, gandjustas, Вы писали:
G>О том что эти принципы были придуманы хзкогда, а до сих пор внятного объяснения найти трудно, а чтобы понять пять буковок нужно прочитать минимум несколько заумных книжек.
Мне объяснения у Мартина нравятся. Несколько заумных книжек тоже не надо. Можно просто у Мартина прочитать эти главы (они совсем небольшие) + для полноты посмотреть определения в других источниках.
Очень советую прочитать книгу Роберта Мартина (Robert Martin) — Agile Principles, Patterns, and Practices in C#. Там достаточно хорошо объясняются эти принципы.
А>1. Принцип единственности ответственности На каждый объект должна быть возложена одна единственная ответственность.
А>Что значит ответственность ? Допустим есть объект Box — у него несколько методов Scale() , Move() получается он отвечает уже за 2 действия. Или три свойства Width, Top, Height — отвечает за 3 параметра. А также Width, Top, Heigth могут быть не просто Integer, а объектами типа SizeMeasure, получается что Box будет отвечать за состояние 3х объектов.
Нет. "Отвественность" кто-то из мэтров определил как потенциальную причину изменять объект. На твоем примере это показать невозможно ибо ты не определил назначение твоего объекта Box.
А>3. Принцип подстановки Лисков Объекты в программе могут быть заменены их наследниками без изменения свойств программы. А>И к чему это интересно ? Зачем заменять объект наследником, не изменяя поведение наследника, а другое поведение наследника — это разве не новое/улучшенное/ухудщеное свойство программы. Если нет, то зачем создавать наследника который не меняет свойств программы.
Слово "свойств" неточное. Формально принцип звучит так:
Если тип B является подтипом A, то все предусловия B должны быть должны быть не сильнее предусловий A, а постусловия для B должны быть не слабее постусловий A.
В ООП отношение тип-подтип создается наследованием. Таким образом, выполняя LSP, можно в любом месте программы где требуется объект типа A подставить объект типа B и программа будет работать как и раньше.
А>2.Принцип открытости/закрытости Программные сущности … должны быть открыты для расширения, но закрыты для изменения.
Фактически означает что надо базовые классы строить так чтобы наследники не могли нарушить LSP.
А>4. А>Принцип изоляции интерфейса Много специализированных интерфейсов лучше, чем один универсальный.
А>Тоже странно, получается по этому правилу нужно делать на каждую сущность свой интерфейс, т.к. допустим есть команда ICommand, у нее 2 метода Execute и CanExecute, интерфейс достаточно универсальный, подходит для всех команд, но каждая команда имеет свои особенности, и получается согласно этому правилу на них нужно плодить специализированные интерфейсы. И в чем будет практическое удобство от этого ?
Если ты не отдаешь наружу методов и не принимаешь команды, отличные от ICommand, то никаких интерфейсов тебе плодить не надо.
Собственно принцип и говорит что если ты отдаешь\принимаешь интерфейс, то лучше много маленьких и специализированных, чем один большой и универсальный.
А> А>5.Принцип инверсии зависимостей Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. А> А>А это как понимать , получается например слой над драйверами не должен от них зависеть, а как извините обращаться к драйверу не завися от его интерфейса.
Откровенно хреновая формулировка. Подробнее про IoC можешь прочитать тут.
Здравствуйте, gandjustas, Вы писали:
G>Проблема не в "посетителе", она более глобальна. Посетитель — костыль. Есть и другие, некостыльные паттерны. Фабрика например. Вот покажи на примере фабрики что она затрудняет.
Фабрика усложнит использование переменной i
int i;
for(i=0; i<10; i++)
{
cout << i;
}
а если серьезно, то надо думать прежде чем применять любой паттерн. Если мы будем отбрасывать все случаи где паттерн использован неверно и неправильно, то действительно останутся только сулчаи успешного применения паттерна, что дает недалеким людям утверждать что паттерн полезен во всех без исключения случаях.
V>>Как-то у вас все просто, прямо захотелось пожить в вашем идеальном мире. G>Что простого ты увидел? Всегда надо принимать решения, только надо понимать факторы, на основании которых ты принимаешь решения. G>Твоя заявление что "все паттерны имеют недостатки" таким пониманием не пахнет.
Ну в принципе да, только для этого нужно понимать как программист мыслит. Паттерны не применяются сами по себе, потому сужать вопрос до определения паттерна — явная ошибка. Это все равно что рассуждать о пользе оператора ++.
G>Логической цепочки вообще не понял, причем тут драйверы и обучение? Ты уводишь тему разговора. G>Скажи какие недостатки от встроенной в язык множественной диспетчеризации. G>Если двойная диспетчеризация не подходит для решения конкретной задачи, то это не проблема двойной диспетчеризации, не так ли? G>Аналогично использование любого паттерна, не подходящего для задачи ничего не улучшит, но это ведь не проблема паттернов.
Там опечатка, я первый раз хотел сказать паттерны вместо драйверов а потом не смог откорректировать.
ЕСли двойная деспетчеризация не подходит для решения конкретной задачи, то значит она не может восприниматься как принцип программирования. Это просто прием один из многих, которые используются от случая к случаю. А принцип должен давать положительный эффект везде и всегда. Он должен быть практически законом, указывающем то, как программист обязан мыслить. Именно так позиционируют себя паттерны. Если перед применением принципа надо 10 раз подумать, то это не принцип, а нюанс текущей реализации коими и являются паттерны. Просто абстракция выше класса и объекта состоящая из нескольких классов и\или объектов.
Здравствуйте, 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, Вы писали:
V>>Тут действительно нет мультиметодов G>Покажи как выглядят мультиметоды чтоли.
Очень смешно. Ты сам начал рассказывать сказки про мултиметоды, а на предложение показать эти мультиметоды у тебянашелся "достойный" ответ : "Покажи как выглядят мультиметоды чтоли."
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>>>И где тут мультиметоды ? Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно
G>>>>Визитор и есть костыль в отсутствии мультиметодов.
I>>>Я просил показать решение на мултиметодах. Есть чего показать ? G>>Я тебе и показал? Ты не видишь отличия мультиметодов от визитора? Попробуй тогда взять какой-нить готовый визитор и попытайся расширить структуру классов, которые обрабатывает визитор.
I>Я тебя попросил показать __мултиметоды__.
I>Не можешь, не хочешь — так и пиши — не могу, не хочу и тд. Не надо галиматью всякую писать.
Ты вообще понимаешь что такое мультиметоды? Читай внимательнее что я тебе написал.
G>>Естественно, в соответствии с OCP ты не имеешь доступа к исходному коду существующих классов. G>>Потом тоже самое с мультиметодами. I>Покажи сначала эти мультиметоды.
Ты походу вообще не читаешь что тебе пишут. Перечитай внимательно мои посты, а до этого загляни в википедию чтобы узнать что такое мультиметоды.
Здравствуйте, gandjustas, Вы писали:
G>Читай дальше, чувак ошибся. Он, также как и ты, только слышал о мультиметодах, но не представляет что это.
Ты это так понял да? Ну твое дело, тока у тебя таки точно мультиметодов не было, а разговоры как бы они выглядели если бы в С# реализовывались — это для детского садика оставь. По определению мультиметод это второе название двойной диспетчеризации и именно ты все запутал. У тебя банальный визитор со статической диспетчеризацией, что не есть мультиметод по определению.
Здравствуйте, 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 вот даже слова знает заморские или не умеет их на русский перевсти. Лучше с ним не спорить он всегда прав, даже когда неправ. Он из тех рыцарей что вскакивают на коня и готовы скакать сразу во всех направлениях. Сформулируют ему задачу применить фабрику — он применит, сформулируют визитора — применит визитора. Главное чтобы задачу ктото другой сформулировал, чтобы было кого обвинить в непрофессионализме.
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. На первый взгляд, этот принцип вообще противоречит ООП, так как предлагает выделять классы, отталкиваясь от обязанностей, в то время как определяющей идеей ООП, как я понимаю, является выделение классов в зависимости от данных. Выделение структурных единиц в зависимости от обязанностей — это вроде как функциональный или процедурный дизайн.
Нет. Хотя, глядя на то, что пишет большинство, становиться понятно, что класс — это "данные + методы их обработки" ООП — оно совсем про другое.
Но почти ни одна формулировка из 5ти не понятны. А именно :
1. Принцип единственности ответственности На каждый объект должна быть возложена одна единственная ответственность.
Что значит ответственность ? Допустим есть объект Box — у него несколько методов Scale() , Move() получается он отвечает уже за 2 действия. Или три свойства Width, Top, Height — отвечает за 3 параметра. А также Width, Top, Heigth могут быть не просто Integer, а объектами типа SizeMeasure, получается что Box будет отвечать за состояние 3х объектов.
2.Принцип открытости/закрытости Программные сущности … должны быть открыты для расширения, но закрыты для изменения.
Не понятно, как можно открыть сущность для изменения ? Допустим есть класс с методами, изменить его можно только изменив исходный текст, перекрытие методов возможно но уже в другом классе, а текущий никак не изменить, кроме редактирования исходного кода.
3. Принцип подстановки Лисков Объекты в программе могут быть заменены их наследниками без изменения свойств программы.
И к чему это интересно ? Зачем заменять объект наследником, не изменяя поведение наследника, а другое поведение наследника — это разве не новое/улучшенное/ухудщеное свойство программы. Если нет, то зачем создавать наследника который не меняет свойств программы.
4.
Принцип изоляции интерфейса Много специализированных интерфейсов лучше, чем один универсальный.
Тоже странно, получается по этому правилу нужно делать на каждую сущность свой интерфейс, т.к. допустим есть команда ICommand, у нее 2 метода Execute и CanExecute, интерфейс достаточно универсальный, подходит для всех команд, но каждая команда имеет свои особенности, и получается согласно этому правилу на них нужно плодить специализированные интерфейсы. И в чем будет практическое удобство от этого ?
5.Принцип инверсии зависимостей Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
А это как понимать , получается например слой над драйверами не должен от них зависеть, а как извините обращаться к драйверу не завися от его интерфейса.
А потом — фраза " Зависимости внутри системы строятся на основе абстракций." и "Абстракции не должны зависеть от деталей." т.е. получаем что в абстракциях не должно быть деталей, и тут вспоминаем п.4. где нам рекомендуют создавать специализированные интерфейсы , которые являются абстракцией, а их специализация означает включение деталей и конкретики.
Здравствуйте, MozgC, Вы писали:
MC>Очень советую прочитать книгу Роберта Мартина (Robert Martin) — Agile Principles, Patterns, and Practices in C#. Там достаточно хорошо объясняются эти принципы.
«Если вы ученый, квантовый физик, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан»
Интересно, а когданить у программистов такое получится?
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, gandjustas, Вы писали:
G>>
G>>«Если вы ученый, квантовый физик, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан»
G>>Интересно, а когданить у программистов такое получится?
MC>Это ты сейчас о чем?
О том что эти принципы были придуманы хзкогда, а до сих пор внятного объяснения найти трудно, а чтобы понять пять буковок нужно прочитать минимум несколько заумных книжек.
ZEN>Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое.
Склонен считать, что программа (делающая то же самое) вне стиля ООП будет еще более запутана.
Т.е. это свойство не подхода к решению проблемы, а самой проблемы.
Здравствуйте, ylem, Вы писали:
ZEN>>Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое.
Y>Склонен считать, что программа (делающая то же самое) вне стиля ООП будет еще более запутана. Y>Т.е. это свойство не подхода к решению проблемы, а самой проблемы.
Каждой парадигме своя область применения. Для гуйни все мапится на ооп хорошо, для процессионговых серверов все лучше мапится на всякие функциональные дкомпозиции и иже с ними.. Надо быть гибким
Re[2]: Объясните принцип SOLID
От:
Аноним
Дата:
30.03.11 16:00
Оценка:
Здравствуйте, Poul_Ko, Вы писали:
P_K>Здравствуйте, Аноним, Вы писали:
А>>1. Принцип единственности ответственности На каждый объект должна быть возложена одна единственная ответственность.
А>>Что значит ответственность ? Допустим есть объект Box — у него несколько методов Scale() , Move() получается он отвечает уже за 2 действия. Или три свойства Width, Top, Height — отвечает за 3 параметра. А также Width, Top, Heigth могут быть не просто Integer, а объектами типа SizeMeasure, получается что Box будет отвечать за состояние 3х объектов.
P_K>Ответственность можно понимать как назначение объекта. Т.е., если объект класса Box отвечает за положение ящика в пространстве, то отвечать за отрисовку этого ящика на экране или сохранение состояния в файл он уже не должен. Как уже сказали, одна ответственность = одна причина изменения класса. При таком подходе изменяя у класса Box логику расположение в пространстве мы не можем повредить логику сохранения, так как она будет в отдельном классе. P_K>На практике такое разделение помогает чётче понять предметную область, способствует более качественному анализу. В процессе разработке одна ответственность может разделиться на несколько — это нормальное явление, главное при этом соответствующим образом разделить класс.
Вроде как понятно, но не совсем. Допустим у ящика появился контейнер Items который хранит объекты внутри него. В понятие геометрии это не вписывается,
где грань между новой и старой ответственностью ?
Здравствуйте, Аноним, Вы писали:
А>Вроде как понятно, но не совсем. Допустим у ящика появился контейнер Items который хранит объекты внутри него. В понятие геометрии это не вписывается, А>где грань между новой и старой ответственностью ?
Суть в том, чтобы сделать методы Add/Remove у Items, а не AddItem/RemoveItem у Box.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Poul_Ko, Вы писали:
P_K>>Здравствуйте, Аноним, Вы писали:
А>>>1. Принцип единственности ответственности На каждый объект должна быть возложена одна единственная ответственность.
А>>>Что значит ответственность ? Допустим есть объект Box — у него несколько методов Scale() , Move() получается он отвечает уже за 2 действия. Или три свойства Width, Top, Height — отвечает за 3 параметра. А также Width, Top, Heigth могут быть не просто Integer, а объектами типа SizeMeasure, получается что Box будет отвечать за состояние 3х объектов.
P_K>>Ответственность можно понимать как назначение объекта. Т.е., если объект класса Box отвечает за положение ящика в пространстве, то отвечать за отрисовку этого ящика на экране или сохранение состояния в файл он уже не должен. Как уже сказали, одна ответственность = одна причина изменения класса. При таком подходе изменяя у класса Box логику расположение в пространстве мы не можем повредить логику сохранения, так как она будет в отдельном классе. P_K>>На практике такое разделение помогает чётче понять предметную область, способствует более качественному анализу. В процессе разработке одна ответственность может разделиться на несколько — это нормальное явление, главное при этом соответствующим образом разделить класс.
А>Вроде как понятно, но не совсем. Допустим у ящика появился контейнер Items который хранит объекты внутри него. В понятие геометрии это не вписывается, А>где грань между новой и старой ответственностью ?
Ты опиши зачем применяется Box. Не бывает "хорошего дизайна" в отрыве от решаемых задач.
Здравствуйте, Аноним, Вы писали:
А>Вроде как понятно, но не совсем. Допустим у ящика появился контейнер Items который хранит объекты внутри него. В понятие геометрии это не вписывается, где грань между новой и старой ответственностью ?
В принципе, уже всё сказали.
Хорошие решения (c точки зрения SRP):
1. Для хранения и манипулирования коллекцией Items создать класс BoxItems (или использовать стандартную коллекцию, если этого достаточно). Добавить свойство Items типа BoxItems в класс Box. В данном случае можно сказать, что хранение ссылки на коллекцию не является значительной ответственностью и внесением её в класс Box можно пренебречь, однако если таких дополнительных ответственностей станет много, то желательно перейти ко второму варианту.
2. Старый класс Box переименовать в BoxGeometry, для хранения и манипулирования коллекцией Items создать класс BoxItems, создать новый класс Box, который хранит ссылку на BoxGeometry и BoxItems. Ответственность нового класса Box — создание и инициализация объектов BoxGeometry и BoxItems. Это самый "идеологически чистый" вариант.
3. Для хранения и манипулирования коллекцией Items создать класс BoxItems, в нём создать неизменяемое поле Box — ссылку на объект Box, коллекцию элементов которого хранит объект BoxItems. Здесь ссылка на Box является своего рода идентификатором и не добавляет никакой ответственности в класс BoxItems.
Плохое с точки зрения SRP решение:
Добавить в класс Box свойство Items и методы для манипулирования коллекцией (AddItem, RemoveItem, FindItem, ...). Управление коллекцией — это отдельная ответственность.
Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, iZEN, Вы писали:
ZEN>>После 15 лет использования ООП прихожу к тому же выводу: парадигма ООП — полная бредятина, не имеющая ничего общего с реальностью. Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое.
V>Я так понимаю что любой паттерн проектирования улучшая что-то другое ухудшает и нет никаких принципов, следовать которым нужно любой ценой.
Неверно понимаешь. Подавляющее большинство "паатернов" ничего не ухудшают, они дают рецепт для решения типовой задачи. В современных языках многие такие паттерны включены в сам язык. Например observer — event_ы в .NET и Delphi, аналогично итераторы.
V>Думаю тут дело даже не в компромисах, а в полном отсутствии однозначного решения любой проблемной ситуации.
Неверно. Это в конкретном языке могут отсутствовать средства адекватно выразить задачу, тогда возникает проблема как её эффективно решить в конкретном случае.
Большинство современных языков имею так называемую Expression Problem. Суть её заключается в невозможности одновременно расширять структуры данных а операции над ними. Ни один ООП язык этого не позволяет.
Здравствуйте, gandjustas, Вы писали:
ZEN>>>После 15 лет использования ООП прихожу к тому же выводу: парадигма ООП — полная бредятина, не имеющая ничего общего с реальностью. Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое. V>>Я так понимаю что любой паттерн проектирования улучшая что-то другое ухудшает и нет никаких принципов, следовать которым нужно любой ценой. G>Неверно понимаешь. Подавляющее большинство "паатернов" ничего не ухудшают, они дают рецепт для решения типовой задачи. В современных языках многие такие паттерны включены в сам язык. Например observer — event_ы в .NET и Delphi, аналогично итераторы.
То что есть паттерны "почти ничего не ухудшающие" не означает, что все паттерны ничего не ухудшают. Возьми паттерн посетитель, например. Нельзя сказать что он ничего не ухудшает. Все паттерны хоть немного но ухудшают понимание программы. При этом применения одних паттернов накладывает ограничение на последующее применение других паттернов.
V>>Думаю тут дело даже не в компромисах, а в полном отсутствии однозначного решения любой проблемной ситуации. G>Неверно. Это в конкретном языке могут отсутствовать средства адекватно выразить задачу, тогда возникает проблема как её эффективно решить в конкретном случае. G>Большинство современных языков имею так называемую Expression Problem. Суть её заключается в невозможности одновременно расширять структуры данных а операции над ними. Ни один ООП язык этого не позволяет.
Это все ерунда, если бы указанные принципы (SOLID) или другие давали только преимущества и достигались однозначным образом, то они бы стали чем то наподобии законов, которые выполняются везде и всегда. Но это не так, это не более чем рекомендации и нет горантии что они дадут пользу. НАпример, двойная деспетчеризация и отказ от инкапсуляции структур данных может сократить горы труда. Есть языки в которых двойная деспетчеризация — норма и встроена в язык. но это ни в коем случае не означает что она дает преимущество везде, всегда и в любой ситуации.
Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
ZEN>>>>После 15 лет использования ООП прихожу к тому же выводу: парадигма ООП — полная бредятина, не имеющая ничего общего с реальностью. Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое. V>>>Я так понимаю что любой паттерн проектирования улучшая что-то другое ухудшает и нет никаких принципов, следовать которым нужно любой ценой. G>>Неверно понимаешь. Подавляющее большинство "паатернов" ничего не ухудшают, они дают рецепт для решения типовой задачи. В современных языках многие такие паттерны включены в сам язык. Например observer — event_ы в .NET и Delphi, аналогично итераторы.
V>То что есть паттерны "почти ничего не ухудшающие" не означает, что все паттерны ничего не ухудшают. Возьми паттерн посетитель, например. Нельзя сказать что он ничего не ухудшает.
Это и называется expression problem. Проблема не в паттерне, проблема в ООП и конкретных языках.
V>Все паттерны хоть немного но ухудшают понимание программы.
Наоборот паттерны улучшают понимание программы ибо они много где описаны и обсосаны. А ad-hoc решение той же задачи будет гораздо менее понятным.
V>При этом применения одних паттернов накладывает ограничение на последующее применение других паттернов.
Пример?
V>>>Думаю тут дело даже не в компромисах, а в полном отсутствии однозначного решения любой проблемной ситуации. G>>Неверно. Это в конкретном языке могут отсутствовать средства адекватно выразить задачу, тогда возникает проблема как её эффективно решить в конкретном случае. G>>Большинство современных языков имею так называемую Expression Problem. Суть её заключается в невозможности одновременно расширять структуры данных а операции над ними. Ни один ООП язык этого не позволяет.
V>Это все ерунда, если бы указанные принципы (SOLID) или другие давали только преимущества и достигались однозначным образом, то они бы стали чем то наподобии законов, которые выполняются везде и всегда.
LSP достигается однозначным образом, но люди не понимают проблем нарушения LSP пока не столкнутся с ними.
DIP тоже, но также не все могут понять зачем оно надо, и без корректных инструментов DIP сложно реализовать.
Некоторые принципы, вроде SRP или OCP, и тот же DIP слишком расплывчато описаны чтобы по ним можно было какие-то действия предпринимать. Это часто становится предметом спекуляций различных евангелистов.
V>Но это не так, это не более чем рекомендации и нет горантии что они дадут пользу.
Как раз гарантии есть, НО... достижение принципов требует пересмотра подхода к разработке и переписывания кода если он уже был написан, а это затраты, которые не все захотят нести (получаются долги проектирования).
На больших объемах кода достижение принципов может оказаться дороже, чем польза от них. Но это не проблема самих принципов.
V>НАпример, двойная деспетчеризация и отказ от инкапсуляции структур данных может сократить горы труда. Есть языки в которых двойная деспетчеризация — норма и встроена в язык. но это ни в коем случае не означает что она дает преимущество везде, всегда и в любой ситуации.
Там где не дает преимуществ, там не надо использовать... В чем проблема?
Ты же говоришь что паттерны что-то могут ухудшить, приведи пример ухудшения от встроенной в язык двойной диспетчеризации.
Здравствуйте, gandjustas, Вы писали:
V>>То что есть паттерны "почти ничего не ухудшающие" не означает, что все паттерны ничего не ухудшают. Возьми паттерн посетитель, например. Нельзя сказать что он ничего не ухудшает.
G>Это и называется expression problem. Проблема не в паттерне, проблема в ООП и конкретных языках.
Ога, языки и ООП виноваты. Только странно, что симптомы проблемы везде без исключения одинаковые
V>>Все паттерны хоть немного но ухудшают понимание программы. G>Наоборот паттерны улучшают понимание программы ибо они много где описаны и обсосаны. А ad-hoc решение той же задачи будет гораздо менее понятным.
V>>При этом применения одних паттернов накладывает ограничение на последующее применение других паттернов. G>Пример?
Например заюзал ты декоратор... а потом хочешь визитор всутуть. Что дальше ?
V>>Это все ерунда, если бы указанные принципы (SOLID) или другие давали только преимущества и достигались однозначным образом, то они бы стали чем то наподобии законов, которые выполняются везде и всегда. G>LSP достигается однозначным образом, но люди не понимают проблем нарушения LSP пока не столкнутся с ними. G>DIP тоже, но также не все могут понять зачем оно надо, и без корректных инструментов DIP сложно реализовать. G>Некоторые принципы, вроде SRP или OCP, и тот же DIP слишком расплывчато описаны чтобы по ним можно было какие-то действия предпринимать. Это часто становится предметом спекуляций различных евангелистов.
Все эти принципы не более чем варианты оптимизации структуры и сводятся к coupling + cohesion.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
V>>>То что есть паттерны "почти ничего не ухудшающие" не означает, что все паттерны ничего не ухудшают. Возьми паттерн посетитель, например. Нельзя сказать что он ничего не ухудшает.
G>>Это и называется expression problem. Проблема не в паттерне, проблема в ООП и конкретных языках. I>Ога, языки и ООП виноваты. Только странно, что симптомы проблемы везде без исключения одинаковые
Именно, мало в каких языках возможно решить expression problem.
Причем тут паттерн посетитель, если в ФП существует аналогичный expression problem?
V>>>Все паттерны хоть немного но ухудшают понимание программы. G>>Наоборот паттерны улучшают понимание программы ибо они много где описаны и обсосаны. А ad-hoc решение той же задачи будет гораздо менее понятным.
V>>>При этом применения одних паттернов накладывает ограничение на последующее применение других паттернов. G>>Пример? I>Например заюзал ты декоратор... а потом хочешь визитор всутуть. Что дальше ?
Обычно визитор просто так не пихают. Для визитора много предусловий надо и решает он узкий круг задач.
Скорее всего будет наоборот: ты юзаешь визитор, а потом хочешь декоратор всунуть. А тут натыкаешться на expression problem и ты не можешь просто так расширить структуру классов (а декоратор именно расширяет структуру классов).
V>>>Это все ерунда, если бы указанные принципы (SOLID) или другие давали только преимущества и достигались однозначным образом, то они бы стали чем то наподобии законов, которые выполняются везде и всегда. G>>LSP достигается однозначным образом, но люди не понимают проблем нарушения LSP пока не столкнутся с ними. G>>DIP тоже, но также не все могут понять зачем оно надо, и без корректных инструментов DIP сложно реализовать. G>>Некоторые принципы, вроде SRP или OCP, и тот же DIP слишком расплывчато описаны чтобы по ним можно было какие-то действия предпринимать. Это часто становится предметом спекуляций различных евангелистов.
I>Все эти принципы не более чем варианты оптимизации структуры и сводятся к coupling + cohesion.
Ты иллюстрируешь выделенное выше.
Copuling ты еще можешь померить. Хотя это неоднозначная характеристика, можешь сразу сказать что лучше: несколько классов с высоким coupling или много классов с низким? Cohesion вообще нифига не формализуется.
Здравствуйте, gandjustas, Вы писали:
G>>>Это и называется expression problem. Проблема не в паттерне, проблема в ООП и конкретных языках. I>>Ога, языки и ООП виноваты. Только странно, что симптомы проблемы везде без исключения одинаковые G>Именно, мало в каких языках возможно решить expression problem. G>Причем тут паттерн посетитель, если в ФП существует аналогичный expression problem?
О чем я тебе и говорю. А ты вот проблему углядел в ооп и конкретных языках.
I>>Например заюзал ты декоратор... а потом хочешь визитор всутуть. Что дальше ? G>Обычно визитор просто так не пихают. Для визитора много предусловий надо и решает он узкий круг задач. G>Скорее всего будет наоборот: ты юзаешь визитор, а потом хочешь декоратор всунуть. А тут натыкаешться на expression problem и ты не можешь просто так расширить структуру классов (а декоратор именно расширяет структуру классов).
А если сначала декоратоа а потом визитор, то ровно тоже самое
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>>>Это и называется expression problem. Проблема не в паттерне, проблема в ООП и конкретных языках. I>>>Ога, языки и ООП виноваты. Только странно, что симптомы проблемы везде без исключения одинаковые G>>Именно, мало в каких языках возможно решить expression problem. G>>Причем тут паттерн посетитель, если в ФП существует аналогичный expression problem?
I>О чем я тебе и говорю. А ты вот проблему углядел в ооп и конкретных языках.
Ну так весь вопрос упирается в конкретные языки. В Haskell можно победить expression problem, в ооп языках с мультиметодами — тоже.
I>>>Например заюзал ты декоратор... а потом хочешь визитор всутуть. Что дальше ? G>>Обычно визитор просто так не пихают. Для визитора много предусловий надо и решает он узкий круг задач. G>>Скорее всего будет наоборот: ты юзаешь визитор, а потом хочешь декоратор всунуть. А тут натыкаешться на expression problem и ты не можешь просто так расширить структуру классов (а декоратор именно расширяет структуру классов).
I>А если сначала декоратоа а потом визитор, то ровно тоже самое
Читай сначала. Визитор просто так не появляется, он слишком большое влияние оказывает на дизайн чтобы его втыкать просто когда захочется.
Только это не проблема визитора, это и есть expression problem, которая гораздо более общая.
А вот любой другой паттерн очень хорошо совмещается с тем же декоратором.
Здравствуйте, gandjustas, Вы писали:
I>>О чем я тебе и говорю. А ты вот проблему углядел в ооп и конкретных языках. G>Ну так весь вопрос упирается в конкретные языки. В Haskell можно победить expression problem, в ооп языках с мультиметодами — тоже.
Покажи пример решения этой проблемы с мультиметодами.
I>>>>Например заюзал ты декоратор... а потом хочешь визитор всутуть. Что дальше ? G>>>Обычно визитор просто так не пихают. Для визитора много предусловий надо и решает он узкий круг задач. G>>>Скорее всего будет наоборот: ты юзаешь визитор, а потом хочешь декоратор всунуть. А тут натыкаешться на expression problem и ты не можешь просто так расширить структуру классов (а декоратор именно расширяет структуру классов).
I>>А если сначала декоратоа а потом визитор, то ровно тоже самое G>Читай сначала. Визитор просто так не появляется, он слишком большое влияние оказывает на дизайн чтобы его втыкать просто когда захочется. G>Только это не проблема визитора, это и есть expression problem, которая гораздо более общая.
И декоратор тоже оказывает влияние на дизайн. И любой паттерн тоже. Вопрос только в степени влияния.
G>А вот любой другой паттерн очень хорошо совмещается с тем же декоратором.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>О чем я тебе и говорю. А ты вот проблему углядел в ооп и конкретных языках. G>>Ну так весь вопрос упирается в конкретные языки. В Haskell можно победить expression problem, в ооп языках с мультиметодами — тоже.
I>Покажи пример решения этой проблемы с мультиметодами.
Да нивопрос:
abstract class A {}
class B:A {}
class C:A {}
puublic abstract class BaseVisitor
{
public abstract void Visit(A obj);
}
public class Visitor:BaseVisitor
{
public override void Visit(B obj) {}
public override void Visit(C obj) {}
}
Собвственно никто не мешает добавить наследников A и насоздавать дополнительных визиторов со своей обработкой новых типов.
I>>>>>Например заюзал ты декоратор... а потом хочешь визитор всутуть. Что дальше ? G>>>>Обычно визитор просто так не пихают. Для визитора много предусловий надо и решает он узкий круг задач. G>>>>Скорее всего будет наоборот: ты юзаешь визитор, а потом хочешь декоратор всунуть. А тут натыкаешться на expression problem и ты не можешь просто так расширить структуру классов (а декоратор именно расширяет структуру классов).
I>>>А если сначала декоратоа а потом визитор, то ровно тоже самое G>>Читай сначала. Визитор просто так не появляется, он слишком большое влияние оказывает на дизайн чтобы его втыкать просто когда захочется. G>>Только это не проблема визитора, это и есть expression problem, которая гораздо более общая.
I>И декоратор тоже оказывает влияние на дизайн. И любой паттерн тоже. Вопрос только в степени влияния.
Нет, декоратор неинтрузивен. Вызывающий код не узнает о появлении декоратора если активно не пользуется type-testing.
G>>А вот любой другой паттерн очень хорошо совмещается с тем же декоратором. I>Чушь.
Приведи контрпример.
I>>Покажи пример решения этой проблемы с мультиметодами.
-----------------------------------------^^^^^^^^^^^^^^
G>Да нивопрос:
G>
G>abstract class A {}
G>class B:A {}
G>class C:A {}
G>puublic 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) {}
G> public override void Visit(C obj) {}
G>}
G>
G>Собвственно никто не мешает добавить наследников A и насоздавать дополнительных визиторов со своей обработкой новых типов.
И где тут мультиметоды ? Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно
I>>И декоратор тоже оказывает влияние на дизайн. И любой паттерн тоже. Вопрос только в степени влияния.
G>Нет, декоратор неинтрузивен. Вызывающий код не узнает о появлении декоратора если активно не пользуется type-testing.
С визитором как раз на это и напорешься.
G>>>А вот любой другой паттерн очень хорошо совмещается с тем же декоратором. I>>Чушь. G>Приведи контрпример.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>
I>>>Покажи пример решения этой проблемы с мультиметодами.
I>-----------------------------------------^^^^^^^^^^^^^^
I>
G>>Да нивопрос:
G>>
G>>abstract class A {}
G>>class B:A {}
G>>class C:A {}
G>>puublic 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) {}
G>> public override void Visit(C obj) {}
G>>}
G>>
G>>Собвственно никто не мешает добавить наследников A и насоздавать дополнительных визиторов со своей обработкой новых типов.
I>И где тут мультиметоды ? Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно
Визитор и есть костыль в отсутствии мультиметодов. Мультиметоды делают multiple dispatch внутри, поэтому ты без геморроя можешь расширять структуру классов. Паттерн визитор возлагает двойную диспетчеризацию на саму структуру классов, что препятствует её расширяемости.
I>>>И декоратор тоже оказывает влияние на дизайн. И любой паттерн тоже. Вопрос только в степени влияния. G>>Нет, декоратор неинтрузивен. Вызывающий код не узнает о появлении декоратора если активно не пользуется type-testing. I>С визитором как раз на это и напорешься.
ты еще не понял что визитор сильно отличается от других паттернов? Причем именно из-за expression problem.
G>>>>А вот любой другой паттерн очень хорошо совмещается с тем же декоратором. I>>>Чушь. G>>Приведи контрпример.
I>Смотри внимательно I>
Здравствуйте, gandjustas, Вы писали:
G>>>Собвственно никто не мешает добавить наследников A и насоздавать дополнительных визиторов со своей обработкой новых типов.
I>>И где тут мультиметоды ? Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно
G>Визитор и есть костыль в отсутствии мультиметодов.
Я просил показать решение на мултиметодах. Есть чего показать ?
I>>>>Чушь. G>>>Приведи контрпример.
I>>Смотри внимательно I>>
I>>StateBase state = (StateBase)CurrentState();
I>>
Здравствуйте, gandjustas, Вы писали:
G>>>Неверно понимаешь. Подавляющее большинство "паатернов" ничего не ухудшают, они дают рецепт для решения типовой задачи. В современных языках многие такие паттерны включены в сам язык. Например observer — event_ы в .NET и Delphi, аналогично итераторы. V>>То что есть паттерны "почти ничего не ухудшающие" не означает, что все паттерны ничего не ухудшают. Возьми паттерн посетитель, например. Нельзя сказать что он ничего не ухудшает.
G>Это и называется expression problem. Проблема не в паттерне, проблема в ООП и конкретных языках.
Ну еще скажи дело в руках и голове программиста. Паттерны такие классные, великолепные, суперовые, а люди все гадкие стараются всё испаганить Вот попробуй проигнорировать силу гравитации. Паттерны может каждый понимать и применять по своему, в этом отличие закона от расплывчатых рекомендаций.
V>>Все паттерны хоть немного но ухудшают понимание программы. G>Наоборот паттерны улучшают понимание программы ибо они много где описаны и обсосаны. А ad-hoc решение той же задачи будет гораздо менее понятным.
V>>При этом применения одних паттернов накладывает ограничение на последующее применение других паттернов. G>Пример?
Посетитель затрудняет применение инкапсуляции. И наоборот.
V>>Это все ерунда, если бы указанные принципы (SOLID) или другие давали только преимущества и достигались однозначным образом, то они бы стали чем то наподобии законов, которые выполняются везде и всегда. G>LSP достигается однозначным образом, но люди не понимают проблем нарушения LSP пока не столкнутся с ними. G>DIP тоже, но также не все могут понять зачем оно надо, и без корректных инструментов DIP сложно реализовать. G>Некоторые принципы, вроде SRP или OCP, и тот же DIP слишком расплывчато описаны чтобы по ним можно было какие-то действия предпринимать. Это часто становится предметом спекуляций различных евангелистов.
Никогда не будет достигнуто согласие по поводу того, какой подход самый лучший. У всякого приема есть достоинства и недостатки, паттернов без недостатков не существует.
V>>Но это не так, это не более чем рекомендации и нет горантии что они дадут пользу. G>Как раз гарантии есть, НО... достижение принципов требует пересмотра подхода к разработке и переписывания кода если он уже был написан, а это затраты, которые не все захотят нести (получаются долги проектирования). G>На больших объемах кода достижение принципов может оказаться дороже, чем польза от них. Но это не проблема самих принципов.
Как-то у вас все просто, прямо захотелось пожить в вашем идеальном мире.
G>Ты же говоришь что паттерны что-то могут ухудшить, приведи пример ухудшения от встроенной в язык двойной диспетчеризации.
Зачем? Камень преткновения не в конкретных недостатках конкретного драйвера, а в твоем упрямом не желании признать их наличие. Давай наоборот, приведи пример языка с двойной диспетчеризацией который бы годился как для написания драйверов так и для обучения детей в школе азам программирования? Раз недостатков у паттернов нет, значит такой язык обязан существовать
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Ikemefula, Вы писали:
I>>Здравствуйте, gandjustas, Вы писали:
I>>
I>>>>Покажи пример решения этой проблемы с мультиметодами.
I>>-----------------------------------------^^^^^^^^^^^^^^
I>>
G>>>Да нивопрос:
G>>>
G>>>abstract class A {}
G>>>class B:A {}
G>>>class C:A {}
G>>>puublic 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) {}
G>>> public override void Visit(C obj) {}
G>>>}
G>>>
G>>>Собвственно никто не мешает добавить наследников A и насоздавать дополнительных визиторов со своей обработкой новых типов.
I>>И где тут мультиметоды ? Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно
G>Визитор и есть костыль в отсутствии мультиметодов. Мультиметоды делают multiple dispatch внутри, поэтому ты без геморроя можешь расширять структуру классов. Паттерн визитор возлагает двойную диспетчеризацию на саму структуру классов, что препятствует её расширяемости.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>>>Собвственно никто не мешает добавить наследников A и насоздавать дополнительных визиторов со своей обработкой новых типов.
I>>>И где тут мультиметоды ? Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно
G>>Визитор и есть костыль в отсутствии мультиметодов.
I>Я просил показать решение на мултиметодах. Есть чего показать ?
Я тебе и показал? Ты не видишь отличия мультиметодов от визитора? Попробуй тогда взять какой-нить готовый визитор и попытайся расширить структуру классов, которые обрабатывает визитор.
Естественно, в соответствии с OCP ты не имеешь доступа к исходному коду существующих классов.
Здравствуйте, Vaako, Вы писали:
V>>>Все паттерны хоть немного но ухудшают понимание программы. G>>Наоборот паттерны улучшают понимание программы ибо они много где описаны и обсосаны. А ad-hoc решение той же задачи будет гораздо менее понятным. V>
V>>>При этом применения одних паттернов накладывает ограничение на последующее применение других паттернов. G>>Пример? V>Посетитель затрудняет применение инкапсуляции. И наоборот.
Проблема не в "посетителе", она более глобальна. Посетитель — костыль. Есть и другие, некостыльные паттерны. Фабрика например. Вот покажи на примере фабрики что она затрудняет.
V>>>Это все ерунда, если бы указанные принципы (SOLID) или другие давали только преимущества и достигались однозначным образом, то они бы стали чем то наподобии законов, которые выполняются везде и всегда. G>>LSP достигается однозначным образом, но люди не понимают проблем нарушения LSP пока не столкнутся с ними. G>>DIP тоже, но также не все могут понять зачем оно надо, и без корректных инструментов DIP сложно реализовать. G>>Некоторые принципы, вроде SRP или OCP, и тот же DIP слишком расплывчато описаны чтобы по ним можно было какие-то действия предпринимать. Это часто становится предметом спекуляций различных евангелистов. V>Никогда не будет достигнуто согласие по поводу того, какой подход самый лучший. У всякого приема есть достоинства и недостатки, паттернов без недостатков не существует.
Ок, какие недостатки у фабрики?
V>>>Но это не так, это не более чем рекомендации и нет горантии что они дадут пользу. G>>Как раз гарантии есть, НО... достижение принципов требует пересмотра подхода к разработке и переписывания кода если он уже был написан, а это затраты, которые не все захотят нести (получаются долги проектирования). G>>На больших объемах кода достижение принципов может оказаться дороже, чем польза от них. Но это не проблема самих принципов. V>Как-то у вас все просто, прямо захотелось пожить в вашем идеальном мире.
Что простого ты увидел? Всегда надо принимать решения, только надо понимать факторы, на основании которых ты принимаешь решения.
Твоя заявление что "все паттерны имеют недостатки" таким пониманием не пахнет.
G>>Ты же говоришь что паттерны что-то могут ухудшить, приведи пример ухудшения от встроенной в язык двойной диспетчеризации. V>Зачем? Камень преткновения не в конкретных недостатках конкретного драйвера, а в твоем упрямом не желании признать их наличие. Давай наоборот, приведи пример языка с двойной диспетчеризацией который бы годился как для написания драйверов так и для обучения детей в школе азам программирования? Раз недостатков у паттернов нет, значит такой язык обязан существовать
Логической цепочки вообще не понял, причем тут драйверы и обучение? Ты уводишь тему разговора.
Скажи какие недостатки от встроенной в язык множественной диспетчеризации.
Если двойная диспетчеризация не подходит для решения конкретной задачи, то это не проблема двойной диспетчеризации, не так ли?
Аналогично использование любого паттерна, не подходящего для задачи ничего не улучшит, но это ведь не проблема паттернов.
Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Ikemefula, Вы писали:
I>>>Здравствуйте, gandjustas, Вы писали:
I>>>
I>>>>>Покажи пример решения этой проблемы с мультиметодами.
I>>>-----------------------------------------^^^^^^^^^^^^^^
I>>>
G>>>>Да нивопрос:
G>>>>
G>>>>abstract class A {}
G>>>>class B:A {}
G>>>>class C:A {}
G>>>>puublic 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) {}
G>>>> public override void Visit(C obj) {}
G>>>>}
G>>>>
G>>>>Собвственно никто не мешает добавить наследников A и насоздавать дополнительных визиторов со своей обработкой новых типов.
I>>>И где тут мультиметоды ? Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно
G>>Визитор и есть костыль в отсутствии мультиметодов. Мультиметоды делают multiple dispatch внутри, поэтому ты без геморроя можешь расширять структуру классов. Паттерн визитор возлагает двойную диспетчеризацию на саму структуру классов, что препятствует её расширяемости.
V>Тут действительно нет мультиметодов
Покажи как выглядят мультиметоды чтоли.
Здравствуйте, gandjustas, Вы писали:
V>>Тут действительно нет мультиметодов G>Покажи как выглядят мультиметоды чтоли.
Судя по википедии ты прав. здесь 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
Мультиме́тод (англ. multimethod) или мно́жественная диспетчериза́ция (англ. multiple dispatch) — механизм, позволяющий выбрать одну из нескольких функций в зависимости от динамических типов или значений аргументов.
В данном случае, естественно, следует отличать мультиметоды от статической перегрузки, так как, в отличие от последней, диспетчеризация происходит в рантайме.
У визитора таки статическая перегрузка, так что визитор это не мультиметоды
Здравствуйте, 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, Вы писали:
I>>>>И где тут мультиметоды ? Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно
G>>>Визитор и есть костыль в отсутствии мультиметодов.
I>>Я просил показать решение на мултиметодах. Есть чего показать ? G>Я тебе и показал? Ты не видишь отличия мультиметодов от визитора? Попробуй тогда взять какой-нить готовый визитор и попытайся расширить структуру классов, которые обрабатывает визитор.
Я тебя попросил показать __мултиметоды__.
Не можешь, не хочешь — так и пиши — не могу, не хочу и тд. Не надо галиматью всякую писать.
G>Естественно, в соответствии с OCP ты не имеешь доступа к исходному коду существующих классов.
G>Потом тоже самое с мультиметодами.
Здравствуйте, gandjustas, Вы писали:
V>>Мультиме́тод (англ. multimethod) или мно́жественная диспетчериза́ция (англ. multiple dispatch) — механизм, позволяющий выбрать одну из нескольких функций в зависимости от динамических типов или значений аргументов. G>То есть мультиметоды есть?
V>>В данном случае, естественно, следует отличать мультиметоды от статической перегрузки, так как, в отличие от последней, диспетчеризация происходит в рантайме. V>>У визитора таки статическая перегрузка, так что визитор это не мультиметоды
G>Да, визитор — это костыль в отсутствии мультиметодов. Почитай внимательнее фрагмент кода, который я запостил. Так могли бы выглядеть мeльтиметоды в C#(N+1), сейчас аналогичное можно повторить через dynamic.
Здравствуйте, 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, Вы писали:
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>Т.е. костыли резко перстали быть костылями ? Правильно тебя понял ?
Такое ощущение что у тебя какие-то голоса в голове которые тебе подсказывают непонятно что.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Vaako, Вы писали:
V>>Здравствуйте, gandjustas, Вы писали:
G>>>Читай дальше, чувак ошибся. Он, также как и ты, только слышал о мультиметодах, но не представляет что это.
V>>Ты это так понял да? G>Да, ты ошибся.
V>>Ну твое дело, тока у тебя таки точно мультиметодов не было, а разговоры как бы они выглядели если бы в С# реализовывались — это для детского садика оставь. G>Как-то не считаю целесообразным для предмета разговора втыкать код на эзотерических языках. При желании ты и сам можешь перевести три строчки на нужный тебе язык.
V>>По определению мультиметод это второе название двойной диспетчеризации и именно ты все запутал. G>Мультиметоды — это множественная дисипетчерезация, встроенная в язык. Когда втроенной в язык возможности нет можно писать typetest руками, но это слишком ненадежно или реализовывать паттерн визитор, но это не решает expression problem. G>В C#4 можно воспользоваться dynamic, он typetest автоматизирует.
V>>У тебя банальный визитор со статической диспетчеризацией, что не есть мультиметод по определению. G>То есть ты код даже смотрел судя по всему.
Неа, я мысли напрямую читал подключившись к всемирному разуму
Здравствуйте, 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[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 в полный рост.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Объясните принцип SOLID
От:
Аноним
Дата:
16.04.11 19:06
Оценка:
Здравствуйте, Sorc17, Вы писали:
S>У строки нет обязанности хранить строки. Строка хранит в себе данные (символы) из которых она состоит, если она не пуста. Копирование, сравнение строк, поиск подстрок — совершенно логичные операции для строки, как для владельца данных (символов) с которыми фактически происходят манипуляции, потому что строка в данном случае является информационным экспертом для выполнения этих операций.
На мой взгляд "хранение строки", естественно, подразумевает "хранение символов", а также, исходя из определения "информационного эксперта"*, то, что ты описал, и есть концепция "объект — есть данные + методы для их обработки", как, собственно, я и говорил. Хорошо, а при чем тут SRP? Как его ввернуть в эту простую и понятную концепцию? Где тут "единственная обязанность (ответственность), которая есть причина для изменения"? Вот что мне непонятно.
________________________________
* Определение из "Википедии", откуда ж еще: "Using the principle of Information Expert a general approach to assigning responsibilities is to look at a given responsibility, determine the information(выделение — мое) needed to fulfill it, and then determine where that information is stored". GRASP_(object-oriented_design) // Wikipedia, English. Информация — и есть данные. Согласно этому определению обязанности определяются исходя из данных объекта.
Re[5]: Объясните принцип SOLID
От:
Аноним
Дата:
16.04.11 19:14
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>...Лучше держать такие вещи в отдельных внешних классах. SRP в полный рост.
Не очень понял, ты предлагаешь определить строку просто как перечисляемое множество символов, а все операции вынести в отдельные классы? Тогда и будет SRP?
Здравствуйте, Аноним, Вы писали:
А>На мой взгляд "хранение строки", естественно, подразумевает "хранение символов", а также, исходя из определения "информационного эксперта"*, то, что ты описал, и есть концепция "объект — есть данные + методы для их обработки", как, собственно, я и говорил. Хорошо, а при чем тут SRP? Как его ввернуть в эту простую и понятную концепцию? Где тут "единственная обязанность (ответственность), которая есть причина для изменения"? Вот что мне непонятно.
Чтобы это понять нужно ответить на вопрос: какая обязанность у строки. Быть строкой, должно быть. Не знаю как лучше это сказать. А что значит быть строкой? Что умеет строка? А ЧЕРТ ЕГО ЗНАЕТ! У объекта должно быть поведение, поэтому давайте поручим строке выполнять базовые строковые операции. А что? Эксперт? Эксперт. Строка в себе хранит символы из которых состоит вот пусть с ними и работает. Сущность "строка" искусственная, поэтому вызывает дискомфорт. А вот примеры из книжек по ООП про Автомобиль или Лампочку не вызывают, потому что они настоящие и автомобиль совершенно точно имеет скорость и может ездить, а лампочка включаться и светить, а где вы видели строки, которые умеют сравнивать себя с другими или парсить? о_О Может в этом всё дело.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, Аноним, Вы писали: А>Не очень понял, ты предлагаешь определить строку просто как перечисляемое множество символов, а все операции вынести в отдельные классы? Тогда и будет SRP?
Ага. Ну, то есть всегда есть вопрос об оформлении бинарных операторов, но в целом идея именно такая.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Sinclair, Вы писали:
S>>...Лучше держать такие вещи в отдельных внешних классах. SRP в полный рост.
А>Не очень понял, ты предлагаешь определить строку просто как перечисляемое множество символов, а все операции вынести в отдельные классы? Тогда и будет SRP?
Например сейчас во фреймворке сравнение строк реализует класс StringComparer. В классе String есть методы Equals, CompareTo и пр, думаю (сейчас проверить к сожалению не могу) внутри этих методов используется StringComparer.
Тут мы имеем с одной стороны принципы хорошего дизайна, с другой — удобство использования. Идеальный код должен учитывать и то и другое.
Класс String, реализуя интерфейсы IComparable<string> и IEquatable<string>, берёт на себя дополнительную ответственность (по сравнению строк), но так как эта ответственность делегируется классу StringComparer, то это можно считать небольшим нарушением SRP в пользу удобства использования.
Здравствуйте, gandjustas, Вы писали:
V>>Что не понятно? В таких случаях для выделения памяти под переменную "i" обычно фабрику не применяют, хотя теоретически это вполне возможно. По твоим словам раз фабрика полезна, значит и в таких случаях должна применятся. G>Ты передергиваешь. Любой паттерн нужен для решения конкретной задачи. Нету задачи — использование паттерна бессмысленно. Ты приводишь пример, в котром нету задачи, которая решается конкретным паттерном. G>То что у тебя не такая задача — не проблема паттерна.
Если проблемы применения паттерна не связывать с паттерном, то с чем тогда свзязывать? С кривыми руками программиста? Сформируй объективно причины почему в моей примере применять паттерн фабрика для переменной i неразумно, может тогда начнешь с логикой дружить. Может даже до тебя дойдет, что четкой границы нет ни не может быть, так чтоб вот в этой сложной ситуации нужно применять фабрику, а для всех более простых ситуаций фабрику применять нельзя. Всё программирование состоит из компромиссов, у всякого проектного решения есть свои + и -. А если читать только книжки то действительно, нет недостатков у паттернов. Продолжай читать книжки.
G>Ну приведи пример, где паттерн приносит вред. То есть есть походящая для паттерна задача и его применение реально что-то ухудшает. Только не визитор, у визитора проблема не в самом патетрне.
Ага, у тебя "подходящая" уже неявно предполагает что ничего плохого нету
Пример с фабрикой для переменной i тебя не удовлетворил? Ты не знаешь как туда прикрутить фабрику? Надеюсь это для тебя посильно в принципе иначе просто нет смысла продолжать. Рассматривая паттерны мы не имеем права игнорировать визитор. Твоя трактовка проблем визитора меня просто шокирует.
V>>Есть желание рассуждать о паттернах не обращая внимания на контр-примеры, ну и рассуждайте. Никто вам это запретить не может. G>А ты не приводишь контр-примеры. То что ты приводишь не выполняет предусловия. Ботай матлогику.
Ага, действия программиста подобны доказательству математических теорем. Особенно твои в первую очередь. Аминь.
G>У меня-то как раз опыт есть, а у тебя видимо нет. Ты приводишь пример для фабрики, даже не понимая зачем фабрика нужна.
Так всё таки есть у паттернов цели, преимущества и недостатки? А то я с дуру подумал что просто проблемы с созданием переменной i в рантайме при помощи фабрики. Сам же настаиваешь на рассмотрении паттерна не более чем приема программирования. Запихиваешь ее в класс, а класс возвращает фабрика , еще прикрутить итератор на всякий случай и вообще супер пример для вредного применения паттерна фабрика получится. Если ты с этим не согласен то дальнейшие обсуждения бесполезны, с точки зрения твоей любимой формальной логики. В приведенном мной примере паттерн фабрика может быть применен. Точка. Никаких других точек зрения не рассматривается. Все нюансы и недостатки такого проектного решения в качестве самостоятельного домашнего задания. Удачи.
Ты показал обычный визитор, т.к. как обычно, всё, кроме того что было нужно 
ООП — оно совсем про другое.
