Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Ziaw, Вы писали:
Z>>>>Точно также легко и непринужденно с совместимостью на уровне исходников метод при необходимости выносится в extensions. AVK>>>Увы нет. Добавление элемента в контракт всегда проще, чем удаление его оттуда. Z>>Чем?
AVK>Тем, что про новый член никто не знает, и его добавление по сути совсем не меняет семантику использующего кода (если только не умудрились дать возможность с его помощью поломать инварианты). А вот удаление метода безусловно меняет семантику тех кусков, которые его использовали, и над этими кусками уже надо думать мозгой, что делать.
Что-то я туплю, как может перенос метода в экстеншен поменяет семантику кода? null в качестве аргумента? так можно добавить проверку и кинуть экзепшен. может быть рефлекшен или приколы из области этюдов nikov'а?
Здравствуйте, AndrewVK, Вы писали:
Z>>1. для ухудшения читабельности кода AVK>Пример этого не продемонстрировал.
Я тебе дам пример. Есть некоторый класс HtmlElement, название говорит само за себя, это базовый класс HTML движка. Не важно какого: IE, Mozilla, Opera, везде практически одно и то же. В минимальной реализации он такой.
class HtmlElement
{
private IntPtr _handle;
public HtmlElement(IntPtr handle)
{
this._handle = handle;
}
public IntPtr Handle
{
get { return this._handle; }
}
}
Здравствуйте, adontz, Вы писали:
A>Я тебе дам пример. Есть некоторый класс HtmlElement
О, веб-формсы. Мою любимый пример как делать не надо. Но тут тебе лучше у Синклера поспрошать, он тебе более качественно объяснить, почему. Я в вебе не очень хорошо разбираюсь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Ziaw, Вы писали:
Z>>1. для ухудшения читабельности кода AVK>Пример этого не продемонстрировал. AVK>Ага, особенно если учесть, что код с использванием extension методов идентичен коду использования instance методов вплоть до символа.
Специально же написал что пункт один не относится к выносу в ЕМ. Как только задача сводится к выносу в EM этот пункт не играет.
Z>>2. для ухудшения расширяемости AVK>Пример этого не продемонстрировал.
И всетаки появление полиморфности вполне реальная ситуация, решение проблемы усложняется.
AVK>Ну вот, ты и сам можешь ответить на свой вопрос, почему раздувание твоего гипотетического ISet — идея совсем не замечательная.
Когда в перспективе вероятен полиморфный метод я не буду смотреть, что сейчас использует реализация, она вполне может измениться. По крайней мере одну поправку к правилу для себя я нашел.
Здравствуйте, AndrewVK, Вы писали:
AVK>О, веб-формсы. Мою любимый пример как делать не надо. Но тут тебе лучше у Синклера поспрошать, он тебе более качественно объяснить, почему. Я в вебе не очень хорошо разбираюсь.
Андрей, я ещё раз повторю, никто не говорит что это хороший дизайн. Ни коим разом. Это плохой дизайн и можно придумать дизайн, который формально лучше. Проблема критиков в том, что хороший дизайн на фиг никому не нужен. Можно писать исследовательские статье на тему какое говно DOM утверждённый W3C, но DOM W3C это предметная облать и любое несоответсвие между объектной моделью системы автоматизации браузера и DOM W3C — проблема. Пытаясь улучшить дизайн, улучшатели меняют не объектную модель, а предметнубю область.
Здравствуйте, adontz, Вы писали:
A>Андрей, я ещё раз повторю, никто не говорит что это хороший дизайн. Ни коим разом. Это плохой дизайн и можно придумать дизайн, который формально лучше.
Не только формально. Вот погляди на WPF и сравни его с винформсами, скажем тот же класс Control — разница поразительная. не так ли. Хотя и в WPF не все хорошо в этом плане, имхо.
A> Проблема критиков в том, что хороший дизайн на фиг никому не нужен.
Точно, нужен плохой.
A> Можно писать исследовательские статье на тему какое говно DOM утверждённый W3C
XML DOM то? Говно и есть.
A> Пытаясь улучшить дизайн, улучшатели меняют не объектную модель, а предметнубю область.
И как изменилась предметная область у XDocument по сравнению с XmlDocument?
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Ziaw, Вы писали:
Z>Специально же написал что пункт один не относится к выносу в ЕМ. Как только задача сводится к выносу в EM этот пункт не играет.
То есть в ответ на вопрос, зачем твой пример, ты ответил тем, что на самом деле ответом не яляется. Я чего то уже теряю нить рассуждения.
AVK>>Пример этого не продемонстрировал. Z>И всетаки появление полиморфности вполне реальная ситуация, решение проблемы усложняется.
Появление или пропадание полиморфности находится абсолютно за рамками принципа Мейерса по вынесению методов.
Z>Когда в перспективе вероятен полиморфный метод я не буду смотреть, что сейчас использует реализация, она вполне может измениться. По крайней мере одну поправку к правилу для себя я нашел.
Это не поправка к правилу, это его следствие. Необходимость полиморфизма однозначно требует помещения метода в основной контракт и правилу никак не противоречит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>>Еще как упала. Раз уж была упомянута STL: хороший пример — разделение алгоритмов и контейнеров: все что необходимо, так это предоставить пару итераторов — все остальное начнет работать автоматически. То же и для алгоритмов поверх любых контейнеров. А что будет если слить все в кучу ?
A>.Net Framework Class Library?
Нет, там как раз порезано на множество классов, что лучше чем один.
ЮЖ>>Здесь множество причин для изменений. Я про это.
A>Ты как-то криво обозвал SRP.
Почему?
A>SRP как и любой другой принцип не самоцель и не надо под алгом больбы с классами занимающимися сразу несколькими задачами измельчать всё что можно и нельзя.
Интерфейс изначально должен быть минимально полным для выполненя своих обязанностей. Уже потом он может обрастать хелперами.
A>Есть классы, которые не просто содержат сотню методов, это абсолютно нормально в предметной области их использования.
Если это минимально полный набор, то пожалуйста.
... A>>>И получить STL где у сттроки нет нормального find ЮЖ>>А нормальный это какой ? с регэкспами и поиском через гугл?
A>Досстаточно регэкспов.
Реализуются через существующий интерфейс. Бывают разные, да и нужны далеко не всем. + тут встает вопрос об "объектной модели" строк.
ЮЖ>>Может быть. В зависимости от задачи. Со строками проблема в том, что там слишком много потенциально настраиваемых моментов, и при попытке свалить все в кучу получится вышеупомянутый реструктуризатор.
A>Да вот System.String как-то всем хватает.
Я имел ввиду положение дел в С++
ЮЖ>>Не надо доводить до маразма кажущееся "удобство" в виде автокомплита. Иначе чем объяснить изначальное существование в классе методов которых там не должно быть? A>Соответствие логике предметной области.
Как может соответствовать логике предметной области то, что ей не соответствует ? ну вот например, нет у класса dog метода 'save(database&)'. Нету.
А писать, да удобнее: 'my_dog.save(db)' с автокомплитом так вообще прелесть =)
ЮЖ>>Ничего против автокомплита не имею, но неужели это действительно может рассматриваться как критерий выбора библиотеки ? A>Близость объектной модели и реалий предметной области — критерий.
Я говорю не о том чтобы вырезать методы из класса, мотивируя разделением обязанностей, а о том чтобы изначально не создавать лишние методы. Я не могу предвидеть все варианты использования(если речь про библиотеку), но я могу только предоставить минимально необходимый интерфейс к одной логической сущности.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не только формально. Вот погляди на WPF и сравни его с винформсами, скажем тот же класс Control — разница поразительная. не так ли. Хотя и в WPF не все хорошо в этом плане, имхо.
Что не мешает HTML + CSS по декларативным возможностям рвать WPF. Ну и чего было столько мучаться когда старая система с плохой архитектурой оказалась мощнее новой системы с хорошей архитектурой? Да ещё и шустрее.
A>> Проблема критиков в том, что хороший дизайн на фиг никому не нужен. AVK>Точно, нужен плохой.
Нужен знакомый.
A>> Можно писать исследовательские статье на тему какое говно DOM утверждённый W3C AVK>XML DOM то? Говно и есть.
HTML, будь внимательнее.
A>> Пытаясь улучшить дизайн, улучшатели меняют не объектную модель, а предметнубю область. AVK>И как изменилась предметная область у XDocument по сравнению с XmlDocument?
Здравствуйте, AndrewVK, Вы писали:
AVK>То есть в ответ на вопрос, зачем твой пример, ты ответил тем, что на самом деле ответом не яляется. Я чего то уже теряю нить рассуждения.
Ответ был на AVK>Что тогда ты пытаешься доказать?
Я ответил, что я пытаюсь доказать в этой ветке вообще, а не каким-то примером в частности.
Z>>Когда в перспективе вероятен полиморфный метод я не буду смотреть, что сейчас использует реализация, она вполне может измениться. По крайней мере одну поправку к правилу для себя я нашел. AVK>Это не поправка к правилу, это его следствие. Необходимость полиморфизма однозначно требует помещения метода в основной контракт и правилу никак не противоречит.
Не необходимость, а вероятность возникновения.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
A>>.Net Framework Class Library? ЮЖ>Нет, там как раз порезано на множество классов, что лучше чем один.
По сравнению с STL сплошной монолит. Поиск в каждом контейнере свой, обощённый интерфейс очень специализированный, итераторов нет.
A>>Ты как-то криво обозвал SRP. ЮЖ>Почему?
Ну он стал трудноузнаваемым
ЮЖ>Интерфейс изначально должен быть минимально полным для выполненя своих обязанностей. Уже потом он может обрастать хелперами.
А обязанности беруться не из деталей реализации, а из предметной области.
ЮЖ>Если это минимально полный набор, то пожалуйста.
Минимально полный не с точки зрения реализации, а с точки зрения предметной области.
A>>Досстаточно регэкспов. ЮЖ>Реализуются через существующий интерфейс. Бывают разные, да и нужны далеко не всем. + тут встает вопрос об "объектной модели" строк.
Ну вот в .Net есть всего один вид и даже не такой как другие и ничего. Тут главное стандарт. В Си++ сколько было вид строк? А в Паскале? Не надо делать супер-класс, надо делать достаточно хороший и стандартный.
A>>Да вот System.String как-то всем хватает. ЮЖ>Я имел ввиду положение дел в С++
В Си++ со строками хронический бардак.
ЮЖ>Как может соответствовать логике предметной области то, что ей не соответствует ? ну вот например, нет у класса dog метода 'save(database&)'. Нету. ЮЖ>А писать, да удобнее: 'my_dog.save(db)' с автокомплитом так вообще прелесть =)
Не передёргивай. Можно писать db.save(my_dog) и это будет нормально, потому что DB это контейнер Dog. Я против, например, Bark.By(my_dog). Это может быть удобно в реализации, но страдательный залог непривычен для восприятия.
A>>Близость объектной модели и реалий предметной области — критерий. ЮЖ>Я говорю не о том чтобы вырезать методы из класса, мотивируя разделением обязанностей, а о том чтобы изначально не создавать лишние методы. Я не могу предвидеть все варианты использования (если речь про библиотеку), но я могу только предоставить минимально необходимый интерфейс к одной логической сущности.
Хорошо, только вот разбиение логической группы методов на разные классы, которое тут демонстрировалось как "хорошо", мною вопронимается как диверсия.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>Нет, там как раз порезано на множество классов, что лучше чем один.
Неужели ты думаешь, найдется хоть один человек который начнет доказвать обратное?
Практически каждый сторонник выноса всего подряд из класса кто приходит в эту ветку
сразу придумывает это неотразимый аргумент.
И пытается сделать из сторонников подумать еще о чем-то кроме формального правила борцов за бездумное засовывание всего подряд в один класс.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Юрий Жмеренецкий, Вы писали:
A>>>.Net Framework Class Library? ЮЖ>>Нет, там как раз порезано на множество классов, что лучше чем один.
A>По сравнению с STL сплошной монолит. Поиск в каждом контейнере свой, обощённый интерфейс очень специализированный, итераторов нет.
Значит еще резать надо =)
ЮЖ>>Интерфейс изначально должен быть минимально полным для выполненя своих обязанностей. Уже потом он может обрастать хелперами. A>А обязанности беруться не из деталей реализации, а из предметной области.
А я где-то утверждал обратное ?
ЮЖ>>Если это минимально полный набор, то пожалуйста. A>Минимально полный не с точки зрения реализации, а с точки зрения предметной области.
Это само собой
... A>>>Близость объектной модели и реалий предметной области — критерий. ЮЖ>>Я говорю не о том чтобы вырезать методы из класса, мотивируя разделением обязанностей, а о том чтобы изначально не создавать лишние методы. Я не могу предвидеть все варианты использования (если речь про библиотеку), но я могу только предоставить минимально необходимый интерфейс к одной логической сущности.
A>Хорошо, только вот разбиение логической группы методов на разные классы, которое тут демонстрировалось как "хорошо", мною вопронимается как диверсия.
По моему здесь демонстрировалось несколько иное: попытка добавления к интерфесу(изменение предметной области) методов, которые выразимы в терминах этого интерфейса.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
A>>Хорошо, только вот разбиение логической группы методов на разные классы, которое тут демонстрировалось как "хорошо", мною вопронимается как диверсия. ЮЖ>По моему здесь демонстрировалось несколько иное: попытка добавления к интерфесу(изменение предметной области) методов, которые выразимы в терминах этого интерфейса.
Нет-нет, пречитай внимательнее, тут собрались Свидетели Правила.
Кромсать всегда, кромсать везде,
До строк последних донца,
Кромсать и никаких идей,
Вот лозунг мой и Солнца.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>>Нет, там как раз порезано на множество классов, что лучше чем один. Z>Неужели ты думаешь, найдется хоть один человек который начнет доказвать обратное?
Сколько уже в топике сообщений ? =)
Z>Практически каждый сторонник выноса всего подряд из класса
Я не сторонник "выноса всего подряд", я сторонник не "вноса" всего подряд. Это разные вещи, ситуции когда надо выносить все подряд зачастую вообще не лечатся.
Z>кто приходит в эту ветку сразу придумывает это неотразимый аргумент.
Это оппоненты пытаются находить в сказанном обязательные "придуманные неотразимые аргументы".
Z>И пытается сделать из сторонников подумать еще о чем-то кроме формального правила борцов за бездумное засовывание всего подряд в один класс.
А сам факт существования всяческих SRP, OCP, DIP и т.п, ни на что не наводит ?
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>А сам факт существования всяческих SRP, OCP, DIP и т.п, ни на что не наводит ?
Наводит на мысль, что единого метода оценки качества кода как не было так и нет, а значит применять любой из существующих надо аккуратно. Справедливости ради надо заметить, что методы становяться всё сложнее и их область применения шире. Однако, до совершества всё равно очень далеко.
Здравствуйте, adontz, Вы писали:
A>Что не мешает HTML + CSS по декларативным возможностям рвать WPF.
Мы обсуждаем ОО API, а не декларативные возможности.
A> Ну и чего было столько мучаться когда старая система с плохой архитектурой оказалась мощнее новой системы с хорошей архитектурой? Да ещё и шустрее.
Рома, какое это имеет отношение к обсуждаемому вопросу.
A>>> Проблема критиков в том, что хороший дизайн на фиг никому не нужен. AVK>>Точно, нужен плохой.
A>Нужен знакомый.
Знакомый, простите, кому?
A>>> Можно писать исследовательские статье на тему какое говно DOM утверждённый W3C AVK>>XML DOM то? Говно и есть.
A>HTML, будь внимательнее.
, на которое я отвечал, слово HTML? Это тебе надо повнимательнее, мысли я читать не умею. И с HTML DOM, который в каком нибудь JavaScript доступен, мне знаком плохо и твои примеры мне ни о чем не говорят.
A>>> Пытаясь улучшить дизайн, улучшатели меняют не объектную модель, а предметнубю область. AVK>>И как изменилась предметная область у XDocument по сравнению с XmlDocument?
A>Я про HTML.
А с ХML та же ситуация — XML DOM унылое гавно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Ziaw, Вы писали:
AVK>>Это не поправка к правилу, это его следствие. Необходимость полиморфизма однозначно требует помещения метода в основной контракт и правилу никак не противоречит. Z>Не необходимость, а вероятность возникновения.
Мне вот кажется, что твоя ошибка в следующем — в начале ты зачем то абсолютизируешь обсуждаемое правило, а потом с этой абсолютизацией споришь. Еще раз процитирую его:
If you're writing a function that can be implemented as either a member or as a non-friend non-member, you should prefer to implement it as a non-member function.
На самом деле это правило — вторично. То есть оно не определяет внутренний дизайн методов. Там нет об этом ни слова. Любая, я повторяю, любая причина, по которой метод не может быть оторван от класса без изменения реализации этого метода, является причиной того, что этот метод должен остаться в классе. И уж если ты решил озаботиться полиморфизмом заранее — флаг тее в руки. Только это никоим образом это самое правило не нарушает.
Что же касается обоснованности подобного предварительного полиморфизма — это отдельный вопрос, за рамками правила. С моей точки зрения этого делать не стоит ни в коем случае — полиморфные структуры очень тесно интегрируются в дизайн приложения, и принимать такие глобальные решения по дизайну на всякий случай — прямой путь к неоправданно сложному дизайну.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
