Здравствуйте, C...R...a...S...H, Вы писали:

CRA>Есть обратный пример:
CRA>System.Convert
CRA>Ведь не сделали так:

CRA>"1".ToInt32()

Именно что сделали, между прочим: класс String реализует IConvertible Interface, просто реализация сделана явной (implicit interface implementation), для того, что бы не смущать неискушённый программеров обилием методов.

Здравствуйте, IB, Вы писали:

S>>сумму ордера конечно же надо хранить.
IB>С точки зрения здравного смысла, надо хранить не сумму (алгоритм рассчета которой так же может поменяться), а ставку налога на момент формирования заказа. Впрочем, для финансов, наверное, и сумму тоже имеет смысл хранить.
Не, с точки зрения здравого смысла, хранить нужно именно сумму. Потому что в способе ее подсчета могло измениться всё что угодно — и НДС, и правила округления, и политика скидок, и прочее.
Хранить все компоненты формулы конечно тоже можно, но вот как раз это здравому смыслу противоречит.

Здравствуйте, stump, Вы писали:

S>Просто в твоем ответе сквозит такая уверенность в существовании "правильной архитектуры". Слово "правильная" к архитектуре и дизайну софта вообще не применимо (ИМХО).
Совершенно верно. Зато очень часто к архитектуре и дизайну применимо слово "неправильная". Чем и воспользовался AVK.

Здравствуйте, adontz, Вы писали:

A>Иван, у тебя получается достаточно странная логика. С одной стороны высокоуровневые рассуждения о связности (я их не опровергаю, даже за) о том как важно разделять и властвовать, с другой стороны, когда речь дошла до практики, вдруг начинаются прыжки в сторону на тему "для эффективной реализации, метод должен быть членом класса".
A>У тебя получается некоторый String с методами, которые остались внутри просто потому что их нельзя выдернуть не просадив производительность (абсолютно нелепая выйдет компания) и помойка для всех остальных методов в хелпере. Мне это совсем не видится светлым будущим и, думаю, надо, всё же, чётко разделить теорию и практику. Раскидать методы по N классам достигнув абстрактной крутости и создав абсолютно нелогичный API не представляет мне достойной целью.
Светлое будущее — в том, чтобы abstraction penalty не было. В теории это иногда возможно: например, грамотный инлайнинг методов публичного контракта внутрь хелперного метода позволит применить жесткие оптимизации и добиться производительности, сравнимой с "внутренней" реализацией того же метода.

Тем не менее, мы живем в настоящем, а не в будущем. Поэтому приходится принимать компромиссные решения. В частности, жертвовать maintainbility для получения performance. Прикол в том, что если с самого начала заниматься performance, то потом улучшать maintainability очень дорого — потому, что собственно maintainability и определяет легкость изменения кода. Поэтому IB и AVK настаивают на последовательном проведении в жизнь правильного дизайна, и на обосновании каждого отступления от него в своих решениях.

Здравствуйте, MozgC, Вы писали:

MC>Я попросил показать реальный пример про String раз вы утверждаете что он реализован неправильно и эти функции надо было вынести в отдельные классы.
Реальный пример: попробуй реализовать свою версию String по образцу Haskell-овских строк (хранение списка линейных фрагментов вместо одного символьного массива).
Вот тут-то тебя не обрадует то, что от строки требуется что-то большее, чем IEnumerable<Char>.

Здравствуйте, Sinclair, Вы писали:

S>Светлое будущее — в том, чтобы abstraction penalty не было.

Не было для кого? Для разработчика библиотеки или для пользователя?

S>Тем не менее, мы живем в настоящем, а не в будущем. Поэтому приходится принимать компромиссные решения. В частности, жертвовать maintainbility для получения performance.

Жертвовать maintainbility кода библиотеки или кода используещего библиотеку? Который важнее?

Здравствуйте, adontz, Вы писали:

A>Не было для кого? Для разработчика библиотеки или для пользователя?
Для программы. Ты знаешь, что такое abstraction penalty? Это как раз то, на что ссылаются джедаи, которые говорят: "да я разверну этот цикл на ассемблере так, что все языки без ассемблерных вставок сдохнут от зависти".
Так что твой вопрос не имеет смысла.
S>>Тем не менее, мы живем в настоящем, а не в будущем. Поэтому приходится принимать компромиссные решения. В частности, жертвовать maintainbility для получения performance.
A>Жертвовать maintainbility кода библиотеки или кода используещего библиотеку? Который важнее?
Приходится жертвовать и там и там. В принципе, конечно же клиентский код важнее — его тупо больше.