Здравствуйте, Aikin, Вы писали:
CRA>>НО заказ не может содержать метод расчета Total, так как это уже совершенно другая ответственность. A>Не может, но может сам инициировать пересчет, т.е. фактически содержать метод расчета (но не алгоритм).
Вы сейчас говорите об IoC, ничего в этом страшного не вижу, это стандартная практика:
public class Order
{
public Order(IOrderCalculator orderCalculator){}
public decimal GetTotal()
{
return orderCalculator.GetTotalFor(this);
}
}
Но хочу еще раз подчеркнуть, ответсвенность за расчет лежит на классе orderCalculator.
Здравствуйте, Aikin, Вы писали:
A>>Не может, но может сам инициировать пересчет, т.е. фактически содержать метод расчета (но не алгоритм). A>Т.е. юзер класса может даже не знать, что для подсчета Total используется некий другой класс, а не сам Order.
А как вы думали работает шаблон State
A>>Не может, но может сам инициировать пересчет, т.е. фактически содержать метод расчета (но не алгоритм). CRA>Вы сейчас говорите об IoC, ничего в этом страшного не вижу, это стандартная практика:
Я сейчас говорю про "Куда девать ф-ции [внешние] для класса". А точнее про то, что вы решили задачу, но это другая задача: "Куда девать алгоритм, внешний для класса".
A>Не может, но может сам инициировать пересчет, т.е. фактически содержать метод расчета (но не алгоритм).
Т.е. юзер класса может даже не знать, что для подсчета Total используется некий другой класс, а не сам Order.
P.S. Кроме того эта же задача может быть решена без IoC CRA>
CRA>public class Order
CRA>{
CRA> public decimal GetTotal()
CRA> {
CRA> returnOrderCalculatorHelper.GetTotalFor(this);
CRA> }
CRA>}
CRA>
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Ага, Вы писали:
Z>Вы занимаетесь непонятной демагогией.
Z>stump привел пример предметной области: Re[9]: Куда девать ф-ции внешние для класса
, то GetTotal вполне может быть стратегией возвращающей Total, а Order может и не содержать свойство Total (в случае, если оно легко вычисляется, нет смысла его кешировать/обнавлять и т.д).
Подойдет в качестве мнения о предмете спора?
Z>Вы усложнили условия задачи:
хъ
Условия всегда меняются. А внешние для класса функции, которые находятся в классе обычно препятсвуют расширению функциональности.
A>>>Не может, но может сам инициировать пересчет, т.е. фактически содержать метод расчета (но не алгоритм). A>>Т.е. юзер класса может даже не знать, что для подсчета Total используется некий другой класс, а не сам Order. CRA>А как вы думали работает шаблон State
Ну, ... типа, ... ты ему опа, а он того... ит... считает
.
А Стэейт никакого отношения к вопросу не имеет, нету тут его и никаким клеем не приклеешь. Максимум Стратегию (а не IoC), да и то о ней клиент будет знать.
Здравствуйте, C...R...a...S...H, Вы писали:
CRA>Здравствуйте, Aikin, Вы писали:
CRA>>>НО заказ не может содержать метод расчета Total, так как это уже совершенно другая ответственность. A>>Не может, но может сам инициировать пересчет, т.е. фактически содержать метод расчета (но не алгоритм). CRA>Вы сейчас говорите об IoC, ничего в этом страшного не вижу, это стандартная практика:
CRA>
CRA>public class Order
CRA>{
CRA> public Order(IOrderCalculator orderCalculator){}
CRA> public decimal GetTotal()
CRA> {
CRA> return orderCalculator.GetTotalFor(this);
CRA> }
CRA>}
CRA>
CRA>Но хочу еще раз подчеркнуть, ответсвенность за расчет лежит на классе orderCalculator.
Мне кажется в этом случае IOrderCalculator правильнее инжектить в методе GetTotal(), а заранее передавать его в конструкторе может быть лишним.
MC>Мне кажется в этом случае IOrderCalculator правильнее инжектить в методе GetTotal(), а заранее передавать его в конструкторе может быть лишним.
Не. В GetTotal() плохо.
Так как если пользователь которому нужен Total знает про нужную реализацию IOrderCalculator, то зачем ему метод GetTotal()?
A>Я сейчас говорю про "Куда девать ф-ции [внешние] для класса". А точнее про то, что вы решили задачу, но это другая задача: "Куда девать алгоритм, внешний для класса".
Серьезно?
Вот смотрите:
public class Order
{
public IList<OrederLine> OrderLines {get;set;}
public decimal Total{get;set;}
}
public class OrderTotalCalculator
{
public decimal GetTotalFor(Order order){} //AndrewVK ;)
}
A>
A>>Не может, но может сам инициировать пересчет, т.е. фактически содержать метод расчета (но не алгоритм).
A>Т.е. юзер класса может даже не знать, что для подсчета Total используется некий другой класс, а не сам Order.
Вы путаете понятия:
1:
public class Order
{
public IList<OrederLine> OrderLines {get;set;}
public decimal CalcTotalForAllLines(){}
}
2:
public class Order
{
public IList<OrederLine> OrderLines {get;set;}
public decimal Total{get;set;}
}
В 1 случае, для класс Order сущестыует 2 ответственности:
1) Хранение заказа (строк заказа, заказчика и т.д.)
2) Выполнение операций расчета (будь то сумма по заказам, сумма НДС по строкам, сумма чистой прибыли по заказу и т.д.)
А вот во 2-м случае, только ответственность за хранение аттрибутов заказа.
A>P.S. Кроме того эта же задача может быть решена без IoC
Решение, которое тоже может быть правильным в определенном контексте, с этим не поспоришь
Здравствуйте, C...R...a...S...H, Вы писали:
CRA>Но, возможно вы могли упустить из вида, одно маленькое требование в одном из контекстов, которое звучит так: CRA>Клиент не имеет право изменять Total напрямую, а может использовать только специально предоставленные ему механизмы.
Это пожалуйста. Только Calc все равно должен быть отдельно и ничего не менять.
CRA>Пытаетесь уменьшить значимость сказанных мною слов, приравнивая их к совершенно другому понятию.
Попробуй перечитать что я пишу. Я ничего не пытаюсь преуменьшить.
CRA>ответственность есть ответственность, присвоение значения свойству – есть то как эта ответственность реализуется в коде.
Еще раз — есть две задачи: вычислить значение и изменить состояние персистентного объекта. Это разные задачи, объединение их в одном флаконе есть классическое нарушение SRP. Как следствие — та же невозможность просто посчитать значение, не меняя состояния. Совершенно классическая ситуация, какое тут еще тебе контекст нужен?
CRA>Применять SRP на уровне метода — это очень и очень проблематично, так как можно скатиться до применения SRP для каждого оператора
Бессмысленно. У тебя обвязка будет больше самого кода. Я всегда говорю одно и то же — от включения головы никакие принципы не спасают.
CRA>, так что считаю обсуждение SRP для каждого метода бредовой идеей, и вы я думаю со мой согласитесь
Вот сам утверждаешь что контекст нужен, и тут же без какого либо контекста заявляешь что SRP при делении на методы это бредовая идея. Нет, не соглашусь. Перегруженный функционалом метод ничем не лучше перегруженного функционалом класса.
CRA>Видимо вы додумали задачу, до конца сделав все возможные предположения за меня
За тебя? Исходную задачу разве ты приводил?
CRA>. Я же пытаюсь сообщить вам, что конкретные необходимости не известны даже мне
Ну да, очень удобно — додумываем и меняем по ходу дела задачу так, чтобы оказаться правым.
CRA>Я хочу обратить внимание, на один факт: Вы сделали предположение о том, что у меня написано в методе UpdateTotal
ННичего я не делал. Я просто не уклоняюсь от исходной темы топика — там самая суть где вычисление должно быть. Так что, если у тебя там внутри хитрая структура, то тогда зря ты это все сюда написал.
CRA>Вы посчитали что в моем объекте нет метод Calc, я вам хочу сообщить, так как пример мой
Я об этом чуть выше писал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
CRA>>public class Order
CRA>>{
CRA>> public Order(IOrderCalculator orderCalculator){}
CRA>> public decimal GetTotal()
CRA>> {
CRA>> return orderCalculator.GetTotalFor(this);
CRA>> }
CRA>>}
CRA>>
CRA>>Но хочу еще раз подчеркнуть, ответсвенность за расчет лежит на классе orderCalculator.
MC>Мне кажется в этом случае IOrderCalculator правильнее инжектить в методе GetTotal(), а заранее передавать его в конструкторе может быть лишним.
Тоже можно использовать в ряде случаем, как говориться сколько людей, столько и мнений
Здравствуйте, stump, Вы писали:
S>Как раз есть, это очень плохо.
Чем именно?
S> Полхо так же то что ты не можешь этого понят, зациклившись на ничем не подкрепленных правилах.
Мои правила подкреплены практикой, метриками студии, формальным определением связности и тем самым здравым смыслом, на который ты ссылаешься.
S>Class coupling сильно влияет на простоту поддержки.
Не сильно.
S> Цитата из MSDN : S>
S> Rule Description
S>This rule measures class coupling by counting the number of unique type references that a type or method contains.
S>Types and methods with a high degree of class coupling can be difficult to maintain. It is a good practice to have types and methods that exhibit low coupling and high cohesion.
S>Избегайте чрезмерной связанности классов!
Отлично. Теперь давай попробуем внимательно прочитать о чем тут речь.
Во первых, class Coupling — это не связность. Это именно связность между классами, а связность — это то, что я цитировал из википедии.
Далее, речь тут не о тупом и произвольном числе связей между классами, а о количестве связий, которые возникают когда один класс использует несколько других. То есть, к нашему случаю никак не относится. Советуют избегать именно такого сценария и ограничивать количество других классов, которые использует данный класс.
S>Высокая связанность классов (high degree of class coupling — подчаркиваю) делает затруднительной поддержку.
Ясен байт. только именно degree, а не точное число.
S>Так вот, использование "четкого принципа": "методы которые работают через публичный контракт класса должны быть вынесены за пределы этого класса", неизбежно и автоматически ведет к повышению class coupling и уменьшению кохессии.
Фантастика! Связь есть. Понимаешь, она физически есть, я не знаю как еще эту мысль до тебя донести.
Эта связь есть всегда, вне зависимости от того, где находится метод. Как только ты вынес метод наружу, эта связь стала учитываться. И это хорошо. Но от того, что эта связь не учитывается если помещен внутрь класса, она никуда не исчезает.
Про "уменьшение кохессии" мы поговорим ниже.
S>Оказывается имеет, прямое отношение см. выше.
Нет не имеет, см выше.
S>Мы обсуждаем конкретные метрики конкретного кода, давай не будем "заводить рака за угол".
Аргументы не нравятся? Сценарий тот же самый, DI переводит неявную связь, никак не учитываемую метрикой Class Coupling, в явную, которую студия с удовольствием считает. Повторяю тот же вопрос — DI увеличивает связность?
S>Проблема в том что ты не можешь понять основных принципов анализа метрик кода, и меня это удивляет.
Точно я?
S>Их надо оценивать интегрально.
Интегрально — это сравнивать одни единицы измерения с другими?
S> В данном случае метрики показали что введение хелпера практически ни на что не повлияло (не повлияло и на Maintainability Index)
Прости, у тебя созрением все в порядке? =)
S>Можно провести дальнейший анализ, а почему Maintainability Index остался на месте
Лучше проведи дальнейший анализ, почему Maintainability Index уменьшился, несмотря на "катастрофическое" увеличение счетчика связей между классами.
S>Но. пример показал тенденцию. И ты этого не хочешь замечать, видимо по тому что эта тенденция тебе не нравится.
Я не хочу замечать тенденцию?! Да ты здесь вообще прямой подтасовкой цифр занимаешься.
S>Даже если онии хорошие, излишнее количество этих связей рано или поздно начнет создавать проблемы.
Я предпочту разбираться с проблемами явных связей, чем неявных зависимостей. И не только я, к слову, студия придерживается того же мнения.
S>Ага теперь про твои любимые "неявные связи". Вся прогрессивная общественность называет это кохессией (зацеплением).
Вся прогрессивная общественность называет это "связностью" (Coupling), прочитай еще раз внимательно википедию, особенно раздел про типы связности. Именно это называется связностью. Связность — физическая характеристика, при желании ее можно посчитать. (Чем, к слову, изанимается студия, считая maintainability index)
S>
S>Cohesion is a measure of how strongly-related or focused the responsibilities of a single class are. In object-oriented programming, if the methods that serve the given class tend to be similar in many aspects the class is said to have high cohesion. In a highly-cohesive system, code readability and the likelihood of reuse is increased, while complexity is kept manageable.
Твоя же любимая кохессия — это чисто логическая, умозрительная характеристика, "вот мне кажется, что у этого класса такая-то ответственность...", никакими метриками ты это не померяешь.
S>Сужествуют различные типы кохессии. Рассматриваемый нами тип (метод использует данные класса) можно отнести к комуникативной и частично функциональной кохессии S>
S>Communicational cohesion
S>Communicational cohesion is when parts of a module are grouped because they operate on the same data (e.g. a module which operates on the same record of information).
S>Functional cohesion (best)
S>Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module (e.g. parsing XML in the case of Expat (XML)).
S>...
S>communicational and sequential cohesion are very good; and functional cohesion is superior.
S>(все цитаты из википедии)
Отлично. Теперь я беру все методы типа foo(), которые работают с A через публичный контракт, выношу их в отдельный класс и, для пущей красоты, обучаю их работать с интерфейсом IA. В итоге получаю отличнейший пример функциональной кохессии — superior!
ЧТД.
S>Т.е. размещение методов котоорые оперируют данными класса внутри самого класса имеет смысл и может дать положительный эффект.
Угу, только вынос всех методов в отдельный класс и группировка по функциональному принципу, за что я ратую, даст гораздо более глубокий положительный эффект.
S>Очень натянутые выводы, плохой анализ.
выводы очевидные, анализ отличный. Другое дело, что он тебе не нравится и ты изделие номер два, на глобус натягиваешь, но тут уж я ничего поделать не могу..
S> Любой видит, что с выносом методов в хелпер Maintainability index увеличился на 1% и за это заплачено значительным увеличением class coupling.
Только проблема в том, что Class Coupling косвенная характеристика, а Maintainability Index — итоговая, учитывающая, в том числе и Class Coupling. Учесть этот факт тебе видимо помешала врожденная способность к афигительному анализу..
S>Я не утверждаю, что есть "четкий принцип" — "если метод использует публичный контракт класса — он должен быть вынесен в другой класс."
А я утверждаю.
S>Я утверждаю, что есть оба принципа, и применительно к конкретным условиям может быть предпочтителен один или другой.
Раньше ты утверждал, что есть некий другой, не менее четкий принцип, который позволит однозначно определить — вносить метод в класс или нет. Но тайны так и не раскрыл.
S>А вот тупое (в смысле прямолинейное и бездумное) следование доному из них, ни к чему хорошему привести не может.
Я призываю к другому. Я призываю таки подумать и следовать тому принципу который я изложил.
Здравствуйте, adontz, Вы писали:
A>Иван, у тебя получается достаточно странная логика.
Логика у меня очень конкретная и последовательная.
A>вдруг начинаются прыжки в сторону на тему "для эффективной реализации, метод должен быть членом класса".
Это не "прыжек в сторону". Андрюша уже писал об этом, как, впрочем, и я. Принцип сформулирован очень четко. Если метод использует только публичный контракт для работы с классом, значит он должен находиться вне класса.
Уже использует, понимаешь? Это данность, его так задизайнили, не важно по каким причинам. Если по каким либо причинам методу нужно использовать приватные данные, не важно по каким, дизайн ли, производительность ли, еще что-то, то его место внутри.
Все очень четко, конкретно, понятно и прозрачно. В данном случае части методов, из соображений производительности, нужно иметь доступ к внутреннему состоянию, значит их место внутри класса.
A>У тебя получается некоторый String с методами, которые остались внутри просто потому что их нельзя выдернуть не просадив производительность (абсолютно нелепая выйдет компания) и помойка для всех остальных методов в хелпере.
С твоей точки зрения, общая помойка в одном классе лучше? Как раз классический пример "плохой кохессии" в терминологии stump-а. Не знаю, я по помойкам не специалист, я больше аккуратненькие клумбочки сервисов выращиваю..
Здравствуйте, MozgC, Вы писали:
MC>Нафига мне его как-то называть?
Ну, тебе же не нравится, что класс называется не string?
MC>И Причем тут экстраполировать, я тебе задал КОНКРЕТНЫЙ вопрос про КОНКРЕТНЫЕ проблемы с КОНКРЕТНЫМ классом.
Да не волнуйся так, я тебе очень конкретно ответил. Достаточно прочитать и немного подумать.
MC>Раз не можешь дать конкретный ответ,
Я тебе дал весьма конкретный ответ, с очень конкретным примером. Разница только в том, что класс не string называется, а проблемы ровно те же самые.
MC> Ты не способен адекватно и конкретно ответить на вопрос?
Боюсь, что ты просто не способен его задать..
A>Ну, ... типа, ... ты ему опа, а он того... ит... считает
No comments
A>А Стэейт никакого отношения к вопросу не имеет, нету тут его и никаким клеем не приклеешь.
Интересное заявление, как вам такое:
Изначально в требованиях к Order было:
В определенные дни заказы должны вести себя по разному:
в понедельник одно поведение,
во вторний другое,
во все остальные дни третье.
CRA>Вы путаете понятия:
Да действительно, прошу прощения.
Вот только не понятия, а неправильно прочитал исходное сообщение: Решил, что GetTotal лежит в самом классе.
Давайте вернемся и начнем сначала и исправим ошибку.
P.S. CRA>В 1 случае, для класс Order сущестыует 2 ответственности: CRA>1) Хранение заказа (строк заказа, заказчика и т.д.) CRA>2) Выполнение операций расчета (будь то сумма по заказам, сумма НДС по строкам, сумма чистой прибыли по заказу и т.д.)
Вы немного сгущаете краски в 2). Он не выполняет операции расчета, он знает кто может ему помочь их выполнить. В этом подходе не вижу ничего плохого
CRA>А вот во 2-м случае, только ответственность за хранение аттрибутов заказа.
Да, про анемичную модель мы слышали, но не прониклись Боюсь Order это не тот случай когда она хороша.
CRA>А вот Алгоритм расчета стоимости заказа, явно уже не отностится к отвественности абстракции "Заказ"
С этим тоже сложно поспорить, но: CRA>По этому получается такая вот загагулина:
В которой вы упустли несколько вариантов:
A>>А Стэйт никакого отношения к вопросу не имеет, нету тут его и никаким клеем не приклеешь. CRA>Интересное заявление, как вам такое: CRA>Изначально в требованиях к Order было: CRA>В определенные дни заказы должны вести себя по разному: CRA>в понедельник одно поведение, CRA>во вторний другое, CRA>во все остальные дни третье.
Ехххьььь, гори оно лесом: оффтоп, так оффтоп
Стэйт -- внутреннее состояние объекта, день недели -- состояние внешней среды!
От внешней среды может зависить Стратегия (подсчета чего-то там), но не внутреннее Состояние самого объекта.
Только из-за того что настал понедельник заказ не перейдет в состояние Заказан, вторник -- Оплачен, среда -- Отгружен, четверг -- Доставлен.
Здравствуйте, AndrewVK, Вы писали:
AVK>Это пожалуйста. Только Calc все равно должен быть отдельно и ничего не менять.
Ладно, пусть каждый останется при своем мнении
AVK>Попробуй перечитать что я пишу. Я ничего не пытаюсь преуменьшить.
Видимо ты этого даже не замечаешь
AVK>Еще раз — есть две задачи: вычислить значение и изменить состояние персистентного объекта. Это разные задачи, объединение их в одном флаконе есть классическое нарушение SRP. Как следствие — та же невозможность просто посчитать значение, не меняя состояния. Совершенно классическая ситуация, какое тут еще тебе контекст нужен?
Вы опять пытаетесь за меня написать метод UpdateTotal.
По вашим словам получается что клиет делающий так:
void Unknown()
{
decimal total = OrderHelper.CalaTotal(order); //получение значение
order.Total = total; //изменить состояние
}
Нарушает SRP, согласитесь это бред
AVK>Бессмысленно. У тебя обвязка будет больше самого кода. Я всегда говорю одно и то же — от включения головы никакие принципы не спасают.
О отлично, хоть в чем то мы согласны, а теперь посмотрите пожалуйста чуть выше
CRA>>, так что считаю обсуждение SRP для каждого метода бредовой идеей, и вы я думаю со мой согласитесь
AVK>Вот сам утверждаешь что контекст нужен, и тут же без какого либо контекста заявляешь что SRP при делении на методы это бредовая идея. Нет, не соглашусь. Перегруженный функционалом метод ничем не лучше перегруженного функционалом класса.
Длинну метода оставим на суд McConnell (Code Complete), но как бы Вы не хотели SRP для метода это жесть.
CRA>>Видимо вы додумали задачу, до конца сделав все возможные предположения за меня
AVK>За тебя? Исходную задачу разве ты приводил?
Вот именно, что не приводил, а вы попытались додумать, придумав то, что клиенту необходимы низкоуровневые операции по расчету Total, вы наверное будете говорить, что это не так, но вот вам цитата:
[23.07.08 18:43] К примеру, сумму может быть нужно рассчитать предварительно, без изменения персистентного класса.
AVK>Ну да, очень удобно — додумываем и меняем по ходу дела задачу так, чтобы оказаться правым.
Конечно, я додумываю задачу, так как я же ее точно не описал, а так как вы решили додумать ее за меня, мне же надо как то парировать (см. выше)
AVK>ННичего я не делал. Я просто не уклоняюсь от исходной темы топика — там самая суть где вычисление должно быть. Так что, если у тебя там внутри хитрая структура, то тогда зря ты это все сюда написал.
см. выше
AVK>Я об этом чуть выше писал.
см. выше
Здравствуйте, Aikin, Вы писали:
A>Да действительно, прошу прощения. A>Вот только не понятия, а неправильно прочитал исходное сообщение: Решил, что GetTotal лежит в самом классе. A>Давайте вернемся и начнем сначала и исправим ошибку.
Будем возвращаться потихоньку... A>P.S. A>Вы немного сгущаете краски в 2). Он не выполняет операции расчета, он знает кто может ему помочь их выполнить. В этом подходе не вижу ничего плохого
Стоп.
Если в даже в инетрфейста Order есть куча методов Calc*** — это это не гуд, даже если они используют state, strategy, etc.
CRA>>А вот во 2-м случае, только ответственность за хранение аттрибутов заказа. A>Да, про анемичную модель мы слышали, но не прониклись Боюсь Order это не тот случай когда она хороша.
На вкус и цвет...
Но посмотрите что может случиться:
public class Order
{
public IList<OrederLine> OrderLines {get;set;}
public decimal CalcTotalForAllLines(){}
public decimal CalcTotalForEvenLines(){}
public decimal CalcTotalForRandomLines(){}
}
Вот такая может получить Rich model и в конечном итоге придется все Calc*** методы куда-нить переносить
Здравствуйте, C...R...a...S...H, Вы писали:
AVK>>Попробуй перечитать что я пишу. Я ничего не пытаюсь преуменьшить. CRA>Видимо ты этого даже не замечаешь
Судя по оценкам — не только я.
CRA>Вы опять пытаетесь за меня написать метод UpdateTotal.
Я тебе попытаюсь пояснить ситуацию в последний раз. В контексте топика речь шла именно о методе вычисления, нигде в исходном примере никаких изменений не было. Глядя на твое решение, я логично предположил, что, если у тебя нигде собственно вычислений не заявленно, значит они внутри Update. Если же у тебя там целая инфраструктура — то весь твой пример идет в лес и обсуждать я его не хочу, потому что на обсуждаемый здесь вопрос он никак не отвечает, самое главное осталось за кадром.
CRA>Вот именно, что не приводил
. Я до сих пор речь веду о нем. Естественно, твои умопостроения, которые ты по ходу разговора додумываешь, я не учитывал. Но твоя позиция абсолютно неконструктивна — всегда ведь можно сказать, на любое утверждение, что оно неверно, потому что у нас за кадром целое стадо коров спрятано. А конструктивно — это когда говорится что, а, главное, почему надо делать.
CRA>, а вы попытались додумать
То есть ты признаешь, что ты написал сообение, которое заведомо не проясняет ситуацию с обсуждаемым здесь вопросом, так? Тогда зачем ты его написал?
AVK>>Ну да, очень удобно — додумываем и меняем по ходу дела задачу так, чтобы оказаться правым. CRA>Конечно, я додумываю задачу, так как я же ее точно не описал
давай тогда и я додумаю, а то несправедливо получается: исходная задача не твоя и не моя, ты додумываешь, а мне нельзя. А вдруг унутре Update так:
var total = order.GetTotal();
order.Total = total;
Поэтому давай не будем тут сочинять по ходу разговора, а просто демонстрировать максимально ясно и понятно ту мысль, которую хочется продемонстрировать, и тогда все у нас получится.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Мы уже победили, просто это еще не так заметно...
