Здравствуйте, IB, Вы писали:
IB>Судя по ветке, как раз бесспорный, так как ни один из спорщиков это утверждение даже не попытался опровергнуть (как, впрочем и многие другие).
Предлагаю закрыть спор об очевидности, как очевидно бесплодный.
IB>С какого перепугу?!они бы имели доступ к приватным переменным своего класса, но ни как не того класса, который расширяют.
Если они в другом классе — они никак могут быть заменой методам с ограниченным доступом к собственным мемберам.
IB>Если у тебя метод находится в классе и в своей реализации обращается к членам этого класса, то тестировать его можно только вмест с этим классом, и mock ты туде не подсунешь.
Почему вдруг? Никаких проблем не вижу. Хочу пример, как вынос метода (только вынос, без других телодвижений) помог что-то оттестировать.
Здравствуйте, IB, Вы писали:
IB>Блинский фиг. Я не тебе что ли объяснял, и, как мне казалось, вроде бы сумел объяснить, что в 99% случаев статик хелперы превращаются в DI сервисы?
Спор сейчас о другом: стоит ли выносить в хелперы или DI сервисы все методы которые туда вынести возможно.
Про применимость DI сервиса или стратегии я бы не стал спорить вообще. Я не согласен с тем, что во всех местах где это позволяет производительность и инкапсуляция метод должен быть вынесен.
В первую очередь, вынос метода не должен снижать удобство работы с модулем.
ответил
AVK>Это не тот порог. Чтобы написать простенький код — да, скопировал пример и вперед. А вот если нужно понимать, что происходит (а это обязательное условие, если ты это применяешь в серьезном проекте) — вот тут все становится сразу печально.
Это сложность предметной области. WCF отлично ее скрывает, оставляя при этом множество механизмов тонкой настройки под себя. Что говорит об отличном дизайне. Проектировалась она явно с упором на юзабилити, а не на стоимость поддержки кода. Впрочем я до сих пор не убежден, что поголовный вынос всех возможных методов вон из класса снижает стоимость поддержки.
Здравствуйте, Ziaw, Вы писали:
Z>Спор сейчас о другом: стоит ли выносить в хелперы или DI сервисы все методы которые туда вынести возможно.
Вот именно, а ты прицепился что статик хелперы плохи. Не нравятся хелперы, выноси в DI, локатор или еще какой сервис — не принципиально.
Z> Я не согласен с тем, что во всех местах где это позволяет производительность и инкапсуляция метод должен быть вынесен.
Ты утверждаешь, что он должен быть оставлен, если так его "удобнее" использовать? Но рано или поздно все равно появится функционал, который из соображений "удобства" надо вкрячить в класс, а делать это уже будет поздно. И за что боролись?
Z>В первую очередь, вынос метода не должен снижать удобство работы с модулем.
В первую очередь дизайн модуля должен облегчать его поддержку и снижать вероятность ошибок при внесении изменений.
Здравствуйте, Ziaw, Вы писали:
AVK>>Это не тот порог. Чтобы написать простенький код — да, скопировал пример и вперед. А вот если нужно понимать, что происходит (а это обязательное условие, если ты это применяешь в серьезном проекте) — вот тут все становится сразу печально. Z>Это сложность предметной области.
И сложности самой библиотеки тоже.
Z> WCF отлично ее скрывает, оставляя при этом множество механизмов тонкой настройки под себя.
Только механизмы эти, как только ты выходишь за рамки готовых сценарных комплектов настроек, ой как не просты. Конвеер behaviors неизмеримо сложнее (гибче потому что), нежели, скажем, sink stack в ремоутинге, хотя и он — не самая простая вещь.
Z> Что говорит об отличном дизайне.
Дизайн там, безусловно, неплохой. Только он ох как непрост.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Ziaw, Вы писали:
Z>Предлагаю закрыть спор об очевидности, как очевидно бесплодный.
Не я его начал.
Z>Если они в другом классе — они никак могут быть заменой методам с ограниченным доступом к собственным мемберам.
Речь идет о публичных членах класса.
Z>Почему вдруг? Никаких проблем не вижу. Хочу пример, как вынос метода (только вынос, без других телодвижений) помог что-то оттестировать.
// возвращаемся к нашему примеру.
// Foo() - метод который пользуется только публичным контрактом A, например A.Bar().
// В этом случае протестировать реализацию Foo() можно только вместе с реализацией Bar()
//public class A : IA
{
public int Bar()
{
}
public int Foo()
{
// use A.Bar();
}
}
// А если вынести Foo() в отдельный класс, то вместо A с совершенно конкретной
// реализацией Bar() можно подсунуть mock-объкет
//public static class IAHelper
{
public int static Foo(IA a)
{
// use a.Bar();
}
}
Здравствуйте, IB, Вы писали:
IB>Вот именно, а ты прицепился что статик хелперы плохи. Не нравятся хелперы, выноси в DI, локатор или еще какой сервис — не принципиально.
Только надо понимать, что DI имеет смысл, только если нужно оторвать зависимость от реализации. Если же реализация ровно одна (как в том же случае с XxxSubstring) — смысла в DI никакого.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, IB, Вы писали:
Z>>Спор сейчас о другом: стоит ли выносить в хелперы или DI сервисы все методы которые туда вынести возможно. IB>Вот именно, а ты прицепился что статик хелперы плохи. Не нравятся хелперы, выноси в DI, локатор или еще какой сервис — не принципиально.
Я прицепился именно к выделенному.
Z>> Я не согласен с тем, что во всех местах где это позволяет производительность и инкапсуляция метод должен быть вынесен. IB>Ты утверждаешь, что он должен быть оставлен, если так его "удобнее" использовать? Но рано или поздно все равно появится функционал, который из соображений "удобства" надо вкрячить в класс, а делать это уже будет поздно. И за что боролись?
Вероятность появления такого функционала определяется каждым конкретным случаем. А вероятность увеличить количество сущностей в системе при выносе всего подряд в сервисы или хелперы 100%. Увеличение количества сущностей несомненное зло, которое должно быть скомпенсировано реальной выгодой в каждом конкретном случае. Только не надо утрировать обратными примерами типа всех методов в одном файле, т.к. бездумное уменьшение количества сущностей добром не является.
IB>
IB>// возвращаемся к нашему примеру.
IB>// Foo() - метод который пользуется только публичным контрактом A, например A.Bar().
IB>// А если вынести Foo() в отдельный класс, то вместо A с совершенно конкретной
IB>// реализацией Bar() можно подсунуть mock-объкет
IB>
Стоп. Здесь кроме выноса метода из класса мы меняем еще и внешнюю к классу сущность, интерфейс.
На основании только одной конкретной реализации метода IA.Foo() в конкретном классе A.
Очевидно, что если у всех реализаций IA планируется одинаковый метод Foo(), его нужно вынести хотя бы из соображений дублирования кода. Независимо от изменения тестабилити метода. Такой вынос не относится к дискуссии.
Здравствуйте, Ziaw, Вы писали:
Z>Я прицепился именно к выделенному.
Где там преобладание статик хелперов?
Не верь глазам своим?
Z>Вероятность появления такого функционала определяется каждым конкретным случаем.
Если библиотекой действительно пользуются, то вероятность появления функционала, который в требуемом классе не реализован равна тем же самым 100%. За примерами далеко ходить не надо, берем тот же String.IsNullOrEmpty(), который появился далеко не сразу, а уж казалось бы все что можно запихнули.
Z>А вероятность увеличить количество сущностей в системе при выносе всего подряд в сервисы или хелперы 100%. Увеличение количества сущностей несомненное зло,
Очень сомнительное зло, откровенно говоря, особенно учитывая вышеизложенное (сущности все равно придется увеличивать, но функционал уже окажется размазан) и тот факт, что полученные сущности сгруппированы по функциональному признаку, что, если верить википедии, является несомненным добром.
Z> которое должно быть скомпенсировано реальной выгодой в каждом конкретном случае.
Описание реальной выгоды я уже давал. Эта выгода присутствует, в разной степени, конечно, но во всех случаях, без исключения. Стоит эту выгоду приносить в жертву "удобству" или нет — это уже другой вопрос, но то что выгода присутствует — это факт.
Z>Стоп. Здесь кроме выноса метода из класса мы меняем еще и внешнюю к классу сущность, интерфейс.
Интерфейс может быть тот же самый. Более того, этот интерфейс может быть специально введен для тестирования (если мы совсем упертые TDD-шники) и пущей формализации контрактов.
Z>Очевидно, что если у всех реализаций IA планируется одинаковый метод Foo(), его нужно вынести хотя бы из соображений дублирования кода.
Метода Foo() может не быть в интерфейсе IA. В конце-концов и никакого IA может не быть, но Bar() являться виртуальным — тогда Mock можно сделать просто наследником A.
IB>Не верь глазам своим?
А я ничего не имел против умеренного и разумного использования DI. Я против того, что любая возможность вынести метод объявляется достаточным основанием для создания сервиса, хелпера или стратегии.
Z>>Вероятность появления такого функционала определяется каждым конкретным случаем. IB>Если библиотекой действительно пользуются, то вероятность появления функционала, который в требуемом классе не реализован равна тем же самым 100%. За примерами далеко ходить не надо, берем тот же String.IsNullOrEmpty(), который появился далеко не сразу, а уж казалось бы все что можно запихнули.
Опять неудачный пример. Этот метод в принципе не мог быть экземплярным.
Z>>А вероятность увеличить количество сущностей в системе при выносе всего подряд в сервисы или хелперы 100%. Увеличение количества сущностей несомненное зло, IB>Очень сомнительное зло, откровенно говоря, особенно учитывая вышеизложенное (сущности все равно придется увеличивать, но функционал уже окажется размазан) и тот факт, что полученные сущности сгруппированы по функциональному признаку, что, если верить википедии, является несомненным добром.
Функционал точно также окажется размазан, если разнести его тонким слоем по функциональным группам на вырост.
Причем размазан 100%, а вот вырастет ли — не факт.
Z>> которое должно быть скомпенсировано реальной выгодой в каждом конкретном случае. IB>Описание реальной выгоды я уже давал. Эта выгода присутствует, в разной степени, конечно, но во всех случаях, без исключения. Стоит эту выгоду приносить в жертву "удобству" или нет — это уже другой вопрос, но то что выгода присутствует — это факт.
Вообще-то наоборот. Жертва удобству присутствует как факт, а вот выгоды мы можем увидеть вообще.
Z>>Стоп. Здесь кроме выноса метода из класса мы меняем еще и внешнюю к классу сущность, интерфейс. IB>Интерфейс может быть тот же самый. Более того, этот интерфейс может быть специально введен для тестирования (если мы совсем упертые TDD-шники) и пущей формализации контрактов. IB>В конце-концов и никакого IA может не быть, но Bar() являться виртуальным — тогда Mock можно сделать просто наследником A.
Моку наследнику А глубоко параллельно где находится метод Foo().
Впрочем существует вариант, когда Bar() является методом интерфейса, а Foo() нет. Тогда действительно в одном случае надо будет мокать наследником, а в другом достаточно интерфейсного мока, что проще. Ладно, вариант в котором вынос метода таки может облегчить тестирование найден. Хоть и достаточно экзотичный.
Z>> Я не согласен с тем, что во всех местах где это позволяет производительность и инкапсуляция метод должен быть вынесен. IB>Ты утверждаешь, что он должен быть оставлен, если так его "удобнее" использовать? Но рано или поздно все равно появится функционал, который из соображений "удобства" надо вкрячить в класс, а делать это уже будет поздно. И за что боролись?
Никогда ничего не поздно исправить. А если еще и писать код в духе: "если появиться вот такое требование -- архитектуру придется изменить (читай усложнить) в сторону {подставте нужное}, но сейчас это не надо, так что реализовываем наиболее простой/наиболее логичный вариант". Т.е. изначально готовить себя к изменениям, то они дадутся намного проще.
Z>>В первую очередь, вынос метода не должен снижать удобство работы с модулем. IB>В первую очередь дизайн модуля должен облегчать его поддержку и снижать вероятность ошибок при внесении изменений.
Да, только предсказать с большой долей правдоподобности что же именно понадобится изменять "через год" не сможет никто. Поэтому придется раздувать архитектуру покрыв все возможные "проблемные при изменениях" места.
Поэтому (раз уж все стали четко высказывать свою позицию) я буду делать так:
Обычно, после 2-3 мин обдумывания можно точно сказать куда лучше положить такой метод. Основываясь на логике, удобстве использования, удобстве сопровождения, наконец.
Если все же непонятно куда его девать (а я уверен что таких случаев не так уже и много), то можно подключить интуицию и "метод наменьших проблем".
С интуицией все понятно, а вот метод выглядит так:
Елси наш класс содеержит небольшое количество методов, а хелпера для него еще нет, то можно добавдобавить к нему еще один метод.
Если количество методов ничинает зашкаливать (МакКоннел говорил о 7-8 методах, вроде), то нужно организовать ему хелпер. А заодно и пересмотреть остальные методы: скорее всего в хелпер перекочует большая часть из них.
Если у нас и класс с большим количеством методов и хелперы у него наличиствуют, то нужно хорошенько подумать "а как получилась у нас такая корявка?"
Здравствуйте, Ziaw, Вы писали:
Z>А я ничего не имел против умеренного и разумного использования DI.
Еще раз. В данном конкретном случае ты примотался именно к статик-хелперам, других возражений не было.
Z>Я против того, что любая возможность вынести метод объявляется достаточным основанием для создания сервиса, хелпера или стратегии.
А я за — дальше что?
Z>Опять неудачный пример. Этот метод в принципе не мог быть экземплярным.
Ну возьми Concat, если этот не нравится или Join.
Z>Функционал точно также окажется размазан, если разнести его тонким слоем по функциональным группам на вырост.
Функциональная группа образуется как только появляется хоть один метод, она уже есть, это состоявшийся факт, не важно сколько методов ее образуют — так что это не на вырост, это под конкретную ситуацию.
Тонкого слоя тоже никакого, групп будет ровно столько, сколько надо и ни на одну больше, тут уже работает неоднократно склоняемый здесь SRP.
Z>Причем размазан 100%, а вот вырастет ли — не факт.
Как раз на 100% не размазан, а вот если оставить, то на 100% будут свалены в кучу методы выполняющие разный функционал.
Z>Вообще-то наоборот.
Вообще-то нет.
Z> Жертва удобству присутствует как факт, а вот выгоды мы можем увидеть вообще.
Удобство — штука относительная, а простота поддержки — практически абсолютная, так как может быть выражена конкретными метриками и основана на совершенно конкретных принципах и практиках, направленных именно на простоту поддержки кода.
Здравствуйте, IB, Вы писали:
A>>Может и наличие инопланетян, призраков, ... бесспорный факт? Раз это никто не смог опровергнуть? IB>Нет, родной, если вести дискуссию в таком ключе, то вы вообще слили еще до ее начала.
Я не веду дисскусию в подобном ключе. Я хотел показать всю абсурдность процитированного заявления.
Здравствуйте, Aikin, Вы писали:
A>Никогда ничего не поздно исправить.
Это ты погорячился.
A> изначально готовить себя к изменениям, то они дадутся намного проще.
Вот я и рассказываю, как поступить так, чтобы потом изменения дались проще.
A>Да, только предсказать с большой долей правдоподобности что же именно понадобится изменять "через год" не сможет никто.
Что конкретно — нет, а тенденции предугадать не так и сложно. К примеру, ты строки выносишь в константы и ресурсы или тупо хардкодишь, в надежде, что менять не придется? Так и тут, тоже самое.
A>Обычно, после 2-3 мин обдумывания можно точно сказать куда лучше положить такой метод.
А еще через пол-часа, переложить его окончательно, а потом, через пару дней, переложить еще раз и убедить себя, что уж с нового места ты его точно не стронешь.
A>С интуицией все понятно, а вот метод выглядит так: A>Елси наш класс содеержит небольшое количество методов, а хелпера для него еще нет, то можно добавдобавить к нему еще один метод. A>Если количество методов ничинает зашкаливать (МакКоннел говорил о 7-8 методах, вроде), то нужно организовать ему хелпер. А заодно и пересмотреть остальные методы: скорее всего в хелпер перекочует большая часть из них. A>Если у нас и класс с большим количеством методов и хелперы у него наличиствуют, то нужно хорошенько подумать "а как получилась у нас такая корявка?"
Это метод разбиения одного большего бардака на много маленьких.
Здравствуйте, Aikin, Вы писали:
A>Я не веду дисскусию в подобном ключе.
Именно в таком ты ее и ведешь. Контраргументов нет и по делу сказать нечего, значит будем просто игнорировать и на этом основании за аргумент не считать. В демагогическом споре, конечно, удобная позиция, но совершенно не конструктивная.
A>Я хотел показать всю абсурдность процитированного заявления.
Пока ты показал, что по делу возразить тебе нечего.
Здравствуйте, Aikin, Вы писали:
A>Обычно, после 2-3 мин обдумывания можно точно сказать куда лучше положить такой метод. Основываясь на логике, удобстве использования, удобстве сопровождения, наконец. A>Если все же непонятно куда его девать (а я уверен что таких случаев не так уже и много), то можно подключить интуицию и "метод наменьших проблем". A>С интуицией все понятно, а вот метод выглядит так: A>Елси наш класс содеержит небольшое количество методов, а хелпера для него еще нет, то можно добавдобавить к нему еще один метод. A>Если количество методов ничинает зашкаливать (МакКоннел говорил о 7-8 методах, вроде), то нужно организовать ему хелпер. А заодно и пересмотреть остальные методы: скорее всего в хелпер перекочует большая часть из них. A>Если у нас и класс с большим количеством методов и хелперы у него наличиствуют, то нужно хорошенько подумать "а как получилась у нас такая корявка?"
Архитектура сама по себе — штука бесполезная. Единственный смысл ее существование — упрощение отладки и модификации кода. Поэтому ее бессмысленно делать потом, когда код уже модифицирован, это будет работать только на последующие модификации. Та же стратегия, что ты описал, ИМХО, по сути формулируется одной фразой "забиваем на архтектуру на уровне контрактов классов, пока совсем не припечет".
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, IB, Вы писали:
A>>Никогда ничего не поздно исправить. IB>Это ты погорячился.
Ок, за исключением одной вещи -- смерти человека.
A>>Да, только предсказать с большой долей правдоподобности что же именно понадобится изменять "через год" не сможет никто. IB>Что конкретно — нет, а тенденции предугадать не так и сложно. К примеру, ты строки выносишь в константы и ресурсы или тупо хардкодишь, в надежде, что менять не придется? Так и тут, тоже самое.
Да, есть масса общепринятых практик. Твое правило к которым очевидно не относится.
A>>Обычно, после 2-3 мин обдумывания можно точно сказать куда лучше положить такой метод. IB>А еще через пол-часа, переложить его окончательно, а потом, через пару дней, переложить еще раз и убедить себя, что уж с нового места ты его точно не стронешь.
Программист страдающий амнезией? Занятно.
A>>С интуицией все понятно, а вот метод выглядит так: A>>Елси наш класс содеержит небольшое количество методов, а хелпера для него еще нет, то можно добавдобавить к нему еще один метод. A>>Если количество методов ничинает зашкаливать (МакКоннел говорил о 7-8 методах, вроде), то нужно организовать ему хелпер. А заодно и пересмотреть остальные методы: скорее всего в хелпер перекочует большая часть из них. A>>Если у нас и класс с большим количеством методов и хелперы у него наличиствуют, то нужно хорошенько подумать "а как получилась у нас такая корявка?" IB>Это метод разбиения одного большего бардака на много маленьких.
Маленький бардак может оказаться вовсе не бардаком.
Здравствуйте, AndrewVK, Вы писали:
AVK>Архитектура сама по себе — штука бесполезная. Единственный смысл ее существование — упрощение отладки и модификации кода. Поэтому ее бессмысленно делать потом, когда код уже модифицирован, это будет работать только на последующие модификации. Та же стратегия, что ты описал, ИМХО, по сути формулируется одной фразой "забиваем на архтектуру на уровне контрактов классов, пока совсем не припечет".
Не надо обобщать архитектуру вообще на данный конкретный случай.
Моя стратегия формулируется так: "в данном конкретном случае нет 100% правильного решения, а с другой стороны этот вопрос не является принципиальным (если ошибешся -- будет куча головной боли, гемороя и переписывания кода). Поэтому тратить на него [вопрос] более 5 минут -- бесполезная трата времени. А самое главное: переход от одного варианта к другому стоит всего двух циклов разработки".
P.S. Про переход: А в случае если этим кодом пользуешься только ты, то и одного достаточно.
Здравствуйте, IB, Вы писали:
IB>Еще раз. В данном конкретном случае ты примотался именно к статик-хелперам, других возражений не было.
Другие возражения были. Примотался я к статик хелперам потому, что этот вариант выноса самый корявый. Что доказывает отсутствие нормальных библиотек широко использующих эти самые хелперы.
Z>>Я против того, что любая возможность вынести метод объявляется достаточным основанием для создания сервиса, хелпера или стратегии. IB>А я за — дальше что?
Это я уже понял. Дальше ничего, я сомневался что моя точка зрения понятна, потому уточнил.
Z>>Опять неудачный пример. Этот метод в принципе не мог быть экземплярным. IB>Ну возьми Concat, если этот не нравится или Join.
Concat() нельзя вынести наружу, он использует приватные методы. То, что он статик тоже вполне логично, экземплярный не смог бы реализовать "An Empty string is used in place of any null argument". Как Join может быть экземплярным я тоже не понимаю, он должен вызываться у разделителя чтоли?
Я не пойму, что эти два метода доказывают? Спор идет о методах которые могут быть с равным успехом реализованы как экземплярными так и внешними. Пока не увидел ни одного выбора в пользу внешнего в общеизвестных библеотеках.
Z>>Функционал точно также окажется размазан, если разнести его тонким слоем по функциональным группам на вырост. IB>Функциональная группа образуется как только появляется хоть один метод, она уже есть, это состоявшийся факт, не важно сколько методов ее образуют — так что это не на вырост, это под конкретную ситуацию. IB>Тонкого слоя тоже никакого, групп будет ровно столько, сколько надо и ни на одну больше, тут уже работает неоднократно склоняемый здесь SRP. Z>>Причем размазан 100%, а вот вырастет ли — не факт. IB>Как раз на 100% не размазан, а вот если оставить, то на 100% будут свалены в кучу методы выполняющие разный функционал.
Ок, давай разместим IsNullOrEmpty, Concat, Join во внешние классы. Для простоты допустим, что вопрос корректной их работы в отрыве от String не существует, остался только вопрос расположения. Как должны выглядеть эти классы/класс?
Z>> Жертва удобству присутствует как факт, а вот выгоды мы можем увидеть вообще. IB>Удобство — штука относительная, а простота поддержки — практически абсолютная, так как может быть выражена конкретными метриками и основана на совершенно конкретных принципах и практиках, направленных именно на простоту поддержки кода.
Да ничего подобного, читабельность кода не поддается автоматической оценке, не существует метрик ее измеряющих. Тем не менее она может стать самой серьезной проблемой при модификации/расширении.
То, что некоторые метрики можно выразить числом еще не означает, что они доминирующие. Их просто легко измерить.
Мы уже победили, просто это еще не так заметно...
