Давно наблюдаю за баталией, мне кажется что баталия сваливается в частности (екстеншн методы, производительность...). Частности, конечно, имеют значение, но хочется все-же вынести какое-то общее правило. Сам я решения про вынос методов принимаю пятой точкой, чему не сильно рад, и собственные попытки сформулировать хоть какой-то принцип ни к чему хорошему не приводят.
В основном обсуждается правило, представленное IB. Применять его тупо ли, с головой ли, со здравым смыслом, с оговорками на производительность ли, как быть с парными методами (LeftSubstring и пр..). Получилась большая каша. Слишком много дополнительных условий, допущений, порой исскувственно введенных, чтобы подначить оппонента
Предлагаю рассмотреть очень простой пример (String — это довольно сложный пример, Order — тоже). Есть в FCL такой класс Rectangle... Он хорош для нашего случая тем, что в нем отсутствуют поля, которые напрямую не доступны через публичный контракт.
Предлагаю искусственно ввести условия для большего упрощения обсуждения:
* Extension методов нет вообще (допустим C# 2.0);
* На производительность нам плевать;
* Так же предлагаю принять что класс Rectangle — reference class (для того, чтобы отпали аргументы, специфичные для value типов);
* Наше пространство евклидово двумерное, стороны прямоугольника параллельны осям (т.е. нет неоднозначностей при определении принадлежности точки либо другого прямоугольника данному прямоугольнику, все реализации методов будут как в FCL);
* Никаких других дополнительных условий не возникнет. Т.е. мы ставим себя на место разработчиков FCL и создаем класс для нужд System.Drawing и System.Windows.Froms (DI нам здесь не понадобится).
Вопрос стандартный для этой темы: надо ли вынести все методы класса Rectangle в другой класс? Почему?
Думаю, что это самый главный кирпич. И если с ним не будет понятно, то дальше будет не интересно.(Надеюсь, что все согласятся с тем, что если откинуть какие-то ограничения, то случай не будет чистым и кто-то будет радеть за правильность, кто-то за производительность, кто-то за reuse, и т.п.)
Что лично я думаю о правиле, предложенном IB: вижу я довольно хороший момент в нем: методы, находящиеся внутри класса нуждаются в дополнительном анализе при принятии решения выноса их из класса при рефакторинге. В то время, очевидно, что метод, находящийся снаружи (в хелпере) может быть подвергнут переносу в другой класс без дополнительного анализа. Под дополнительным анализом подразумеваю анализ возможности использования лишь публичного контракта. Внутренние методы не тяготеют к использованию только публичного контракта.
Итого, с оговоркой на перспективу развития — это правило мне нравится. Но я не склонен выносить методы в хелперы при первой возможности. ))
Здравствуйте, samius, Вы писали: S> ... S>Итого, с оговоркой на перспективу развития — это правило мне нравится. Но я не склонен выносить методы в хелперы при первой возможности. ))
У вам наоборот слишком абстрактный пример и это не хорошо. В том то и дело что на практике все может быть по-другому.
Здравствуйте, samius, Вы писали:
S>Вопрос стандартный для этой темы: надо ли вынести все методы класса Rectangle в другой класс? Почему?
Однозначно оставить.
Стоимость поддержки широкоиспользуемой библиотеки делится на все проекты ее использующие. Да и заявления о повыешнии этой самой стоимости достаточно гиперболизированы.
Я не хочу сам использовать кучу разных хелперов для обработки прямоугольников. Я не хочу разбирать код джуниоров которые вместо одного незнакомого хелпера наделали макарон из знакомых им. Я хочу видеть все методы на одной странице хелпа.
Здравствуйте, AndrewVK, Вы писали:
AVK>По существу я ссылочку привел.
"Надо искать золотую середину, когда и дизайн не слишком плох, и перформанс приемлем."?
S>Есть в FCL такой класс Rectangle... Он хорош для нашего случая тем, что в нем отсутствуют поля, которые напрямую не доступны через публичный контракт.
Фигассе простой пример.
Но: в данном конкретном случае большинство методов, вынесенных в его публичный контракт, Прямоугольнику не нужны. Потому как есть более общие случай -- класс Region. Вот в него и должны быть вынесены эти методы.
Contains: в Region -- new Region(rectangle).IsVisible(point) // Интересное название IsVisible. Почему не Contains?
Inflates ("надувает" прямоугольник): Интересный метод. Не сильно представляю наф он нужен, но если он нужен, то только Прямоугольнику -- остается. // давайте без офтопа зачем он нужен
Intersect (пересечение): в Region
IntersectsWith (проверяет есть ли что-то в пересечении): в Region
Offset (перемещает прямоугольник): наверное, единственный метод который нужен Прямоугольнику -- остается.
Union: в Region
Здравствуйте, samius, Вы писали:
S> Получилась большая каша. Слишком много дополнительных условий, допущений, порой исскувственно введенных, чтобы подначить оппонента
Ёее.. Никакой каши. Принцип прост и понятен, никаких оговорок, исключений, частных сучаев не наблюдается вообще — тем и хорош.
В этом одно из основных преимуществ данного подхода, правило настольно четкое и конкретное, что его можно автоматизировать.
S>Вопрос стандартный для этой темы: надо ли вынести все методы класса Rectangle в другой класс? Почему?
Если изменений класса и методов не предполагается, то вопрос бессмысленный, так как все ухищрения дизайна и архитектуры направлены именно на облегчение поддержки и модификации.
Если же предвидятся какого либо рода модификации (изменение внутренней реализации класса Rectangle, появление новых алгоритмов рассчета площади, периметра, попадания точки внутрь прямоугольника, ect...), то естественно все надо выносить наружу.
1. При добавлении нового функционала не модифицируем существующий прямоугольник, а добавляем новый хелпер/сервис с новым функционалом, что очевидно лучше.
2. Все побочные эффекты изменения реализаций контролирует компилятор.
3. Можно передать наш прямоугольник через слои приложения или вообще запулить наружу через веб-сервис, не боясь неправильного вызова метода или того, что на другой стороне этого метода просто не окажется.
4. Проще тестировать методы, вместо прямоугольника можно спокойно подпихнуть mock.
N. И еще куча других аргументов, которые я уже неоднократно приводил в этом топике, начиная от глубоко теоретических и заканчивая сугубо практическими.
Внятный контраргумент прозвучал только один — неудобно использовать. Но что a.foo(), что b.foo(a) по удобству не отличаются, а цепочки вызовов a.foo().foo().foo(), мягко говоря, по любому не образец удобства.
S>Итого, с оговоркой на перспективу развития — это правило мне нравится.
Без перспективы развития, как я уже говорил, вообще весь разговор бессмысленен. Как показывает практика, в конечном итоге, работает вообще любой код, хоть всю программу в одну строчку, в одном методе напиши. Работать будет и возможно, даже без ошибок, если писать аккуратно.
Весь вопрос — во что обойдется поддержка этого кода.
Здравствуйте, Aikin, Вы писали:
A>ИМХО, вы о разном говорите
Мы говорим ровно об одном и том же..
Если отбросить Ромин искрометный юмор, то все просто как рельс. Мотивируя тем, что по каким-то причинам нам пришлось поместить один метод в класс, Рома призывает запихнуть в этот же класс и все остальные похожие методы, превратив его в большую помойку. Мне же такая мотивация кажется ни разу не убедительной..
Здравствуйте, IB, Вы писали:
IB>Вот stump бы на такое обиделся и сказал бы, что он с хамами не разговаривает и что ты вообще любитель передергивать.
Нет, он он мне уже сказал
Большой +
Все эти аргументы и многие другие уже приводились здесь. Ты действительно хорошо пишешь, но сомневаюсь, что тебе удастся в чем то убедить Ивана и Андрея.
Видимо передёргиваешься всё же ты, пытаясь прикрыться людьми, которые вовсе не хотят, чтобы ты ими прикрывался. Неужели так мало осталось соратников? Неужто раскрыта ложность твоих идеалов и все разбежались?
IB>Проблема ровно в том, что так и не смогли привести ни одного сценария, где бы это правило не работало, и я не вижу ни одной разумной причины его не применять (ну, разьве что по быстрому надо пару классов набросать и забыть).
А тебе никто не приведёт пример, когда правило не получается применить. Его получается применить всегда, однако, время от времени, это приводит к абсурдному результату, когда логически связанная группа методов оказывается разбросана по разным классам.
IB>Почему исключительно?
Потому что правило. Ты ведь принимаешь его как догму, без оговорок.
IB>Тот самый "здравый смысл", на который вы так все любите ссылаться подсказывает, что при всем желании от деталей реализации никуда не уползешь.
Нельзя уползти от предметной области, от деталей реализации можно и нужно уползать.
IB>Но, к сожалению, иногда, требования производительности идут в разрез с правильным и удобным дизайном и мы вынуждены помещать метод внутрь класса. (Собсственно, Андрей об этом уже писал). Но, при этом, заметь, правило, мной озвученное, по прежнему работает.
Правильный и красивый дизайн библиотеки подразумевает в первую очередь удобство использования, а не лёгкость поддержки. Не надо быть лентяем за счёт других.
IB>Ну вот я и пытаюсь, поднять вас до своего уровня, чтобы вы увидели стену в целом, а вы уперлись тут.. в кирпичик...
Поднять?! Переверни шкалу отсчёта, ты её неправильно держишь
IB>Откапываете всякие частности, и пытаетесь придумать сценарий при котором правило не работает — успехов..
Во-первых, не пытаюсь, а уже не раз привёл, чиатй внимательнее, разжевал я свой пример и в рот положил. Конкретного ответа так и не получил, оно и не удивительно, ведь пришлось бы признать что правило не работает. Во-вторых, сферические кони в вакууме интересуют только абстракционистов-теоретиков, а у реальных людей всегда есть частные варианты с которыми тоже надо что делать. Причём на совесть, а не прикрываться правилами.
IB>В том что "зато пользоваться удобно и абстрактно", будешь убеждать пользователя своей библиотеки, когда она начнет считать не правильно.
Что за фигня? С чего это она начнёт считать неправильно? Что за нелепый, абсурдный аргумент? Тебе нечего было больше ответить, кроме как "если не использовать моё правило, у вас будут баги"?
IB>Не можно, а нужно. Должны быть очень веские причины, чтобы при возможности использовать только внешний контракт, открывать доступ к внутреннему состоянию.
Например, здравый смысл
IB>Я правильно понимаю, что из за невозможности вынести один метод за пределы класса из соображений производительности, ты предлагаешь все остальные методы так же пихать в класс и получать один большой бардак?
Я чуть ниже отвечу на этот важный вопрос.
IB>Не угадал. Моя цель — минимизировать бардак, даже в том случае, если мы вынуждены реализовывать несколько методов не там где хотелось бы.
Не там где хотелось бы кому? Тебе или пользователю библиотеки? Мне как пользователю хелпер не удобен по определению.
IB>К тому же ты опять передергиваешь, речь не в абстрактной "внутренней красоте", а в удобстве поддержки, даже на твоем уровне это должно быть очевидно..
Удобство поддержки при написании библиотеки не является более приоритетным, чем качественный внешний интерфейс. На кой ляд хорошо поддерживаемая бюиблиотека, если ей неудобно пользоваться?
IB>Рома, не придумывай, на практике это не проблема. Для статических хелперов есть методы расширения, для избавления от этой проблемы, а с IoC и так все понятно. Более того, даже без методов расширения это не было большой проблемой.
Методы расширения для другой цели, я напишу об этом ниже.
IB>Гы. То есть, контраргументов на приведенные формальные метрики, прнципы уменьшения связности и прочие best-practice найти не удалось, значит надо обвинить оппонента в тяге к абстрактной красивости..
Ты действительно думаешь что твой или ещё какой-то рейтинг чем-то принципиально осмысленнее чем LOC/day и его область применения не узка?
A>> ведь они не могут обращаться к внутренним полям класса, а значит должны быть вынесены в хелпер. IB>А по твоему класс с Extension Method-ами — не абстрактный хелпер? А что же он тогда?
Средство расширения существующей иерархии классов (построения параллельной, горизонтальной, жалкое подобие duck typing) с сохранением удобства использования.
IB>Как это никаких? Как раз специально, для самых ленивых придумали специальную плюшку, позволяющую выносить методы их класса в абстрактные хелперы. Именно для этого, и ни для чего другого. Это именно тот подход, который я отстаиваю... IB>Ты бы разобрался в вопросе предварительно, прежде чем клеймить..
А вот и то самое "ниже", которое я дважды обещал. Вот пример, наглядный. Есть методы A и B у класса C. A требует доступа к приватной перменной _x, B не требует.
class С
{
private int _x;
public void A()
{
// use _x
}
public void B()
{
}
}
Это плохо. Что ты предлагаешь сделать? Ты предлагаешь сделать так
class С
{
private int _x;
public void A()
{
// use _x
}
}
class СHelper
{
public static void B(C c)
{
}
}
или даже так
class С
{
private int _x;
public void A()
{
// use _x
}
}
class СHelper
{
public static void B(this C c)
{
}
}
при этом самое очевидное решение, ты почему то в упор не видишь
class СBase
{
private int _x;
public void A()
{
// use _x
}
}
class С : CBase
{
public void B()
{
}
}
Это решение было всегда, и в C#, и в Си++ и в Object Pascal.
Оставляю тебе на домашнее задание разобраться зачем на самом деле были введены extension methods. Ну или просто прочти это сообщение внимательно, я уже написал
Здравствуйте, Ziaw, Вы писали:
Z>Однозначно оставить.
Z>Стоимость поддержки широкоиспользуемой библиотеки делится на все проекты ее использующие.
А стоимость ошибки в реализации?
Z>Да и заявления о повыешнии этой самой стоимости достаточно гиперболизированы.
А заявления об ужасах поиска нужного метода — нет?
Z> Я не хочу разбирать код джуниоров которые вместо одного незнакомого хелпера наделали макарон из знакомых им.
Ищите внятных джуниоров.
Z>Я хочу видеть все методы на одной странице хелпа.
Правильно. На одной странице хелпа к нужному сервису.
Здравствуйте, adontz, Вы писали:
A>Более конкретного ответа я и не ожидал
А более конкретного ответа в отсутствие реальных требований предоставить и не возможно. Мне это напоминает собеседование в одной очень известной конторе — когда предлагали спроектировать какое нибудь простенькое приложение, не уточняя масштабов проекта, требований к расширяемости, предполагаемой длительности жизненного цикла etc.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, samius, Вы писали:
S>Что лично я думаю о правиле, предложенном IB: вижу я довольно хороший момент в нем: методы, находящиеся внутри класса нуждаются в дополнительном анализе при принятии решения выноса их из класса при рефакторинге. В то время, очевидно, что метод, находящийся снаружи (в хелпере) может быть подвергнут переносу в другой класс без дополнительного анализа. Под дополнительным анализом подразумеваю анализ возможности использования лишь публичного контракта. Внутренние методы не тяготеют к использованию только публичного контракта. S>Итого, с оговоркой на перспективу развития — это правило мне нравится. Но я не склонен выносить методы в хелперы при первой возможности. ))
Это частный случай вашего правила доведенный до абсурда. Рома же говорил не только об этом.
IB>Мотивируя тем, что по каким-то причинам нам пришлось поместить один метод в класс, Рома призывает запихнуть в этот же класс и все остальные похожие методы, превратив его в большую помойку.
Вы же считаете, что похожие методы должны быть в разных местах. Ага. А потом будут соревнования по скростному поиску методов так как:
Метод LeftSubstring() может быть в строке, а метод RightSubstring() в хелпере
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, samius, Вы писали:
IB>1. При добавлении нового функционала не модифицируем существующий прямоугольник, а добавляем новый хелпер/сервис с новым функционалом, что очевидно лучше.
Судя по флейму не так уж очевидно.
IB>2. Все побочные эффекты изменения реализаций контролирует компилятор.
Может стоит ввести в язык новый модификатор метода который имеет доступ только к публичным членам?
IB>3. Можно передать наш прямоугольник через слои приложения или вообще запулить наружу через веб-сервис, не боясь IB> неправильного вызова метода или того, что на другой стороне этого метода просто не окажется.
Со всеми инжектнутыми сервисами внутри.
IB>4. Проще тестировать методы, вместо прямоугольника можно спокойно подпихнуть mock.
Что мешает мокать при вызове собственных методов?
Здравствуйте, adontz, Вы писали:
A>Видимо передёргиваешься всё же ты, пытаясь прикрыться людьми, которые вовсе не хотят, чтобы ты ими прикрывался. Неужели так мало осталось соратников? Неужто раскрыта ложность твоих идеалов и все разбежались?
Понятно, аргументы по делу кончились, я так и думал..
Не на долго же тебя в этот раз хватило..
A>А тебе никто не приведёт пример, когда правило не получается применить.
Конечно, его же нет..
A>Нельзя уползти от предметной области, от деталей реализации можно и нужно уползать.
Засчет сваливания всего в одну кучу? Отличный способ.
A>Правильный и красивый дизайн библиотеки подразумевает в первую очередь удобство использования, а не лёгкость поддержки.
Весьма спорный тезис. Если удобству использования приносится в жертву надежность, то нафиг-нафиг такую библиотеку.
A>Поднять?! Переверни шкалу отсчёта, ты её неправильно держишь
Родной — это ты шкалу ввел, забыл уже? =) Как-то ты быстро свою позицию меняешь..
A> Во-вторых, сферические кони в вакууме интересуют только абстракционистов-теоретиков, а у реальных людей всегда есть частные варианты с которыми тоже надо что делать. Причём на совесть, а не прикрываться правилами.
Да и "реальные люди", навалили в класс кучу методов не разбираясь, зато никаких правил исключительно здравым смыслом руководствовались! =)
Отличный результат.. )
A> С чего это она начнёт считать неправильно?
С того что код получился менее надежный и в нем легче ошибиться при модификации.
A>Что за нелепый, абсурдный аргумент?
Если он тебе не нравится — это не значит что он не лепый и абсурдный..
A>Мне как пользователю хелпер не удобен по определению.
Придется переучиваться..
A>Удобство поддержки при написании библиотеки не является более приоритетным, чем качественный внешний интерфейс. На кой ляд хорошо поддерживаемая бюиблиотека, если ей неудобно пользоваться?
На такой, что она более надежна.
A>Методы расширения для другой цели, я напишу об этом ниже.
=)
A>Ты действительно думаешь что твой или ещё какой-то рейтинг чем-то принципиально осмысленнее чем LOC/day и его область применения не узка?
Ты что этим сказать-то хотел?
A>Средство расширения существующей иерархии классов (построения параллельной, горизонтальной, жалкое подобие duck typing) с сохранением удобства использования.
Да, и для этого хелперы тоже можно использовать..
A>А вот и то самое "ниже", которое я дважды обещал. Вот пример, наглядный. Есть методы A и B у класса C. A требует доступа к приватной перменной _x, B не требует.
<...> A>Это решение было всегда, и в C#, и в Си++ и в Object Pascal.
Потому что наследование катастрофически увеличивает связность. При нормальном дизайне случаи использования наседования можно по пальцам пересчитать. Агрегация в большинстве случаев намного предпочтительнее.
A>Оставляю тебе на домашнее задание разобраться зачем на самом деле были введены extension methods.
Сначала разберись, чем плохо наследование..
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Ziaw, Вы писали:
Z>>Однозначно оставить. IB>
Z>>Стоимость поддержки широкоиспользуемой библиотеки делится на все проекты ее использующие. IB>А стоимость ошибки в реализации?
Умножается. Только не верю я в вынос методов как в эффективную меру борьбы с ошибками реализации.
Тестирования, ревью кода, скил программистов решают эту проблему гораздо эффективнее.
Z>>Да и заявления о повыешнии этой самой стоимости достаточно гиперболизированы. IB>А заявления об ужасах поиска нужного метода — нет? Z>> Я не хочу разбирать код джуниоров которые вместо одного незнакомого хелпера наделали макарон из знакомых им. IB>Ищите внятных джуниоров.
Ужасов не будет если специалист узконаправлен и наизусть знает данную библиотеку. Если вдруг понадобилось быстро разобраться — ничуть не гиперболизированы. Порог вхождения не менее важный фактор для библиотеки чем стоимость ее поддержки.
Z>>Я хочу видеть все методы на одной странице хелпа. IB>Правильно. На одной странице хелпа к нужному сервису.
Насколько я понял мысль — сервисов планируется не один.
Здравствуйте, minorlogic, Вы писали:
M>Если ссылка еще не пробегала.
Перевод там, конечно ...
Цитаты по теме:
Мы теперь видим, что приемлемый способом оценки инкапсуляции является количество функций, которые могли бы быть разрушены, если изменяется реализация класса. В этом случае становится ясно, что класс с n методами более инкапсулирован, чем класс с n+1 методами. И это наблюдение поясняет мое предпочтение в выборе функций, не являющихся ни друзьями, ни методами: если функция f может быть выполнена как метод или как функция, не являющаяся другом, то создание ее в виде метода уменьшило бы инкапсуляцию, тогда как создание ее в виде "недруга" инкапсуляцию не уменьшит. Так как функциональность здесь не обсуждается (функциональные возможности f доступны классам клиентов независимо от того, где эта f размещена), мы естественно предпочитаем более инкапсулированный проект.
...
Если Вы самокритичны и честны сами с собой, вы увидите, что имеете эту предполагаемую несогласованность со всеми нетривиальными классами, Вы используете ее потому, что класс не может имеет любую функцию, которую пожелает како-то клиент. Каждый клиент добавляет, по крайней мере, несколько своих функций для собственного удобства, и эти функции всегда не являются методами классов. Программисты на C++ используют это, и они не думают ничего о этом. Некоторые вызовы используют синтаксис методов, а некоторые синтаксис внешних вызовов. Клиенты только ищут, какой из синтаксисов является соответствующим для тех функций, которые они хотят вызвать, затем они вызывают их. Жизнь продолжается. (это по поводу Роминых StringLeft и StringRight)
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, adontz, Вы писали:
A>Не надо вестись на провокации Бодягина, есть третий путь
К слову, самый худший из всех предложенных..
"Нафига нам враги когда у нас есть такие друзья" (с) =)))
Здравствуйте, Ziaw, Вы писали:
Z>Судя по флейму не так уж очевидно.
???
Я этот аргумент выдвигал раз пять. Каждый раз его молча игнорировали, отсюда делаем вывод, что возразить нечего.
Z>Может стоит ввести в язык новый модификатор метода который имеет доступ только к публичным членам?
Возможно, но я бы предпочел методы расширения в экземплярных классах...
Z>Со всеми инжектнутыми сервисами внутри.
Зачем? Наоборот это голый объект, который можно передать в любой сервис умеющий с ним работать.
Z>Что мешает мокать при вызове собственных методов?
Методы придется тестировать вместе с классом, а так можно по отдельности.
Я против введения базового класса без необходимости в полиморфизме а только лишь для группировки методов и контроля компилятором соблюдения публичного контракта. Это может привести потребителя к лишней неоднозначности. Для этой цели лучше уж хелпер.
Мы уже победили, просто это еще не так заметно...
