Здравствуйте, SV., Вы писали:
SV.>Ну как же. Как он смел заниматься бухгалтерией без плана счетов, утвержденных Минфином РФ с его идентификаторами? Ладно, это была шутка. Не обращайте внимания.
Непонятная шутка. Минфин — ни при чём. Даже если это ваша личная бухгалтерия, с именами счетов "левый карман" и "правый карман", ничего не меняется.
SV.>Я имел в виду запись в отдельной таблице с указанием текущего справочника и вхождения в него.
Я вас по-прежнему не понимаю. Вы мыслите в терминах какого-то конкретного решения, а не в терминах задачи. При чём тут справочник? Справочник можно построить на ходу, просто сделав select distinct sourceAccount from transactions.
SV.>Один простой вопрос. Как вы в этой системе будете вести лицевые счета? Они не видны в отчете, но видны операционисту.
Точно так же.
Математика никак не меняется.
SV.>А я и не говорю про ООП. Я переключился на уникальные искусственные идентификаторы счета, которые (не) нужны.
Отлично. Я по прежнему не понимаю, для чего вам суррогатные ключи.
SV.>Вот опять мы говорим не про ООП. И опять я скажу, что тут шайбочкой не обойтись.
Беллетристика поскипана. Не имеет отношения к делу.
SV.>Что эти немного абстрактные рассуждения значат применительно к ООП и счетам? Я делаю утверждение, основанное на наблюдениях, а не на какой-то там мифической науке: никто не любит писать объектные модели, но все очень любят ими пользоваться, поскольку они снижают порог вхождения.
О, вот теперь мы подошли к сути. Наконец-то вы делаете хоть какое-то утверждение, которое можно обсуждать.
SV.>Я делаю второе утверждение — нет, и не может быть никакой науки, чтобы доказать или опровергнуть первое утверждение.
То есть мы резко перешли к религии. Порог, по-вашему, существует, но измерить его невозможно.
Простите, но на этом нам придётся дискуссию свернуть. Потому что иначе мне придётся в ответ заявить, что анемичные модели имеют по сравнению с объектными моделями значительно более высокую аладибобберность, которая крайне важна, но измерить её научным методом невозможно.
SV.>Нет, нет и еще раз нет. Реальная бухгалтерия обслуживает реальный бизнес.
Вы сейчас смешиваете бухгалтерский учёт и финансовый учёт. Это во-первых.
Во-вторых, финансовый учёт точно так же не работает ни с какими "обьектами", у которых бы было состояние и поведение.
SV.>Без эмоций, вполне спокойно, я заявляю:
Мнение по поводу нужности бухучёта отправлено в дев/нулл как нерелевантное к теме топика.
SV.>Опять же, причем тут Лука Пачоли. А чем они все эти века занимались, пока Госплан не выкатил план счетов, интересно?
Неужели отправляли сообщения объектам?
А, нет — записывали проводки в гроссбухи, и готовили отчёты.
SV.>У счета нет состояния. Он его эмулирует. Я, вроде, не скупился в словах, когда это описывал.
Отлично. То есть на самом деле объекта нет, есть некая эмуляция. "Состояние" объекта меняется не в результате взаимодействия с ним других объектов, а в результате действий, произошедших в какой-то посторонней части системы. Ок.
SV.>Это я сначала предложил CalcCurrentBalance(). А уже потом развил свою мысль до CalcBalance(Date forDate = Date.Now). Дорогу, тыскызыть, осиливает идущий. Но я не настаиваю, пусть будет CalcCurrentBalance() и CalcBalance(Date forDate). Это все равно несравненно лучше суммирования проводок везде, где нужен баланс.
Непонятно. Вы предлагаете суммировать проводки везде, где нужен баланс. Но при этом это почему-то лучше, чем суммировать проводки везде, где нужен баланс. По-моему, вы спорите с голосами в голове.
SV.>Откуда у Васи acc — как откуда? От AccountingService'а. Как он достукивается до сериса — это платформозависимые вещи. Если Вася пишет плагин (допустим, вебпарт), то и ссылку получает на входе. Если пишет standalone-страницу, просто обращается к сервису и получает у него интерфейс. Затем — что-то типа:
SV.>SV.>var acc = theService.GetAccountByReportIdentifier('78.01');
SV.>
О, отлично. То есть вы предлагаете Васе писать код вот так:
var acc = theService.GetAccountByReportIdentifier('78.01');
var balance = acc.CalcBalance();
Да?
И полагаете, что ему это понятнее и удобнее, чем делать всё в одну строчку:
var acc = theService.GetBalance('78.01');
?
Простите, такие смелые утверждения нужно как-то обосновывать.
SV.>Вася этот сидит у меня за спиной сейчас. Только зовут его Катя. Все взято с натуры.
SV.>Дальше, а почему Синклер тупеет? Цель была показать, что имплементация полна сюрпризов, а вы от них ограждены. Можете подставить СВ. Я люблю, когда ОМ скрывает от меня реализацию на первых порах и тупым себя по этой причине не считаю.
Если и считаю, то не по этой. Главное, чтобы она (ОМ) по мере "врубания" и роста хотелок не становилась гирей на ногах, как это случилось с ShP OM.
Рич-модель практически всегда становится рано или поздно гирей на ногах. Увы.
SV.>А вот ЭТО и будет нарушением SRP, о котором столько говорилось.
С чего бы это вдруг? Обоснуйте своё утверждение.
SV.>По сути, будет одна большая общая куча функций. Что-то типа WinAPI. Словами не передать, как я ненавижу изучать такие API.
С чего это вы взяли? Вы почему-то думаете, что если вы эту кучу функций засунете в класс Account и заставите порождать его экземпляры на каждый чих, то всё станет понятнее. Я не вижу никаких к этому причин.
Вот как я себе представляю "объектную" модель:
var acc1 = accountingService.GetAccount('78.01');
var acc2 = accountingService.GetAccount('62.03');
var transaction = accountingService.NewTransaction(acc1, acc2, amount);
accountingService.Commit();
Видим четыре объекта, четыре метода.
Вот как бы выглядела анемичная модель:
var result = accountingService.NewTransaction('78.01', '62.03', amount)
Один объект, один метод.
S>>Сколько разных реализаций вы себе представляете у класса Account?
SV.>Я привел пример с двумя реализациями: "реального" счета, то есть, счета, который пасется на базе, и агрегирующего счета, который агрегирует "реальные" счета по заданному признаку.
К сожалению, они не являются взаимозаменяемыми. Я не могу сделать перевод с агрегирующего счёта, не указав, какой "реальный" счёт мне нужен. То есть весь полиморфизм у вас — внутри CalcBalance, а точнее — внутри того метода, который выбирает проводки для суммирования. Ну так и выполняйте декомпозицию по этой границе.
Но это, подчеркиваю, не обязательно. Даже если у вас одна реализация, не надо свинячить и пихать в AccountingService everything and kitchen sink.
А что вы называете Everything? Простите, но API AccountingService будет практически 1:1 совпадать c API класса Account.
SV.>Про классиков я не знаю. Можете показать, что надо прочитать и соотнести — я прочитаю и соотнесу.
SV.>Запихать вообще всё в функцию main — НЕнормально, как раз потому, что ответственность нельзя описать словами "сделать всё". Сделать что? Декомпозируйте.
SV.>В реальности, вы же знаете, люди пишут код без комментов и переменные называют однобуквенными именами, чтоб с работы не выгнали. В подавляющем большинстве мест, я подозреваю. Какой тут ООП. Но если вы, допустим, архитектор и совладелец?
То я буду вводить только те объекты, которые обладают
поведением. У AccountingService поведение есть.
У Account — нету. Account — это всего лишь строчка '78.01'. Вся политика по поводу того, куда и что можно переводить, а куда нельзя, реализована снаружи Account. Это сегодня нельзя, а завтра — можно. И вообще можно всегда, вопрос только в том, будет ли результирующая отчётность устраивать ограничениям или нет.
SV.>Про сотни и тысячи я не понял. Да хоть миллионы. ООП же не роняет производительность сама по себе.
Вернитесь к тому месту в разговоре, где вы рассказывали про вашу борьбу с прямыми запросами к базе в ShP. Зачем вы это делали, если производительности чистого ООП самого по себе хватало?
