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

SV.>>С одной стороны она соответствует модели в голове у бухгалтера, поскольку основывается на проводках.
S>Не соответствует.

Это счет-то не соответствует результату операций по проводкам?

SV.>>С другой стороны, ее можно отдать, допустим, программисту гуёв, и он найдет в ней и .CalcCurrentBalance(), и что его душе угодно. Не проблема хранить пачку счетов (вектор, например), поскольку реальные инкапсулируемые данные в памяти малы.
SV.>>Вся эта штука называется объектная модель.
S>Вся эта штука называется "ошибка архитектуры".
S>У неё нет никаких преимуществ. То есть совсем никаких.

У нее есть одно большое преимущество — она интуитивно-понятна. Поэтому так строят реальные системы типа ShP OM. А других преимуществ — да, нет.

Есть и недостаток — ОМ чувствительна к дизайну. Кривые руки ее погубят. Поэтому, ШП ОМ — редкая гадость (когда я последний раз смотрел на их CAML, плакал горючими слезами — пакетные запросы адекватно представлены не были, пришлось плюнуть и переписать все на SQL).

S>Смотрите, в чём затык: для вывода баланса на экран придётся построить новый счёт и попросить данные у него:
S>

S>BalanceLabel.Text = (new Account("03")).CalcCurrentBalance().ToString();
S>

Нет, поскольку где ж вы возьмете идентификатор? Вообще, идентификатор сугубо служебен и снаружи вам не виден. Искать вы будете по внешним атрибутам счета, может быть, даже, в соответствии с правами доступа. Создаваться экземпляр будет фабрикой, внешний вид которой зависит от архитектуры. Разумеется, этот поисковый объект не будет исключительно фабрикой, и я никогда не соглашусь, что это нарушение SRP.

S>А что такое "Current"? Наверное, есть операция CalcBalanceForDate(Date targetDate), и есть важный инвариант CalcCurrentBalance() == CalcBalanceForDate(new Date()).

Да, хотел дописать почти теми же словами, но решил, что и так понятно. Это некий шорткат, который можно реализовать по-разному (хоть бы и дефолтным значением параметра).

>Этот инвариант верен для всех счетов; то есть, с точки зрения правильного дизайна надо его выносить наружу. Ок, CalcCurrentBalance мы отобрали.

Зрение бывает у дизайнера, а не у дизайна. Как и точка, откуда дизайнер зрит. Это так, к слову.

С какой точки зрите вы, я не знаю. Мой поинт в том, чтобы сложность разложить по полочкам. Поставьте себя на место гуёвого программиста, которому дела нет до идентификаторов и базы. Зато у него на входе есть счет, который сводит дебит с кредитом по запросу. И полученный таким образом результат можно запихать в форму и отдать операционисту.

S>Откуда он будет брать эти проводки? Из базы? Ну, тогда надо научить его общаться с базой, а это — прямое нарушение SRP. Придётся отпилить от него какую-то функциональность — либо по расчёту баланса, либо по работе с базой.

Это зависит от точки зрения дизайнера на responsibility. Если у вас есть дополнительные требования к работе с БД (допустим, поддержка в качестве БД чего угодно, в том числе NoSQL) — ну, введем посредника, который будет делать выборки и другие реляционные операции по чему ему скажут (а Account ему скажет — по проводкам). Если нет — ради бога, прячьте сиквел в реализацию, получите быстрособранную систему, которая жестко завяжется на структуру таблиц. И то, и другое будет понятной объектной моделью, но с разными достоинствами и недостатками в других областях.

S>Если оставить в нём работу с базой, тогда непонятно, почему в нём — почему нам не иметь класс DbManager с методами GetTransfers(Predicate where), кроме которого, в общем-то, ничего и не нужно?
S>Если оставить в нём работу с расчётом баланса, а проводки отдавать снаружи, то получается, что мы завели целый отдельный класс для примитивов типа
S>

S>Decimal static CalcBalanceForDate(Date date, allTransfers) 
S> return (from t in allTransfers where t.Date <= date select t.Amount).Sum();
S>

S>Зачем всё это делать, совершенно непонятно.

Как же это непонятно? Допустим, мы завязались на структуру таблиц. Тогда, во-первых, а где это хранить? В каком месте? "Там, где архитектурно правильно" — это общие слова. Где конкретно? Помните про гуёвого программиста, которому нужно состояние счета, атрибуты, балансы и больше ничего? Его вы озаботите знанием этого запроса, в том или ином виде?

S>Всё, что нужно, прекрасно получается безо всяких объектов Account.

Заглавное сообщение прочитайте еще раз. Всё, что нужно, прекрасно получается безо всяких объектов. Хоть на ассемблере. А вот если подумать о людях, которым с этим кодом работать...