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


DG>значит для этой системы будет

DG>

DG>class БухСчет
DG>{
DG>  public Tx[] Оплатить(БухСчет target, Товарный_Чек чек)
DG>  {
DG>    return DocTxService.MakeDocTx(CreateDocument(this, target, чек));
DG>  }
DG>}
DG>Нал.Оплатить(Основные_Фонды, new Товарный_Чек("Компьютер Pentium", 20000, "ИП Пупкин и сыновья", ...));
DG>

То есть ты непонятно на каком основании сделал кредитный счет важнее дебетового. Зачем?

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

AVK>>Тебе уже несколько раз сказали — проводка ссылается минимум на два счета. К какому из них она относится?

DG>ты мне сейчас рассказываешь про SRP

Нет.

DG>. SRP никакого отношения к объектной оболочке отношения не имеет, а имеет отношение лишь к процессу хранения состояния.

Вообще смысл не уловил. SRP относится к дизайну в рамках любой парадигмы, а не эксклюзивно к ООП. И уж тем более не ограничен рамками хранения состояния. SRP просто мнемоническое правило для следования критериям low coupling/high cohesion, и касается исключительно связей между сущностями в коде, и ничего более.

DG>SRP никак не мешает иметь два метода, которые делают похожую работу:

Не похожую, а идентичную, просто порядок аргументов чуть отличается. Нет, не мешает, но на эту тему вроде бы какой то другой модный принцип был, я их не очень хорошо все помню.

DG>

DG>class БухСчет
DG>{
DG>  public Tx[] Оплатить(БухСчет target, Товарный_Чек чек)
DG>  {
DG>    return DocTxService.MakeDocTx(CreateDocument(this, target, чек));
DG>  }
DG>  public Tx[] ОплатитьИз(БухСчет source, Товарный_Чек чек)
DG>  {
DG>    return DocTxService.MakeDocTx(CreateDocument(source, this, чек));
DG>  }
DG>}

А зачем? Какой юзкейс такие методы упрощают?

DG>и соответственно, обе следующие операции равноправны:
DG>[c#]
DG>Нал.Оплатить(Основные_Фонды, new Товарный_Чек("Компьютер Pentium", 20000, "ИП Пупкин и сыновья", ...));
DG>//или
DG>Основные_Фонды.Оплатить_Из(Нал, new Товарный_Чек("Компьютер Pentium", 20000, "ИП Пупкин и сыновья", ...));
DG>

Т.е. одно и то же можно сделать двумя способами. Вопрос все тот же — зачем?

AVK>Т.е. одно и то же можно сделать двумя способами. Вопрос все тот же — зачем?

Потому что так удобно — в частности, повышается обзорность.
так же есть принцип "there's more than one way to do it", который в частности входит в unix-way

ps
например, при решении задачи:
сидя вечером разобраться почему в кармане сейчас нала 600р, а бух. система говорит, что баланс 970р, то мне проще работать с объектом Нал, параллельно вспоминая что произошло за день, разыскивая чеки и применяя их к счету Нал, отслеживая сошелся баланс по счету с действительностью или нет?

pps
если же речь идет про программиста, то тот же Gui проще строить по такой объектной оболочке (при этом элементы на экране и кнопки в один к одному соответствуют объектной оболочке, что упрощает построяние скриптов и их освоение пользователем: пользователь просто записывает в скрипте то, что он делал до этого руками), чем строить его к "атомарному" api.

AVK>А зачем? Какой юзкейс такие методы упрощают?

Весь gui сейчас строится по ООП-метафоре: либо простой — объект + действия, либо сложной — объект + палитра инструментов.

Gui удобнее строит поверх объектной оболочки, имея соответствие элементов-на-экране к объектам-в-коде, а также кнопок/пунктов-в-меню/элементов-в-палитре-инструментов к методам-объекта — как 1 к 1 по двум основным причинам:
1. упрощается тестирование и сопровождение. Можно отдельно простыми unit-тестами проверить правильность объектной оболочки, и потом для Gui-я лишь проверить, что соответствующая кнопка вызывает соответствующий метод
2. api скриптов и командой строки соответствует действиям GUI-я 1 к 1

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

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

S>>Да нет, я стою на месте.

V>Стоял бы на месте если бы не увиливал от аргументов:
V>

V>>>Поведение — это реакция на внешние раздражители. Например, при попытке открыть дверь не в ту сторону, поведение двери будет вполне предсказуемым — она откажется открываться.

Я уже на этот бред отвечал что с дверьми не разговариваю.

V>Это я еще не всё описал. Но я и не собрался, просто ХЗ сколько тебе надо подробностей, чтобы показать причинно-следственную связь событий, которую ты перед этим показательно проигнорировал.
Не нужны мне подробности, с дверьми не разговариваю.

S>>Я не говорю о фиксации. Я говорю что дверь.Откройся() далека от рж безотносительно ТЗ.

V>Дык, разрешение абстрагироваться от подробностей тебе затем и дано, чтобы ты не вычислял лишнего в программе. Тики-то процессора не бесплатные и не бесконечные. Особенно во времена становления ООП. )))
Разговор о том и идет, что чтобы от рж перейти к модели, надо все подробности выкинуть, прикрутить что-то свое, а потом соврать что получилось один в один.

S>>Такая модель может соответствовать ТЗ, я ведь об этом ничего не говорю. Но далека от реальной двери.

V>Пофиг, в инженерии кач-во решения определяется степенью его соответствия функциональным и нефункциональным требованиям. Это всё!
Извини, но ты влез в спор на стороне, которая утверждала что ООП модель в точности соответствует реальной жизни. Причем утверждала это без всякого ТЗ. (*)

V>Опять же — модель двери ни в коем случае не самоцель. Парадигма вообще не может быть самоцелью. Модель двери — это инструмент, помогающий упорядочить наше понимание о происходящем в собственном коде, это элемент решения задачи. В конкретной иерархии объектов это мог быть элемент декомпозии по принципу SRP и ничего более. И то, если дверь имеет поведение в том смысле как показал, например, существует в коде возможность "попытаться открыть дверь не в ту сторону", а дверь "умно" реагирует. А так-то если никакого поведения нет, то объект можно смело заменять данными, в данном случае:
V>

V>bool doorState;
V>

V>Вот почему я надоедаю со своим ТЗ, что мы-то обсуждаем решение, а условия никто еще не слышал. Дурдом? Натуральный. Отсюда и столь различные решения у всех участников, как в конкурсе "принеси то, не знаю что".
см. (*)

S>>Он может быть не такой и сложный, но ООП все поставит с ног на голову.

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

V>>>Ты даешь двери воздействие. Затем "что-то происходит": силы складываются по-ньютоновски, кинетические энергии переходят... Но сорри, мы же программисты — ленивый народ и не делаем лишнюю работу!
S>>Видишь, ты сам понимаешь что модель далека от моделируемого.

V>Модель задачи и модель решения — это независимые модели, увы, до тех пор, пока такая зависимость не оговорена в ТЗ.
Но ты влез на ту сторону, короче см. (*)

V>>>Коль тебя интересует лишь конечный результат, то мы абстрагируемся от подробностей и просто хотим получить результат — дверь открыта в итоге или нет? Итого всё взаимодействие с дверью сводится к посылке двух сообщений: от тебя к двери и от двери к тебе.
S>>Вот тут ты свою физику и слил. Дальше скипаю.

V>Ты как всегда скипнул неудобные аргументы. В данном случае вот эти:
V>

V>ты той же рукой осязаешь положение двери и/или контроллируешь ее положение взглядом, сигналы органов чувств попадает тебе в мозг, накладываются на твой опыт и понимание, как выглядит/озязается открытая и закрытая дверь, и после сопоставления своего опыта и сигналов рецепторов ты делаешь вывод о том, открыта ли она...

А, т.е. ты предлагаешь уже моделировать сингалы органов чувств, мозг, опыт и понимание? Извини что пропустил, очень интересно.

V>Объективно тебе необходимо взаимодействовать с дверью, чтобы узнать постфактум события открытия двери. Будь то оптическое взаимодейтвие, либо физическое. В любом случае переносится информация именно от двери именно к тебе и энтропия в момент доставки информации к тебе падает.
Информация от двери переносится да. Но далеко не в форме диалога "Дверь, ты открыта?" (дверь шуршит микросхемами и возвращает в ответ "Нет, я отказалась открываться".
Происходит обычно следующим образом. Я начинаю воздействовать на дверь и ожидаю что мои рецепторы начнут ловить сигналы об изменении положения двери. Понимаешь, диалога-то нет.


S>>ну, вспоминай физику, которую ты слил. Что-то я не помню что бы ты говорил о сообщениях в ней.

V>Гы-гы. А что есть сообщения, по-твоему?
V>Термин "информация" имеет вполне определенный физический смысл.
Но ты меня так не убедил что дверь отправляет сообщения.

V>>>А как же ты её видишь и/или осязаешь? По закону сохранения энергии, сигналы в твоих рецепторах органов чувств не могут взяться из ниоткуда. Это, уважаемый коллега, пришло внешнее для тебя воздействие. Будь оно оптическое или ньютоновское.
S>>Все пропало!

V>Тебе еще не 90, еще есть шанс, не переживай.
Глядя на тебя, уже начинаю переживать.

S>>Двери воздействуют на людей ньютоновскими силами!

V>Домашнее задание: какой закон Ньютона имелся ввиду при физическом фзаимодействии руки с дверью?
да фиг знает, что ты имел в виду. При фосдействии на дверь рукой — второй описывает фосдействие на дверь, третий говорит что фосдействие на руку равно по модулю.


S>>Я пользуюсь рецепторами вне зависимости от наличия рядом двери. И это, отраженный свет послан мне внезапно не дверью вовсе.

V>Оп-па! Отраженный от двери свет послан не дверью. Я бы на месте твоего школьного учителя физики съел свою шляпу.
да, ну если так сложно со светом, давай представим мяч, который попал в тебя рикошетом от двери. Ты будешь думать что это дверь послала в тебя мяч? Не, я догадывался что у тебя проблемы с дверьми, но что настолько... Пожалуй мой учитель тут не виноват.

V>Ну а на месте ВУЗовского съел бы там, где ты плаваешь в вопросах информации.
Как шляпе повезло, мне не читали в ВУЗ-е теорию информации. Вообще. Зато целый год упрощенного паскаля

S>>И кстати, если я вижу дверь, то я ее вижу вне зависимости от того спрашивал я дверь о том, вижу ли ее или нет.

V>Как это вне зависимости, если ты свои органы чувств должен настроить таким образом, чтобы достоверно различить положение двери. То бишь, получить информацию о ней? Как минимум ты должен открыть глаза, посомтреть в ее сторону и сфокусировать кристаллики глаза. Ничего себе "не спрашивал"... Или ты буквально выразился в том плане, что решил с дверью поговорить? )))
Слушай, а ты машину водишь? И вообще, когда смотришь, фокусируешься на всем подряд и спрашиваешь каждую вещь, видишь ли ты ее?

S>>Т.е. концепции единого сообщения нет. Пусть будет мульон сообщений. Но ведь в твоей модели лишь одно...

V>Да, повторно переданная одна и та же информация не изменяет энтропию, увы. Поэтому ленивые программисты поступают с лишней информацией... впрочем, ты уже в курсе как.
Ну вот я и утверждаю что модель далека. А ты решил поспорить.

S>>Еще раз. Я писал о ЧИСТОМ языке. CL не чист.

V>Вообще-то ты писал о Лиспе.
Я писал о чистом языке.

S>>Ты хочешь что бы я как ты вилял? Мне это зачем?

V>Вилять можно только если влез, а потом понял, что не туда. Так что виляние уже де-факто происходит. Ты дважды оспорил, а потом так и не пояснил, ПОЧЕМУ ты спорил-то. Если не воспринимаешь оппонента всерьез, зачем столько пишешь ему в ответ?
Я уже задолбался писать, почему я спорю и за что. А про зачем столько пишешь — ну мне ведь интересно, куда ты дальше вильнешь.

V>>>По указанной в пред посте ссылке, рядом с этим постом в обсуждении есть разбор механики тайпклассов для таких сценариев.
S>>разбор механики ничего не говорит о заимствовании.

V>Согласен, на уровне механики заимствование не считается, это лишь подробности. Но на уровне концепции это есть контракт, который сам по себе концепция в ООП в таком точно виде. Т.е. в кач-ве концепции дизайна тайпклассы и контракты в ООП настолько близки, насколько это вообще возможно, т.к. и те и другие задают набор операций над одним и тем же элементом дизайна, в обоих случаях над типом.
Слушай, ну концепция-то одна на все — мешок указателей на функции. Только от мешка до ООП далеко еще.

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

AVK>>Т.е. одно и то же можно сделать двумя способами. Вопрос все тот же — зачем?

DG>Потому что так удобно

Чем удобно? Тем, что надо непонятно откуда доставять экземпляр счета?

DG> — в частности, повышается обзорность.

Какая такая обзорность? Если ты про discoverability, то она прекрасно повышается extension методами без измывательств над публичными контрактами бизнес-сущностей. Но в данном случае мне совершенно непонятно, зачем может понадобиться цепочка discovery от счета к проводке.

DG>например, при решении задачи:
DG>сидя вечером разобраться почему в кармане сейчас нала 600р, а бух. система говорит, что баланс 970р, то мне проще работать с объектом Нал, параллельно вспоминая что произошло за день, разыскивая чеки и применяя их к счету Нал, отслеживая сошелся баланс по счету с действительностью или нет?

Все равно непонятно, откуда там объекты Счет появятся. Сперва в системе ты заводишь документ — чек. Далее вызываешь для него метод Отработать, и внутренняя логика формирует проводку. Счета при этом даже не вводятся тобой руками, а определяются типом документа и его содержимым в алгоритме формирования отработки, т.е. внутри твоего "Оплатить".

DG>если же речь идет про программиста, то тот же Gui проще строить по такой объектной оболочке

Чем проще?

DG> (при этом элементы на экране и кнопки в один к одному соответствуют объектной оболочке

Давай на реальном примере. http://www.parus.ru/tornado/node/78 — расходник. Вот где там Нал.Отработать() упростит жизнь?

DG>, что упрощает построяние скриптов и их освоение пользователем: пользователь просто записывает в скрипте то, что он делал до этого руками), чем строить его к "атомарному" api.

Мне все меньше и меньше понятно, о чем ты.

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

DG>Весь gui сейчас строится по ООП-метафоре: либо простой — объект + действия, либо сложной — объект + палитра инструментов.

Здорово. Осталось понять, какая связь с объектом Счет.

DG>1. упрощается тестирование и сопровождение. Можно отдельно простыми unit-тестами проверить правильность объектной оболочки, и потом для Gui-я лишь проверить, что соответствующая кнопка вызывает соответствующий метод
DG>2. api скриптов и командой строки соответствует действиям GUI-я 1 к 1

Я рядом ссылочку на скринкаст привел. Жду конкретики.

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

I>

I>Mod modifier = GetSalt();
I>Ctx ctx = GetContext();

I>Order(x => modifier[ctx].Apply(x))
I>

I>Покажи такой же фокус, что бы все было так же прозрачно.

Ничего прозрачного я не вижу. Что возвращает modifier[ctx]?


I>>>Кроме того, в твоем примере все точно так же упирается в имена функций при том что один из методов, там где ExtractABC хуже некуда.

V>>Ниче не понял, перефразируй, плиз.

I>В моем примере лямбды дают инверсию и прозрачность, нет нужны ковырять внутренности. В твоем ничего этого нет, можно догадываться только исходя из имен методов.

Дык и у тебя без именнованного метода было бы не понятно, с какой целью надо было извлечь поле ABC из x.



I>>>В моем случае все это по месту вызова.
V>>Тю блин, в твоем случае была одна полезная строчка. В случае же тысяч полезных строчек, удачно подобранные имена идентификаторов становятся всё более востребованными, не находишь? ))

I>Лямбды избавлдяют от нехобходимости проектировать структуры данных и сигнатуры для взаимодействия, тупо берешь локальный контекст и используешь. Изменился контекст — не надо ничего менять снаружи.

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

I>В твоем случае надо перепахивать все подряд,ибо надо проектировать и структуры данных и сигнатуры.

Структуры данных в любом случае проектировать надо. Подозреваю, что ты таки имел ввиду локальность видимости? Но в С++ я могу эти структуры или объекты с методами проектировать внутри других методов для решения локальных задач:

void Method() {
  Obj1 x;
  vector<Obj2> vec;
  
  struct : Base {
    Obj * x;
    void operator()(Obj2 y) { x->do(y); }
  } lambda = { &x };

  foreach(vec, lambda);
}

Пример просится на частичное применение через boost:bind без дополнительных локальных структур:

void Method() {
  Obj1 x;
  vector<Obj2> vec;

  foreach(vec, bind(&Obj1::do, x, _1));
}

Но будем считать, что в сложном случае частичным применением не отделаешься, поэтому первый вариант безымянных объектов в помощь.

В общем, свои наработки для локализации видимости элементов программы есть во многих языках. В Джава для этого есть анонимные объекты, в которых ты можешь переопределять виртуальные методы, захватывать контекст и т.д. и всё это в рамках всего одной операции SomeObject obj = new SomeObject() { /* расширение объекта */};

То бишь, лямбда, как элемент лямбда исчисления, — это уникальный момент, а как элемент локализации видимости кода — ни разу не новость.


V>>Так видел или не видел? http://cplus.about.com/od/learningc/ss/pointers2_8.htm
V>> Там же такое же точно IoC в полный рост. И это императив из махровых 70-х. А при вызове мы совершаем над qsort то самое DI, подавая адрес ф-ии-компаратора.

I>Там нет никакого IoC.

Я тебе показал IoC в qsort прямо по определению IoC.

I>не веришь — покажи аналог для моего кода выше.

Конечно не верю. Никакой другой пример не отменяет дизайна qsort. Для твоего кода тоже покажу, ес-но, только ответь там на вопрос.

I>То есть, все атки ФП ? Опаньки ! А надо было показать разницу между функционально и процедурной.

Кто здесь?
)))
Я и показал в процедурном стиле... пытаюсь сфокусировать тебя, что это тоже самое, что на функциональном подходе. Это не оппаньки, это и есть цель, см. историю этой ветки.

ИМХО, замыкания и ФВП отличаются от рукопашного процедурного кода лишь тем, что сами протягивают свой контекст за собой, а в процедурном мире этот контекст приходится протягивать ручками через доп. аргументы. Но если ты понимаешь, как работает ФП, ничто не мешает воспроизвести аналог в любой технике. Особенно легко это в ООП+GC. Собсно, ты это в примерах и показываешь на анонимных делегатах дотнета. ))

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

>> Математика — это инструмент для описания закономерностей мира.
G>То есть инструмент, не модель.

Модель — тоже инструмент. Математика описывает модели. Прикладные разделы математики — это и есть модели, опирающиеся на более атомарные разделы математики (описываемые с помощью них).


G>И не является частью модели.

С ума сошел? Модель всегда работает по неким законам.


G>В программировании инструментальных средств — внезапно! — большая часть.

По русски можно?

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

V>>Нету нулевого поколения. Сообщения принципиально должны обрабатываться после линии задержки.
I> Для для чего инстанцировать на момент попадания в очередь, если обработка будет после выхода из неё ?

На выходе точный таймер, собственно, тебе длина очереди дана чтобы сгладить все эффекты с быстродействием, то бишь дать некую фору во времени. Да и с чего ты решил, что накапливать нейтивную память дешевле, чем объекты из пула? Однофигственно.

>>Длительность линии я тебя чуть приврал, на самом деле она плавающая, зависит от результата мониторинга разброса интервалов м/у пакетами в сети, но примерную верхнуюю границу указал верно. В нормальном режиме задержка порядка 100ms, но меня интересует худший случай, ес-но.

I>У меня в тесте тоже нет нулевого поколения. Так ты выдашь внятный тест или будешь и дальше сочинять ?

Я тебе уже сказал, что тебе надо делать.


V>>Кароч, ты упомянул свой уже готовый тест — давай его сюда. Я над ним поработаю на досуге для доведения до похожих условий. Т.е. если тебе реально интересно — без проблем. (просто, помня твой стиль, вовсе не факт, что сие именно так, уж не обессудь )
I>У меня стиль простой — пока ты не выложишь внятную модель или жосткие данные я ничего выкладывать от себя не собираюсь.

ЧТД. Демонстрировать серьезность намерений — это не твой стиль. Приятно было поболтать ни о чем.

AVK>Давай на реальном примере. http://www.parus.ru/tornado/node/78 — расходник. Вот где там Нал.Отработать() упростит жизнь?

тут, вообще, достаточно (если, конечно, цель — дружественная система, а не сделай всё сам):

ООО_Маша_И_Сыновья.Иванов_А_К.Выдать_Зарплату(20000, 2012, 5);

всё остальное бантики, и должно подставляться автоматически.

можно, конечно, задать и в ручную

ООО_Маша_И_Сыновья.Иванов_А_К.Выдать_Зарплату(20000, 2012, 5, 
  From: Источник_обеспечения.Бюджет, 
  Debet: КБК.11.Счет.12.Косгу.13,
  Credit: КБК.10.Счет.1.Косгу.14
)

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

I>Если ты внимательно читал,то у меня самая плохая реализация выдаёт в 10 раз больше того, чем тебе хочется.

Сравнение на разной технике может показать что угодно.
Современная итак в 10 раз быстрее той, итого, ты сожрал на бесполезном GC все выч ресурсы той техники. Работать программе некогда. Поздравляю.

>>Затраты на GC — не только на выделение объектов 0-го поколения. Размазывай все его затраты на все его операции со всеми поколениями. Ты в своем тесте создавал одно сообщение и помещал его в очередь? А ты создавал к этому сообщению пустой список полей так же по new каждый раз? Если не создавал, то создай и прогони тест опять. Вычти затраты из остатка на сообщение.

I>Зачем заранее создавать и хранить пустой список полей ?

Потому что с пустым списком идут большинство полей, вестимо.


I>Это по требованию нужно делать. О чем я тебе и говорю уже в который раз.

Этот детсад хорошо смотрится для одноразовых вычислений, а не для поточной обработки с объектами из пула.


V>>Ну и дело было 5 лет назад, никаких 4 или 8 ядер не было. Сейчас одно ядро в среднем в 3 раза быстрее, и кол-во ядер в 2-3 раза больше. Если ты получил всего на порядок быстрее, то ты, выходит, всё быстродействие тех машин занял одним GC.

I>Нет, все быстродействие съедает неэффективная очередь, а не GC. Профайлер показывает что издержки на GC ничтожные.

Что ты мне неткаешь, если твои 10 раз отожрали весь выч.ресурс тех машин? Кароч, не компосируй мне процессор. Пример нетривиальный, с 0-ля делать ради тебя не буду. Ты говоришь у тебя что-то уже есть — дык давай. Я все-равно минимум вдвое твой пример ускорю сугубо за счет уже описанных словами техник. Более того, пытливый ум может интересовать исключительно сравнительные цифры на одной и той же технике, а не абсолютные на разных. Смысл выкатить только один мой пример? А может ты банально испугался?

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

http://www.rsdn.ru/forum/philosophy/4838064.1.aspx

Автор: vdimas
Дата: 01.08.12

Смотри какое дальше идет бурление овн. ))

AVK>Я рядом ссылочку на скринкаст привел. Жду конкретики.

Вообще, пример ужасный. При таком ведении бухучета, я не вижу как можно будет проводить вменяемый фин. анализ для данной компании.

>>> Математика — это инструмент для описания закономерностей мира.
> G>То есть инструмент, не модель.
>
> Модель — тоже инструмент. Математика описывает модели. Прикладные разделы математики — это и есть модели, опирающиеся на более атомарные разделы математики (описываемые с помощью них).

В твоем представлении что-нибудь кроме моделей существует? Или в твоем представлении мы все созерцательные кони в вакууме? Что, никак-никаких-совсем никаких средств воздействия на окружающий мир? Совсем никаких новых сущностей, только отражение "реального мира"?


> G>И не является частью модели.
>
> С ума сошел? Модель всегда работает по неким законам.

Ну по крайней мере я умею разделять модели и понятия, отделяю инструментальные средства от объектов их применения. А ты этого не можешь. Так что кто тут сошел с ума это пока вопрос.


> По русски можно?

По русски тут будет три буквы.

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

AVK>Вы говорите о разных вещах. Синклер о бухгалтерском счете, ты о банковском.
Да, совершенно верно. Ок, банковский счёт можно рассматривать как объект — в некоторых изолированных сценариях.
Вопрос о том, в каких именно, и насколько это будет уместно, я пока опущу.

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

DG>Весь gui сейчас строится по ООП-метафоре: либо простой — объект + действия, либо сложной — объект + палитра инструментов.
Для ГУЯ сейчас актуально использовать какую-нибудь разновидность MVP.
Presenter — это как раз тот объект, который выполняет посредническую роль между Domain Model и представлением; он сам не соответствует ничему в предметной области.
Если ваш UI показывает сущности вашей внутренней модели, то в 99% случаев это плохо спроектированный UI.
Пользовательский интерфейс должен проектироваться от сценариев пользователя; и объекты в нём будут такие, чтобы соответствовать сценариям пользователя.

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

I>>

I>>Mod modifier = GetSalt();
I>>Ctx ctx = GetContext();

I>>Order(x => modifier[ctx].Apply(x))
I>>

I>>Покажи такой же фокус, что бы все было так же прозрачно.

V>Ничего прозрачного я не вижу. Что возвращает modifier[ctx]?

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

I>>В моем примере лямбды дают инверсию и прозрачность, нет нужны ковырять внутренности. В твоем ничего этого нет, можно догадываться только исходя из имен методов.

V>Дык и у тебя без именнованного метода было бы не понятно, с какой целью надо было извлечь поле ABC из x.

Сортировка по конкретному колумну для тебя новость ? В твоем случае ты даже не узнаешь, по чем сортирует вообще, придется раздранонить все подряд.

I>>Лямбды избавлдяют от нехобходимости проектировать структуры данных и сигнатуры для взаимодействия, тупо берешь локальный контекст и используешь. Изменился контекст — не надо ничего менять снаружи.
V>Гы-гы... в паскалеподобных языках есть локальные процедуры в процедурах и т.д. рекурсивно. Причем, локальным процедурам доступен контекст вышестоящих процедур. В итоге — такое же точно замыкание безо-всяких лямбд.

Покажи хороший пример вроде того, что я показал.

"реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции" — собтсенно это ты и не можешь показать.

V>Структуры данных в любом случае проектировать надо.

Нет, не надо. Замыкания решают этот вопрос на 100%

>Подозреваю, что ты таки имел ввиду локальность видимости? Но в С++ я могу эти структуры или объекты с методами проектировать внутри других методов для решения локальных задач:

V>

V>void Method() {
V>  Obj1 x;
V>  vector<Obj2> vec;
  
V>  struct : Base {
V>    Obj * x;
V>    void operator()(Obj2 y) { x->do(y); }
V>  } lambda = { &x };

V>  foreach(vec, lambda);
V>}
V>

Ну и снова ты отошел от структурного программирования. Покажи внятный аналог моего кода.

V>Пример просится на частичное применение через boost:bind без дополнительных локальных структур:
V>

V>void Method() {
V>  Obj1 x;
V>  vector<Obj2> vec;

V>  foreach(vec, bind(&Obj1::do, x, _1));
V>}
V>

V>Но будем считать, что в сложном случае частичным применением не отделаешься, поэтому первый вариант безымянных объектов в помощь.

Покажи внятный аналог моего кода.

V>В общем, свои наработки для локализации видимости элементов программы есть во многих языках. В Джава для этого есть анонимные объекты, в которых ты можешь переопределять виртуальные методы, захватывать контекст и т.д. и всё это в рамках всего одной операции SomeObject obj = new SomeObject() { /* расширение объекта */};

Покажи внятный аналог моего кода и не соскакивай со стурктурного .

V>То бишь, лямбда, как элемент лямбда исчисления, — это уникальный момент, а как элемент локализации видимости кода — ни разу не новость.

А про новости никто и не говорил, важно что это новые возможности для дизайна которых в структурном и близко нет. Даже в ООП и то нет.

I>>Там нет никакого IoC.

V>Я тебе показал IoC в qsort прямо по определению IoC.

Покажи общий случай IoC а не вырожденый, мой пример выше.

I>>не веришь — покажи аналог для моего кода выше.
V>Конечно не верю. Никакой другой пример не отменяет дизайна qsort. Для твоего кода тоже покажу, ес-но, только ответь там на вопрос.

Покажи внятный аналог моего кода.

V>Я и показал в процедурном стиле... пытаюсь сфокусировать тебя, что это тоже самое, что на функциональном подходе. Это не оппаньки, это и есть цель, см. историю этой ветки.

Ты вообще то говорил что "реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции"
Собтсенно это ты и не можешь показать.

V>ИМХО, замыкания и ФВП отличаются от рукопашного процедурного кода лишь тем, что сами протягивают свой контекст за собой, а в процедурном мире этот контекст приходится протягивать ручками через доп. аргументы. Но если ты понимаешь, как работает ФП, ничто не мешает воспроизвести аналог в любой технике. Особенно легко это в ООП+GC. Собсно, ты это в примерах и показываешь на анонимных делегатах дотнета. ))

Не надо врать. "реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции"
В другой технике у тебя просто нет аналога, потому что
1. связывание придется делать вручную
2. управлять контекстом придется вручную
3. проектировать структуры данных для взаимодейтсвия придется вручную

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

DG>тут, вообще, достаточно (если, конечно, цель — дружественная система, а не сделай всё сам):
DG>

DG>ООО_Маша_И_Сыновья.Иванов_А_К.Выдать_Зарплату(20000, 2012, 5);
DG>

А ничего что таких целей 100500 может быть? Будем на каждую по методу заводить?

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

AVK>>Я рядом ссылочку на скринкаст привел. Жду конкретики.

DG>Вообще, пример ужасный.

Пример реальный.

DG> При таком ведении бухучета, я не вижу как можно будет проводить вменяемый фин. анализ для данной компании.

Видишь ли, никому не интересен гипотетический и не существующий в природе идеальный бухучет. Есть законодательство, которое довольно жестко регламентирует, что и как, и никто в нашей стране от него не освобожден.