Реализовать скриптинг некоего алгоритма

Ты бы хоть указал что именно тебе не нравится в указанной реализации? IMHO реализация как реализация. Если работает то и нехай себе. Или как обычно, когда программисту делать нечего он цвета настраивает? (c)...

Эта не реализация а ее план. А не нравится не мне а тем кто не знает ни ооп, ни миксины js.

Вобщем без примера трудно, а фраза про ооп и миксины только нагнала туману, но скажу например, чего бы хотел я, как пользователь-скриптописатель какой-либо системы. Так вот, я бы не хотел вешать каких-то 5 коллбеков и непонятно что в них делать. Я бы хотел, чтобы была одна точка входа - функция и было бы предоставленно АПИ, которое я бы вызывал как хотел и когда хотел. Кроме того, чтобы мне дали примеров, как разработчик видет использование своего апи.

В твое случае я пишу

function myScriptFuntction(сontext){
  contex.doSomeInit();
  var sql = context.prepareSQL("MY SUPER SQL");
  var prepared = sql.bindParameters("Hello, world");
  var result = prepared.execute();
  return result;
}

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

Как-то так

s/видет/видел/

Алгоритм это, грубо говоря

function myAlgorithm(a, b) {
    return a + b;
}

имхо, этого достаточно.

Со стороны джавы архитектура наверное нормальная.

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

Я понимаю, что сложнее, коллбечный проще для тебя, а прямой- для пользователя. Вспомни, чем тебе удобней пользоваться - DOM или SAX, ну точнее, не DOM, а дотнетовский ридер, не в курсе, сделали ли его в яве, пулл-парсер вобщем. Просто ты написал, что алгоритм последовательный, поэтому его удобнее делать последовательным кодом в скрипте, а не у тебя.

не так

Context{
//тут хранится кой какой состояние, исходный запрос все это вызвавший 
//и еще до фига всего, в том числе и того что паблик быть не должно, но 
//в силу текущего подхода есть
 int a,b,c,d;
}
Algoritm{
 init(context ctx);
 Builder createBuilder(Context ctx);
 prepareStatement(Context ctx, Statement statement);
 query(Conetxt ctx, Statement statement)
}
//далее некий метод вызывает один раз init, затем раз 5 2й метод, 
//затем столько же третий, и т.п.

Зойдача дать пользователю все это кошерно переопределять, отменять, логгирвоать и т.п.

Я понимаю, что сложнее, коллбечный проще для тебя, а прямой- для пользователя.

Косяк в том что если пользователь захочет переопределить лишь один метод, то дефолтный алгоритм отключается, и пользователю надо писать 10 строчек + 1 которую он хотел добавить, а с миксинами - достаточно перегрузить нужный метод

Вспомни, чем тебе удобней пользоваться - DOM или SAX, ну точнее, не DOM, а дотнетовский ридер

SAX, но многие меня не поймут 8) Дотнетовский ридер я не знаю, нешто они на DOM забили?

Ну ридер это SAX наоборот

     while (reader.Read())
        {
            switch (reader.NodeType)
            {
                case XmlNodeType.Element:
                    writer.WriteStartElement(reader.Name);
                    break;
                case XmlNodeType.Text:
                    writer.WriteString(reader.Value);
                    break;
                case XmlNodeType.XmlDeclaration:
                case XmlNodeType.ProcessingInstruction:
                    writer.WriteProcessingInstruction(reader.Name, reader.Value);
                    break;
                case XmlNodeType.Comment:
                    writer.WriteComment(reader.Value);
                    break;
                case XmlNodeType.EndElement:
                    writer.WriteFullEndElement();
                    break;
            }
        }

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

и пользователю надо писать 10 строчек + 1 которую он хотел добавить, а с миксинами - достаточно перегрузить нужный метод

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

Можно кстати оба механизма дать, убъешь 2-х зайцев.

аа, так если сах - сродни посетителю, то ридер - итератору.

Точно подмечено! И простым людям - итератор проще, что неудивительно.

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

жабаскрипт ему предоставит изолированный контекст, для хранения, так что 2 проблемы - нет инкапсуляции контекста запроса (того что Context из примера кода) и пользователю надо объяснить что враппер stateless. Вот последнее условие весьма нехорошо.

Можно кстати оба механизма дать, убъешь 2-х зайцев.

Я потом на поддержке буду завален зайчатиной.

Ну и еще - из итератора сделать посетитель - как два пальца, а вот наоборот - думать надо, и не всегда придумаешь.

пользователю надо объяснить что враппер stateless

Вот видишь, действительно надо объяснять, я уже собрался в глобалы-кложуры складывать, а нельзя :-)

Я потом на поддержке буду завален зайчатиной.

Тогда таки АПИ и одна функция. А сделать хитро - они и сами смогут, если захотят-асилят, все таки жс же нормальный язык. Но конечно, зависит, насколько усложнится твоя задача.

для скриптинга pnuts понравился