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

SV.>>>>Нет, поскольку где ж вы возьмете идентификатор? Вообще, идентификатор сугубо служебен и снаружи вам не виден.
S>>>Как это "не виден"? Да он в плане счетов написан крупным шрифтом. То, что вы дали счёту какой-то внутренний служебный идентификатор — ваше личное решение; нужды в нём никакой нет.
SV.>>После таких слов Лука Пачоли в гробу перевернулся.
S>С чего бы это вдруг?

Ну как же. Как он смел заниматься бухгалтерией без плана счетов, утвержденных Минфином РФ с его идентификаторами? Ладно, это была шутка. Не обращайте внимания.

SV.>>Ваш план счетов — это один-единственный аспект, отчетный. А вы на основе его идентификаторов делаете уникальные ключи, хотя это всего лишь внешние атрибуты (и то, не факт, что прямые, очень может быть, что вычисляемые).
S>Не очень понятно, что значит "вычисляемые".

Я имел в виду запись в отдельной таблице с указанием текущего справочника и вхождения в него.

SV.>>Во-первых, план счетов — хронотопический стандарт, он действует на территории отдельного государства, и его средняя продолжительность жизни — пять лет. По уму, место его — в справочнике. Чтобы любое количество реальных счетов можно было отнести на счет из текущего плана, а исчезновение из плана идентификаторов не приводило к необходимости переоткрывать счета. Если подумать, из счета даже ссылаться на справочник текущего плана напрямую нельзя.
S>Совершенно верно. Именно поэтому идея представить счёт в виде объекта — порочна. Потому что все необходимости что-там "переоткрывать" связаны исключительно с представлением о счёте как о чём-то таком, у чего есть своё собственное поведение.
SV.>>Нужно делать промежуточную таблицу с историей ссылок.
S>Это ещё зачем? Такая таблица нужна только тогда, когда вы придаёте счёту идентичность. А у счёта её нет — вы только что сами написали об этом.
S>Если у вас в таблице проводок пишутся только идентификаторы счетов (в соответствии с той версией плана, которая актуальна на момент действия проводки), то никаких исторических таблиц делать не надо.

Один простой вопрос. Как вы в этой системе будете вести лицевые счета? Они не видны в отчете, но видны операционисту.

SV.>>Во-вторых, план счетов — внешний по отношению к организации стандарт. Есть ведь и другие аспекты помимо налогово-отчетных. В реальной организации на один внешний счет, включенный в отчет, может приходиться 10 внутренних, которые вообще в вышеупомянутом аспекте не видны.
S>Ну и что? Каким образом нам тут поможет ООП-шный объект "счёт"? То, что вы описываете, прекрасно реализуется на декларативном Екселе, не то что без ООП, а даже и без структурного программирования.

А я и не говорю про ООП. Я переключился на уникальные искусственные идентификаторы счета, которые (не) нужны.

SV.>>"Это" — это что? Сделать шорткат от Current'а на Date.Now?
S>Да.

SV.>>А почему не будем? Очень даже будем. Дизайн — он безответный, и, прикрываясь его интересами (которых у него нет), можно что угодно запроектировать. Вы ровно это и делаете. Берете произвольное решение, которое нравится вам ("надо его выносить наружу"), и пишете "с точки зрения правильного дизайна". Пойди поспорь. Или надо соглашаться, или начнется совершенно идиотский спор "какой дизайн трушнее". Который закончится взаимным посыланием нафиг и тем, что каждый останется при своем мнении.
S>Есть объективная реальность. Вообще дизайн — на удивление точная наука, даже если мы говорим о веб-дизайне или дизайне интерьеров. Всё в нём подчинено требованиям удобства сиреч эргономики.
S>А уж дизайн софта — и подавно. Есть совершенно объективные критерии того, какой дизайн лучше другого — это стоимость внесения изменений.
S>А рассуждения о субьективности критериев дизайна — это, простите, махровая гуманитарщина. То есть отказ от пользования логическим мыслительным аппаратом.

Вот опять мы говорим не про ООП. И опять я скажу, что тут шайбочкой не обойтись.

То, что прочитал, для меня звучит дико. В центре любого дизайна для меня стоит ЧЕЛОВЕК. Юзер. Покупатель и пользователь. С одной стороны дизайн продает. Если ЧЕЛОВЕКУ не нравится, он не купит. С другой — если вас этот покупатель интересует в будущем (он честно и регулярно платит), то даже после продажи надо обеспечить ЧЕЛОВЕКУ какое-то минимальное удовлетворение от покупки. Видите, сколько раз я сказал "ЧЕЛОВЕК"? А теперь вспомните, как "человечный" будет по латыни? Humanus. Да, представьте себе, это махровая гуманитарщина.

Теперь про логический аппарат. Аппарат вам не поможет, извините. Вся история IT — это история того, как тупорылый юзер похерил все достижения точных наук и чистого разума и купил себе айфон. Угадать ход его мысли логически? Ха-ха-ха. Вся наука сводится к тому, чтобы либо быть с ним в резонансе, как это делал Джобс, либо ориентироваться по другим продуктам, фокус-группам и так далее. То есть, изучать человека без фиги (точной науки) в кармане. Кто бы мог подумать, что главное в мобильной операционной системе — блестящие иконки. Это я такой умный задним умом, как все русские. Когда игра уже сыграна.

Что эти немного абстрактные рассуждения значат применительно к ООП и счетам? Я делаю утверждение, основанное на наблюдениях, а не на какой-то там мифической науке: никто не любит писать объектные модели, но все очень любят ими пользоваться, поскольку они снижают порог вхождения. Я делаю второе утверждение — нет, и не может быть никакой науки, чтобы доказать или опровергнуть первое утверждение. Максимум, что мы можем сделать — это провести опрос или посмотреть на эволюцию имеющихся программных систем. Мое третье утверждение — вам же самому будет лучше, если программисты по проекту под вашим началом смогут быстро в нем осваиваться. Экономически. Поскольку есть и такая точка зрения — мы привлекаем лучших специалистов, вот пусть они и нюхнут дерьмеца. Монстры-инженеры, как-никак. Лапшу там поразгребают, знание о проводках постаскают из модуля в модуль. Люди такие есть, но вы их сначала наймите, а потом окажется, что бросать их на бухгалтерию — как микроскопом гвозди забивать.

SV.>>Например, Васе поставили задачу — "построение таблицы [счет]-[текущий баланс]". Если вы опять напишете про своих теток, которые паразитируют на реальном труде, приводя сведения о реальном бизнесе в соотетствие с порождением советского Госплана (а откуда же еще высрались эти планы счетов?), которым такая таблица не нужна, не надо, пожалуйста.
S>Коллега, меньше эмоций. Бухгалтерию придумали вовсе не в СССР, и про тёток никто не писал. Если у Васи представления о счёте, как о баночке с деньгами — то это личные Васины проблемы. Точнее, это проблемы того, кто Васю нанял, потому что реальная бухгалтерия работает вовсе не так.
S>Реальная бухгалтерия — это, в первую очередь, механизм расчёта налогов. Без этого, грубо говоря, можно просто иметь одну баночку с деньгами, и просто брать из неё столько, сколько нужно.

Нет, нет и еще раз нет. Реальная бухгалтерия обслуживает реальный бизнес. А ему надо вести счета, основанные на проводках, не для того, чтобы рассчитывать долю государства, а для того, чтобы этим самым бизнесом оперировать. Я знаю, что говорю, поскольку имел такие заказы. Когда у вас сотня клиентов, у каждого свой мультивалютный счет, а у вас свои внутренние служебные счета, вы не можете оперировать баночкой. 95% времени вы осуществляете переводы в рамках своей финансовой деятельности, а к моменту подготовки налоговой отчетности у вас все эти пачки и пачки счетов суммируются и относятся на несколько позиций из плана. Люди заранее ПРОСИЛИ, чтобы все эти лицевые счета были отмаркированы в целях облегчения дальнейшего суммирования.

Без эмоций, вполне спокойно, я заявляю: то, что вы описываете, это паразитизм. Минфин в роли краба, который лицо закрывает, и личинка чужого в виде собственной бухгалтерии, которая грызет бизнес изнутри. Борьба с безработицей по-русски. Все понятно, но за пределами этих уродливых перекосов жизнь тоже есть.

Опять же, причем тут Лука Пачоли. А чем они все эти века занимались, пока Госплан не выкатил план счетов, интересно?

SV.>>Мир не крутится вокруг СССР. У других, знаете, тоже бывает бухгалтерия, в которой баланс счета — сумма проводок, а не состояние.
S>Совершенно верно. Вот только зачем вы хотите иметь именно счёт с состоянием вместо суммы проводок ?

У счета нет состояния. Он его эмулирует. Я, вроде, не скупился в словах, когда это описывал.

SV.>>Так вот, выше я предложил сделать шорткат на основе дефолтного параметра. Что вы изволили назвать плохим решением. Видимо, с точки зрения "Правильного Дизайна", который вы тут представляете на манер Лебедева. С точки зрения не Дизайна, а Васи, у него есть объект acc, у которого можно нажать точку и посмотреть, что будет. Вывалится список методов, среди которых не будет никакого CurrentBalance. А будет CalcBalance(Date forDate = Date.Now).
S>Нет, вы предлагали именно CalcCurrentBalance() — все ходы записаны. Далее, по вашим словам, мне совершенно непонятно, откуда это у Васи вдруг возьмётся объект acc, у которого можно нажать точку и посмотреть, что там выпадет.

Это я сначала предложил CalcCurrentBalance(). А уже потом развил свою мысль до CalcBalance(Date forDate = Date.Now). Дорогу, тыскызыть, осиливает идущий. Но я не настаиваю, пусть будет CalcCurrentBalance() и CalcBalance(Date forDate). Это все равно несравненно лучше суммирования проводок везде, где нужен баланс.

Откуда у Васи acc — как откуда? От AccountingService'а. Как он достукивается до сериса — это платформозависимые вещи. Если Вася пишет плагин (допустим, вебпарт), то и ссылку получает на входе. Если пишет standalone-страницу, просто обращается к сервису и получает у него интерфейс. Затем — что-то типа:

var acc = theService.GetAccountByReportIdentifier('78.01');

S>Сопли, простите, поскипаны. Если вы хотите что-то написать — пишите по делу. А не драму про Васю, который, оказывается, с самого начала ничего не знает, зато каким-то волшебным образом всё узнаёт. И про Синклера, который сначана всё знает, а потом почему-то стремительно тупеет.

Вася этот сидит у меня за спиной сейчас. Только зовут его Катя. Все взято с натуры.

Дальше, а почему Синклер тупеет? Цель была показать, что имплементация полна сюрпризов, а вы от них ограждены. Можете подставить СВ. Я люблю, когда ОМ скрывает от меня реализацию на первых порах и тупым себя по этой причине не считаю. Если и считаю, то не по этой. Главное, чтобы она (ОМ) по мере "врубания" и роста хотелок не становилась гирей на ногах, как это случилось с ShP OM.

SV.>>Гуёвый программист не занимается порождением объектной модели. Он отдает 78.01 в метод хелперного объекта AccountingService, и получает объект Account, который можно изучать через IDE. Оба они, AccountingService и Account, а также все реализации Account, описанные выше, являются частью объектной модели, создавать которую (и упаковывая реализацию в которую) дело архитектора.
S>Вопрос: зачем гуёвому программисту этот объект Account?
S>Что мешает ему сразу вызвать метод AccountingService.CalcBalance(...)?

А вот ЭТО и будет нарушением SRP, о котором столько говорилось. По сути, будет одна большая общая куча функций. Что-то типа WinAPI. Словами не передать, как я ненавижу изучать такие API.

S>Сколько разных реализаций вы себе представляете у класса Account?

Я привел пример с двумя реализациями: "реального" счета, то есть, счета, который пасется на базе, и агрегирующего счета, который агрегирует "реальные" счета по заданному признаку. Но это, подчеркиваю, не обязательно. Даже если у вас одна реализация, не надо свинячить и пихать в AccountingService everything and kitchen sink.

SV.>>Вы не читаете, что ли? Я же сказал: это зависит от точки зрения дизайнера на responsibility. Если думать о responsibility в терминах "функциональность по расчёту баланса", "функциональность по работе с базой" — тогда да, это нарушение SRP. Если считать responsibility этого класса "предоставить Васе доступ к балансам", тогда нет. Вот когда Account начнет заодно курсы валют возвращать, тогда это будет нарушение SRP.
S>Непонятно, где вы проводите границу responsibility. У классиков — всё понятно. Границы responsibility проходят там, где проходят разные причины для изменений. А с вашим подходом запихать вообще всё в функцию main — нормально, потому что ответственность программы это "сделать всё".

Про классиков я не знаю. Можете показать, что надо прочитать и соотнести — я прочитаю и соотнесу.

Запихать вообще всё в функцию main — НЕнормально, как раз потому, что ответственность нельзя описать словами "сделать всё". Сделать что? Декомпозируйте.

S>Я же вам привёл пример: сменили структуру базы или заменили хранилище — поправили код в одном месте. А у вас придётся править Account, Transaction, а то и всяких Person и прочих "активных классов", которые слишком много знают о доступе в базу.

SV.>>Еще раз. Вы просто не ставите такой задачи, которую решает ООП, допустим, в том же самом MS ShP.
S>Возможно, возможно. Я не говорю, что ООП вообще не нужно. Но в подавляющем большинстве софта для масс-процессинга ООП — это оверкилл. А бухгалтерия — это типичный пример масс-процессинга, где проводок — сотни и тысячи.

В реальности, вы же знаете, люди пишут код без комментов и переменные называют однобуквенными именами, чтоб с работы не выгнали. В подавляющем большинстве мест, я подозреваю. Какой тут ООП. Но если вы, допустим, архитектор и совладелец?

Про сотни и тысячи я не понял. Да хоть миллионы. ООП же не роняет производительность сама по себе.