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

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

А я ничего такого не решал. Я решил что накапливать отсутствие памяти дешевле чем накапливать любую память в том числе из пула.

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

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

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

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

AVK>Ты его недостаточно любишь

AVK>

AVK>public static class NotNullUtils {
AVK>    public static IList<T> AsNotNull<T>(this IList<T> list) {
AVK>        return list ?? EmptyArray<T>.Value;
AVK>    }
AVK>

Вот эта оптимизация, в каких реальных сценариях она тебе понадобилась ? Какой был профит ?

S>Для ГУЯ сейчас актуально использовать какую-нибудь разновидность MVP.
S>Presenter — это как раз тот объект, который выполняет посредническую роль между Domain Model и представлением; он сам не соответствует ничему в предметной области.

При этом остается основной вопрос, а как организована Model?
Я утверждаю, что она должна быть организована в виде объектной оболочки к атомарному api.

S>Если ваш UI показывает сущности вашей внутренней модели, то в 99% случаев это плохо спроектированный UI.

ужасное утверждение, т.к. используется неопределяемое понятие "внутренняя модель".

Для меня как раз пример из ролика AndrewVK показывает, что в gui-е тупо показывается сущности внутренней модели (сущности атомарного api), например, даже никто не озаботился, чтобы число 20тыс. р не надо было вводить два раза, не говоря уже про какие-то более удобные вещи.


S>Пользовательский интерфейс должен проектироваться от сценариев пользователя; и объекты в нём будут такие, чтобы соответствовать сценариям пользователя.

Так объектная оболочка как раз и спроектирована от сценариев пользователей.

Если я руководитель небольшой ООО компании, то я:
— хочу выдавать распоряжения без всякой прослойки в виде бухгалтера (который лишь жрет мою прибыль),
— хочу чтобы система мне на основе бух. данных строила полноценных фин. анализ,
— хочу видеть Иванов.Выдать_Зарплату,
— хочу чтобы все КГОСУ проставлялись автоматически на основе лучших рекомендаций бух. консультантов по оптимизации налогооблажения,
— хочу видеть следующий сценарий использования бух. системы:
— подписался на пакет рекомендаций от консультанта бух. учета,
— вводишь Иванов.Выдать_Зарплату,
— бух. система сама проставляет все бюджетные коды на основе скаченного пакета рекомендаций.

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

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

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

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

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

I>Вот эта оптимизация, в каких реальных сценариях она тебе понадобилась ? Какой был профит ?

Много коротких итераций по разветвленному графу. Профит был в снижении нагрузки на GC.

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

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

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

Интересный подход. Т.е. программисты должны наплодить кучу никому не нужных методов, потратить массу времени на это, а конечному пользователю в итоге ни холодно ни жарко?

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

в реальном качественном примере должно быть:

ООО_Маша_и_Сыновья.Иванов_А_К.Начислить_Зарплату(2012, май, Трудовой_Договор.37, 15отработанных-дней, 5больничных);
ООО_Маша_и_Сыновья.Иванов_А_А.Покрыть_Долг(20000, From: Источник_обеспечения.Бюджет);

иначе не очень понятно на основе чего Иванову были выданы деньги.


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

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

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

и выкидываешь все остальные задачи, которые ставятся перед бух. учетом:
— обеспечение учета в рамках договорных отношений(если Иванов будет говорить, что ему не доплатили за работу на основе имеющихся у него трудового договора и приказов о поощрении, то именно бух. система должна уметь грамотно построить баланс между всеми выплатами Иванова и имеющимися документами: трудовой договор, приказы о поощрении, табель посещаемости, отчеты с командировок и т.д.)
— фин. анализ

поэтому я и утверждаю, что пример ужасный, не смотря на то, что он реальный (это лишь говорит об ужасной безграмотности в области фин. менеджмента ваших заказчиков), т.к. обе указанные задачи на основе строки "выдать Иванову 20000 за май в качестве зарплаты" не решишь.

AVK>>

AVK>>public static class NotNullUtils {
AVK>>    public static IList<T> AsNotNull<T>(this IList<T> list) {
AVK>>        return list ?? EmptyArray<T>.Value;
AVK>>    }
AVK>>

I>Вот эта оптимизация, в каких реальных сценариях она тебе понадобилась ? Какой был профит ?

для развесистого объектного дерева в котором пустой список — это норма, может дать экономию памяти в размере 5-15%, и ускорение работы gc процентов на 20-30

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

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

Я не хотел тебе отвечать, но все-таки отвечу.
Я тебя не обвинял в том, что ты не разбираешься в парадигмах; мне жаль, что ты понял эту фразу именно так, в ней перехода на личности не было. Но мне показался странным твой неожиданный отказ обсуждать теоретическую часть, т.к. к практике мы все же приходим через теорию. И да, вопрос "какая мне от этого польза на практике" должен быть неким итоговым вопросом, который должен быть задан, когда все понятия будут окончательно определены, и все собеседники с ними согласятся.

Какой смысл, скажем, рассуждать об ФП на практике, когда каждый вкладывает в это понятие что-то свое, причем с остальными принципиально не согласен? Данный тред явно показывает, что по крайней мере ФП мы уж точно понимаем по-разному.

ВВ>>Просто забавно, было наблюдать, как ты весьма охотно со мной спорил о чистоте концепций
AVK>Тебе показалось.
ВВ>>Вообще уровень дискуссии очень характерно развивается — посчитай, сколько раз в твоем сообщении слово "жопа" встречается.
AVK>Ты бы вместо жоп посчитал количество подтасовок в своих сообщениях.

В моих сообщениях не было подтасовок; тебе показалось. Если какая-то твоя мысль была неправильно понята, то вместо того, чтобы обвинять других в подтасовках, проще переформулировать, чем обвинять других в подтасовках.

As of now, мне, например, непонятна большая часть того, что ты писал в этом треде. К чему, например, ты писал о "костылях" в ФП?

Чтобы показать, что даже такие базовые вещи как АлгТД вносят в ФП нечистоту концепции? Как оказалось, нет.
Чтобы показать, что ФП изначально не предоставляет нужных абстракций? Опять же нет.

Ты можешь сейчас сказать, какие именно твои мысли были "подтасованы" и как их следовало понимать?

AVK>Интересный подход. Т.е. программисты должны наплодить кучу никому не нужных методов, потратить массу времени на это, а конечному пользователю в итоге ни холодно ни жарко?

Если это сделано грамотно, то бух. учет из обузы (и расходной статьи) превращается в доходный инструмент финансового управления.
О чем и рассказывают в любом курсе финансового менеджмента, но насколько я понял — забыли об этом рассказать программистам бух. систем.

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

DG>в реальном качественном примере должно быть:
DG>

DG>ООО_Маша_и_Сыновья.Иванов_А_К.Начислить_Зарплату(2012, май, Трудовой_Договор.37, 15отработанных-дней, 5больничных);
DG>ООО_Маша_и_Сыновья.Иванов_А_А.Покрыть_Долг(20000, From: Источник_обеспечения.Бюджет);
DG>

DG>иначе не очень понятно на основе чего Иванову были выданы деньги.

Что то я окончательно перестал тебя понимать. Ты предлагаешь отказаться от статической типизации или завести на каждого Иванова отдельное свойство в объекте предприятия?

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

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

Это не я беру, это клиенты мне за это платят. А за сферическую бухгалтерию в вакууме нифига не платят.

DG>- обеспечение учета в рамках договорных отношений(если Иванов будет говорить, что ему не доплатили за работу на основе имеющихся у него трудового договора и приказов о поощрении, то именно бух. система должна уметь грамотно построить баланс между всеми выплатами Иванова и имеющимися документами: трудовой договор, приказы о поощрении, табель посещаемости, отчеты с командировок и т.д.)

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

DG>поэтому я и утверждаю, что пример ужасный, не смотря на то, что он реальный

Приведи другой реальный, но не ужасный.

DG> (это лишь говорит об ужасной безграмотности в области фин. менеджмента ваших заказчиков)

Давай мы не будем обсуждать чью либо безграмотность, ок?

DG>, т.к. обе указанные задачи на основе строки "выдать Иванову 20000 за май в качестве зарплаты" не решишь.

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

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

MVP — это ответ на вопрос, как реализовывать gui
OOUI — это ответ на вопрос, на основе каких принципов проектировать gui

и друг другу эти ответы ортогональны, и соответственно выбор реализации, как MVP — никак не противоречит пострению GUI-я как OOUI.

ps
стоит хоть иногда книжки читать, хотя бы классику: Нильсен, Коллинз, Раскин

pps
ты лучше про веревку ответь, в фундаменте ООП — ты более подкован, и там с тобой интересно дискутировать, а про дизайн систем — не очень.

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

AVK>>Интересный подход. Т.е. программисты должны наплодить кучу никому не нужных методов, потратить массу времени на это, а конечному пользователю в итоге ни холодно ни жарко?

DG>Если это сделано грамотно

Опять общие слова. Ты мне покажи как грамотно и почему. Пока что все твои примеры только приводят к распуханию и усложнению кода.

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

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

AVK>Опять общие слова. Ты мне покажи как грамотно и почему. Пока что все твои примеры только приводят к распуханию и усложнению кода.

основу я уже сказал.
Поверх атомарного api наворачивается несколько уровней объектной оболочки, которые приближают объектную модель программы к понятийной модели пользователя, позволяя ему единообразным способом работать — с GUI, CLI и скриптами, а также разгововарить на едином языке с программистами при постановке задач по разработке.
В идеале — объектная оболочка строится автоматически, требуя минимальных трудозатрат. На практике — смешивается автоматическое построение объектной оболочки с ручным заданием.

Из твоих слов следует, что для тебя таких задач не существует, и для тебя это всего лишь разбухание кода.

И соответственно тогда основной вопрос: как я могу тебе показать, что эти задачи есть, важны, и нужны?

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

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

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

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

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

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

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

DG>основу я уже сказал.

Лично у меня только больше вопросов появилось и ни одного ответа. Ты прямые вопросы пропускаешь, и вместо этого переключаешься на что то еще. А в последних сообщениях так и вовсе решил обсудить мою, Синклера и моих заказчиков квалификацию.

DG>Поверх атомарного api

Что такое атомарный api и как он должен выглядеть?

DG> наворачивается несколько уровней объектной оболочки, которые приближают объектную модель программы к понятийной модели пользователя

Зачем? И с какой стати ты решил, что в понятийной модели пользователя хозоперация является частью кредитного счета?

DG>, позволяя ему единообразным способом работать — с GUI, CLI

Что такое CLI?

DG> и скриптами

Пользователю со скриптами? Ты ничего не перепутал?

DG>, а также разгововарить на едином языке с программистами при постановке задач по разработке.

Пользователю разговаривать напрямую с программистами? Все страньше и страньше.

DG>В идеале — объектная оболочка строится автоматически, требуя минимальных трудозатрат.

Ух ты. Автоматически на основании чего? И зачем какая то оболочка, не привносящая в систему новой информации?

DG> На практике — смешивается автоматическое построение объектной оболочки с ручным заданием.

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

DG>Из твоих слов следует, что для тебя таких задач не существует

Каких таких?

DG>, и для тебя это всего лишь разбухание кода.

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

DG>И соответственно тогда основной вопрос: как я могу тебе показать, что эти задачи есть, важны, и нужны?

Начни с описания одной подобной задачи. Реальной, а не "сижу, примус починяючеки разбираю". Потому что если реальной задачи нет — все это превращается в очередной бредогенератор типа ветки про открывание двери.

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


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

Ты не ответил ни здесь, ни на пред топик. Где сама-то сортируемая коллекция? Где аннотации как минимум еще двух типов?
Ну и каша...

А вопрос был ключевой лишь потому, что речь идет о статически-типизированном языке, то бишь, что бы не возвращал modifier[ctx] (скажем, SortModifier), и что бы не возвращаел затем Apply(x), — независимо от исходного модификатора это будет значение одного и того же типа. А я не вижу аннотаций в примере.

Итого, в твоем примере я даже не вижу по какому критерию происходит сортировка. Полный мрак и непонятки. Вот причина "ключевых вопросов" — из-за нечитабельности кода.

Ну ок, буду разгребать твою кашу.

Помнишь, я писал тебе тебе, что есть замыкание? Вот часть инфраструктуры вне примера:

// лямбда
template<typename F, typename C>
struct Fn { F f; C c; };

// хелпер создания
template<typename F, typename C>
Fn make_fn(F f, C c) {...}

// хелперы использования

template<typename R, typename A, typename Fn>
Ret call(Fn f, A * a) {
  return fn.f(c, a);
}

template<typename R, typename A1, typename A2, typename Fn>
Ret call(Fn f, A1 * a1, A2 * a2) {
  return fn.f(c, a1, a2);
}  
...

Имеем некую обобщенную процедуру сортировки (показываю ключевые моменты):

template<typename Fn>
inline void qsort(CollectionOfX * collection, Fn f) {
  // blah-blah
  int compareRеsult = call<int>(f, x1, x2);
  
  switch(compareRеsult) {
    // blah-blah
  }
}

Далее, я из головы дополню отсутствующие нотации типов в твоем примере.

struct SaltedModifier;  // это то, что возвращается выражением modifier[ctx]
struct ModifiedX;       // это то, что подлежит сравнению

// исходная ф-ия - компаратор, подразумеваемая в твоем примере
int CompareByModifiedX(ModifiedX * a, ModifiedX * b);

А теперь само решение. Смотрим на твой код и отделяем мух от котлет, то бишь свободные переменные от связанных в замыкании:

int CompareUsingModifier(SaltedModifier * sm, X * a, X * b) {
  return CompareByModifiedX(sm->Apply(a), sm->Apply(b));
}

Mod modifier = GetSalt();
Ctx ctx = GetContext();
SaltedModifier sm = modifier[ctx];

qsort(collectionOfX, make_fn(CompareUsingModifier, &sm));

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

Ты показал плохой пример. Ничего не понятно. В отличие от моего конечного варианта, который отличается одной доп. ф-ей CompareUsingModifier.

V>>Структуры данных в любом случае проектировать надо.
I>Нет, не надо. Замыкания решают этот вопрос на 100%

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

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

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>>

I>Ну и снова ты отошел от структурного программирования.

А в какую сторону я отошел-то? Тебя идентификатор lambda смутил? А если бы я назвад его object?
Например, куда здесь отошла ф-ия драйвера, которой сам драйвер подается как контекст?

void ioctl(IODriver * driver, int param, void * arg);

В какую сторону ты видишь тут "отход от структурного программирования" (С)? В ФП или ООП?
Заметь, отход-то равнозначный... что как бэ намекает на истоки озвученного мною мнения. Я ведь не с потолка утверждение сделал, а после изготовления пары интерпретаторов ф-х языков.

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

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

Т.е. тебе опять нечего ответить? ЧТД.


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

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

Общий случай в qsort и есть. Похоже, ты не понимаешь, где в твоем собственном примере IoC, а где ФП. См внимательно мой вариант твоего примера.


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

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

О, уже пошел разговор сам с собой. ))

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

I>Не надо врать.

Т.е. ты не понял, что я только что написал? ЧТД.

I>"реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции"

Именно, твой пример — тому пример. Твоего замыкание в дизайне не видно. А вот упущенные в примере аннотации типов и сам Order — они видны в полный рост. Просто их скромно прячешь, превращая свой пример в кашу.

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

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


I>2. управлять контекстом придется вручную

Ну да. Подавать "контекст" придется вручную. Более того, у контекста теперь появится... оп-па! Экземпляр!


I>3. проектировать структуры данных для взаимодейтсвия придется вручную

Структура данных нужна будет для отображения контекста, а не дляя взаимодействия. Например в ООП, объект — это контекст самому себе. Так же смотри мой пример с IODriver. Я бы не сказал, что выделение контекста в отдельный тип IODriver такая уж плохая идея...

============================
Кстати, у тебя, походу, проблемы с оперативной памятью:
I>Покажи внятный аналог моего кода.
I>Покажи внятный аналог моего кода.
I>Покажи внятный аналог моего кода.
I>Покажи внятный аналог моего кода.

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

DG>При этом остается основной вопрос, а как организована Model?
DG>Я утверждаю, что она должна быть организована в виде объектной оболочки к атомарному api.
Что такое "атомарный API"?

S>>Если ваш UI показывает сущности вашей внутренней модели, то в 99% случаев это плохо спроектированный UI.
DG>ужасное утверждение, т.к. используется неопределяемое понятие "внутренняя модель".
Оно вполне определяемое. Просто внутренняя модель сильно зависит от применяемой архитектуры.
Скажем, если мы работаем в традиционной для 90х годов клиент-серверной архитектуре, то внутренняя модель — это таблички и хранимые процедуры. В неё нет никаких объектов (и они нафиг не нужны).
Если мы работаем в традиционной для ранних 2000 SOA-архитектуре или трёхзвенке, то внутренняя модель — это сервис (или несколько сервисов) с RPC-style дырками в них. Опять никаких объектов нету (ну, кроме объекта "ендпоинт", который никак предметной области не соответствует).
Можно ещё поиграть в рич-модель, но она, по моему опыту, затрудняет работу как тому, кто её мучительно пишет, так и тому, кто её мучительно потребляет.

DG>Для меня как раз пример из ролика AndrewVK показывает, что в gui-е тупо показывается сущности внутренней модели (сущности атомарного api), например, даже никто не озаботился, чтобы число 20тыс. р не надо было вводить два раза, не говоря уже про какие-то более удобные вещи.
У меня IE x64, ролики кажет через раз. Так что не могу конструктивно обсуждать пример AVK.
S>>Пользовательский интерфейс должен проектироваться от сценариев пользователя; и объекты в нём будут такие, чтобы соответствовать сценариям пользователя.
DG>Так объектная оболочка как раз и спроектирована от сценариев пользователей.
Непонятно. Сценарий — это, грубо говоря, набор глаголов.
DG>Если я руководитель небольшой ООО компании, то я:
DG>- хочу выдавать распоряжения без всякой прослойки в виде бухгалтера (который лишь жрет мою прибыль),
Много эмоций, мало смысла.
DG>- хочу чтобы система мне на основе бух. данных строила полноценных фин. анализ,
Много эмоций, мало смысла.
DG>- хочу видеть Иванов.Выдать_Зарплату,
А это ещё зачем?
DG>- хочу чтобы все КГОСУ проставлялись автоматически на основе лучших рекомендаций бух. консультантов по оптимизации налогооблажения,
DG>- хочу видеть следующий сценарий использования бух. системы:
DG>- подписался на пакет рекомендаций от консультанта бух. учета,
DG>- вводишь Иванов.Выдать_Зарплату,
DG>- бух. система сама проставляет все бюджетные коды на основе скаченного пакета рекомендаций.
Чушь какая. Вы вообще реальных пользователей видели когда-нибудь? У них нет терминов "скачанного пакета" и "вводишь".

AVK>Что то я окончательно перестал тебя понимать. Ты предлагаешь отказаться от статической типизации или завести на каждого Иванова отдельное свойство в объекте предприятия?

1. автоматически завести отдельное свойство в объекте орг. структуры предприятия
2. статически проверять валидность операций
3. при сбоях в статических проверках — по максимуму локализовывать ошибку, и обеспечивать работоспособность остальной системы

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

AVK>Но я так и не получил от тебя ответов на кучу заданных вопросов. Я правильно понимаю, что для ввода первички и формирования хозопераций объект Счет все таки не нужен?

Необходимо сначала договориться о терминах: что такое первичка, и что такое счет?

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

Также для меня Иванов.Начисленный_Доход, Иванов.Отработанные_Дни, Иванов.Расходы_из_его_собственных_средств — это тоже Счета, но уже больше в парадигме финансового и управленческого учета.


DG>>поэтому я и утверждаю, что пример ужасный, не смотря на то, что он реальный

AVK>Приведи другой реальный, но не ужасный.

Я его привел:
1. сначала начисляем Иванову зарплату на основании трудового договора и табеля об отработанных днях
2. затем закрываем обязательства перед Ивановым в размере 20тыс. рублей

хочется видеть как это делается в парусе: как через Gui (в виде скринкаста), так и через CLI или скрипт (в виде примера кода).

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

потому что для меня как для руководителя — фин.менеджмент — это первично, а бух. учет в разрезе кодов КБК — это вторично, который лишь навязан мне бюджетными органами, и для меня ничего полезного не делает.

Здравствуйте, DarkGray, Вы писали:
DG>MVP — это ответ на вопрос, как реализовывать gui
DG>OOUI — это ответ на вопрос, на основе каких принципов проектировать gui
Я, наверно, вас разочарую, но OOUI сейчас несколько вышло из моды.
Я читал Мандела — доктор наук, как никак. Но невооруженным мозгом понятно, что с тех пор, как он проектировал интерфейс для полуоси, человечество ушло далеко вперёд.
OOUI начинает со страшной силой сливать в случае более-менее сложных моделей, где объектов — много. Слишком много нужно умственных усилий, чтобы найти нужный объект, догадаться, что с ним делать, и выполнить действие. Особенно это здорово заметно, когда для действия нужно более одного объекта.

DG>и друг другу эти ответы ортогональны, и соответственно выбор реализации, как MVP — никак не противоречит пострению GUI-я как OOUI.
Совершенно верно. При этом надо понимать, что объектная ориентированность самого UI никакого отношения к внутреннему устройству не имеет. OOUI можно писать хоть на фортране-77.

DG>ps
DG>стоит хоть иногда книжки читать, хотя бы классику: Нильсен, Коллинз, Раскин
Можно цитату, где они настаивают на OOUI?
DG>pps
DG>ты лучше про веревку ответь, в фундаменте ООП — ты более подкован, и там с тобой интересно дискутировать, а про дизайн систем — не очень.
Что-то у меня запал иссяк. Там в верёвках и концах — сплошной косяк. Начиная с того, что у вашей верёвки произвольное количество концов.
Если непонятно, почему для непрерывно переходящих друг в друга объектов нельзя ввести identity, то я — пас.