Здравствуйте, IB, Вы писали:
Z>>Косяк дизайна? IB>Весьма вероятно, я не краевед по Spring.Net
Для этого надо быть краеведом в спринге? Бог с ним, пусть я проектирую абстрактную библиотеку.
Если интерфейс ISet, несколько реализаций. Нужны методы AddAll, RemoveAll. Представляют из себя вызов Add/Remove в foreach по IEnumerable параметру. Куда мне их деть? Только пожалуйста без общих рекомендаций типа "куда угодно". Любое конкретное решение.
Z>>Так сложно написать несколько строк контрактов? IB>Что это тебе даст? Ты можешь написать их сам, если очень хочется.
Мне это даст понимание правильного с твоей точки зрения выноса. Если я напишу их сам никакого смысла в этом не будет.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
A>>Давай поставим вопрос ребром, зачем ты вообще решил увеличивать инкапуляцию? Ради упрощения поддержки? ЮЖ>Т.е. результативнее снизить количество необходимых изменений, а не улучшать их "удобство". Как минимум, уменьшается объем потенциально возможных ошибок, набор тестов, да и просто количество необходимого времени.
Верно, но не про нас. То где находится метод: в классе или хелпере, никак не влияет ни на возможность его тестировать, ни на возможность его поменять или добавить новый метод. Прсото взяли и для себя упорядочили. Подчёркиваю, для себя. Другим эта упорядоченность на фиг не упала.
ЮЖ>один класс должен иметь только одну причину для изменения.
Утверждение, которое можно трактовать как угодно.
ЮЖ>А вот снижение количества изменений, снижение количества потенциально возможных багов порожденных этими изменениями, снижение объемов тестирования, уменьшение времени, затраченного на эти изменения, увеличиние скорости реализации новых фич и т.п., — все это тоже в конечном итоге средства снижения стоимости и увеличения конкурентноспособности.
ОК, как вынос метода в хелпеер на это влияет? А? Не изменение архитектуры, а просто взяли и сделали второй класс и вытащили туда всё чему достаточно публичного контракта.
ЮЖ>Повторному использованию, имхо, очень часто мешают лишние ответственности.
Опять не в тему. Библиотека не стала делать больше или меньше, просто методы перераскидали по классам.
ЮЖ>А такой код(библиотечный) тем более должен стремится к применению SRP по максимуму. Если я хочу от библиотеки 'A', то она и должна мне предоставить 'A', а не ['A' + 'B' + на всякий случай 'C' для удобства] в одном флаконе. Это просто снижает повторное использование(вместе с окупаемостью).
Опять не в тему. Библиотека не стала делать больше или меньше, просто методы перераскидали по классам.
ЮЖ>Можно пойти еще дальше и оставить только два итератора, плюс сделать строку иммутабельной и добавить string builder.
И получить STL где у сттроки нет нормального find И каждый пишет свой. Не надо SRP доводить до маразма стимулирую написание велосипедов.
ЮЖ>Т.е. автокомплит, если я правильно понял всю ветку — это и есть удобство?
Конечно, автокомплит увеличивает производительность. Кто бы спорил.
Здравствуйте, IB, Вы писали:
A>>Ровно столько, сколько надо. IB>О, как ты быстро назад сдаешь.. ) А сколько надо? На глазок решишь?
А я не сдаю назад, я же говорю, тут только ты впадаешь в крайности. На глазок ли? Ну не наобум, но да, в каждом конкретном случае решение может приниматься индивидуально, на основе личного опыта. Жёстких правил нет, правила вссегоо лишь рекомендуют.
IB>Что может быть непривычного в конфигурационных файлах? )
Конфигурационные файлы определённого формата могут быть непривычны.
IB>Да и проблема с удобством решилась — привыкли и сразу стало удобно, этот аргумент, значит, тоже вычеркиваем..
Здравствуйте, AndrewVK, Вы писали:
A>>Я знаю, как минимум, два. AVK>Во, прекрасный пример использования не по делу.
Вот и я о том же, хелперы не панацея и нечего пихать в них всё что можно, прсото потому что можно.
Что это не по делу я знаю, я это как раз как пример использования "не по делу" привёл.
Здравствуйте, Ziaw, Вы писали:
Z> Любое конкретное решение.
Опять конкретные решения. Прошлый ничего не показал? Данное конкретное решение уже есть в фреймворке, если я правильно понял — это метод AddRange у класса List<T>. И оно должно быть внутри класса, потому что требует доступа к внутреннему массиву. Что же касается интерфейса IList<T>, то там такого метода нет. И если оно там понадобится — безусловно это будет статический хелпер, хотя бы потому что реализацию в интерфейс добавить не получится (в качестве примера метод Enumerable.Concat() из того же фреймворка).
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Данное конкретное решение уже есть в фреймворке
Еща раз. У меня стоит задача спроектировать библиотеку работы со множествами, есть требование обеспечить возможность добавлять в ISet множество IEnumerble<T> вызовом одного метода. Сам метод выглядит очень просто
public static AddAll<T>(ISet<T> set, IEnumerable<T> items)
{
foreach (T item in items)
set.Add(item);
}
Либо
public AddAll<T>(IEnumerable<T> items)
{
foreach (T item in items)
this.Add(item);
}
Какой мне предпочесть опираясь на OCP или другие соображения?
Здравствуйте, adontz, Вы писали:
A>Тем не менее безусловно пихали в хелперы всё что можно вытащить из основного класса.
Панацея, Рома, это согласно БСЭ:
1) у алхимиков лекарство, якобы исцеляющее от всех болезней, названное по имени древнегреческой богини Панакии (Panakeia — всеисцеляющая). 2) В переносном смысле (иронически) — средство, избавляющее от всех зол, для решения всех проблем.
Очевидно — от всех зол правило Мейерса не избавляет, всего лишь позволяет сделать еще один шажок на пути улучшения manageability исходного кода.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Панацея, Рома, это согласно БСЭ: AVK>
1) у алхимиков лекарство, якобы исцеляющее от всех болезней, названное по имени древнегреческой богини Панакии (Panakeia — всеисцеляющая). 2) В переносном смысле (иронически) — средство, избавляющее от всех зол, для решения всех проблем.
Спасибо за цитату, но зря. Она у меня есть бумажная, весь 31 том.
AVK>Очевидно — от всех зол правило Мейерса не избавляет, всего лишь позволяет сделать еще один шажок на пути улучшения manageability исходного кода.
ОК, зачем его использовать "на всякий случай", когда видимой выгоды нет?
Здравствуйте, adontz, Вы писали:
A>Спасибо за цитату, но зря. Она у меня есть бумажная, весь 31 том.
Я ж не тебе лично письмо пишу.
A>ОК, зачем его использовать "на всякий случай", когда видимой выгоды нет?
Что значит "на всякий случай" и "видимой выгоды нет"? Увеличение инкапсуляции и уменьшение связности — вполне конкретная выгода. А если у нас у класса есть еще публичный интерфейс — то и минимизация его размеров.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Увеличение инкапсуляции и уменьшение связности — вполне конкретная выгода.
Увеличение инкапсуляции и уменьшение связности это метод, а не результат.
AVK>А если у нас у класса есть еще публичный интерфейс — то и минимизация его размеров.
Самообман. Интерфейс не стал меньше, просто в нём стало больше классов.
Здравствуйте, adontz, Вы писали:
A>Увеличение инкапсуляции и уменьшение связности это метод, а не результат.
Конечный результат — увеличение manageability кода. Мы пошли по кругу.
AVK>>А если у нас у класса есть еще публичный интерфейс — то и минимизация его размеров.
A>Самообман. Интерфейс не стал меньше, просто в нём стало больше классов.
Два маленьких интерфейса — намного лучше одного большого.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Отлично, я быстренько все это пишу. Отдаю библиотеку все используют — все в восторге.
Однако через год обнаруживается, что в многопоточных приложениях ее использовать нельзя, т.к. отсутствует потокобезопасный тип множества.
И меня спрашивают,
— Использовал ли ты OPC в своей библиотеке?
— Ага (конечно же я помню ту замечательную дискуссию на рсдн где мы наконец пришли к консенсусу по поводу выноса методов).
— Ну так добавь быстренько SynchronizedSet
— Яволь.
Я сажусь за код и с ужасом понимаю, что мне приходится в методах AddAll/RemoveAll писать замечательные конструкции типа:
Ужас он не от того, что мне пришлось это сделать, а от того, что я понимаю, что еще пара вариантов реализации AddAll и мне придется признаться, что мой дизайн унылое г.
Здравствуйте, Ziaw, Вы писали:
Z>public static AddAll<T>(this ISet<T> set, IEnumerable<T> items) Z>{ Z> if (set is ISynchronizedSet)
Да уж. А сделать:
public static AddAll<T>(this ISynchronizedSet<T> set, IEnumerable<T> items)
Религия мешает?
Z>Ужас он не от того, что мне пришлось это сделать, а от того, что я понимаю, что еще пара вариантов реализации AddAll и мне придется признаться, что мой дизайн унылое г.
Неа, унылое гавно, это когда в уже существующих методах вдруг появляется блокировка. Ну а главное — тема сис... вынесения методов не раскрыта. Где здесь преимущество варианта, когда твои AddAll находятся в ISet?
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
