Новое сообщение в форум Философия программирования

Форум	Философия программирования
Тема	Как правильно задавать вопросы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SV.>[c#]
SV.>var acc = theService.GetAccountByReportIdentifier('78.01');
SV.>[/c#]

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

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

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

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

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

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

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

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

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

SV.>Запихать вообще всё в функцию main - НЕнормально, как раз потому, что ответственность нельзя описать словами "сделать всё". Сделать [i]что[/i]? Декомпозируйте.
 
S>>Я же вам привёл пример: сменили структуру базы или заменили хранилище - поправили код в одном месте. А у вас придётся править Account, Transaction, а то и всяких Person и прочих "активных классов", которые слишком много знают о доступе в базу.

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

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

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

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail