Вернуть this из класса

[belugin]

ok. Сущсвуют ли по твоему мнению такие условия, когда примемение EQB приемлемо?

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

EQB прост для изучения - это всего лишь результат применения паттерна ExpressionBuilder по отношению к аксаптовскому Query. Несколько минут, если уже знаешь то и другое, зато сэкономит время и объем внимаения, т.к. под ногами не будет болтатьсся всякие fetchMode(0) и прочие дубли

[mazzy]

Цитата:

Сообщение от belugin

EQB прост для изучения - это всего лишь результат применения паттерна

Могу ошибаться, но мне кажется, что:
1. при построении перекрестных ссылок у Аксапты может пехать крыша
2. query лучше строить не в коде, а в AOT, а в коде инстанцировать одной строкой query = new Query(querystr(mySuperQuery))

[belugin]

Цитата:

Сообщение от mazzy

Могу ошибаться, но мне кажется, что:
1. при построении перекрестных ссылок у Аксапты может пехать крыша
2. query лучше строить не в коде, а в AOT, а в коде инстанцировать одной строкой query = new Query(querystr(mySuperQuery))

1. Не поедет - это такой же код как и другой
2. Query плохо читаемо: для того, чтобы узнать, какие есть условия на поля надо активно возить мышкой и нажимать на плюсики. Даже для того, что убедится, что оно не отсортировано. Т.е. визуализация Query содержит много лишних деталей, но при жтом нужные детали запрятаны глубоко.

Сорри, при наведении на датасурс часть структуры показывается...

[mazzy]

Цитата:

Сообщение от belugin

1. Не поедет - это такой же код как и другой

Не совсем. Уровней вложености много.

Цитата:

Сообщение от belugin

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

В том то и дело.
В АОТ структура запроса отделена от кода. Следовательно:
1. заниматься оптимизацией и улучшизмами можно отдельно от кода (может отдельный человек)
2. апгрейд сильно упрощается, поскольку самым трудоемким является апгрейд кода. А количество кода при использовании Query из АОТ сильно уменьшается.

Но что-то я ушел от темы.

В общем, я согласен, что паттерн ExpressionBuilder позволяет сделать интересный код.
Но у него все ж таки есть недостатки, связанные с глубиной.
1. как я уже говорил могут поехать перекрестные ссылки
2. по-моему, нельзя будет поставить точку останова на конкретный метод (дебаггер остановится на первом вызове, а затем в дебаггере нужно будет заходить в каждый парм-метод)
3. возникают очень тонкие и неявные побочные явления, связанные с порядком вызова методов и их аргументов
4. не дай бог какому-нибудь из методов вернуть значение Null.
5. непонятно как возвращать параметры

В общем, все равно весь код в подобном стиле написать не получится.
Значит будет дикая смесь нотаций: традиционной и через-точку.

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

[belugin]

Цитата:

Сообщение от mazzy

Не совсем. Уровней вложености много.

Надо проверить....

Цитата:

1. заниматься оптимизацией и улучшизмами можно отдельно от кода (может отдельный человек)

В принципе, да, есть примеры в реальности? Как фиксируется интерфейс Query (то есть то, что нельзя менять при такой оптимизации - состав полей, порядок записей)

Цитата:

2. апгрейд сильно упрощается, поскольку самым трудоемким является апгрейд кода. А количество кода при использовании Query из АОТ сильно уменьшается.

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

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

Цитата:

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

Согласен.

Цитата:

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

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

Цитата:

4. не дай бог какому-нибудь из методов вернуть значение Null.

Каким образом return this может превратиться в Null

Цитата:

5. непонятно как возвращать параметры

Так как builder нацелен на создание Query, у него все сделано для того, чтоб эта задача решалась максимально просто и лаконично. Возврат параметров просто будет методами с более длинными названиями. Либо через Query

Цитата:

В общем, все равно весь код в подобном стиле написать не получится.
Значит будет дикая смесь нотаций: традиционной и через-точку.

Ну не согласен что смесь - скорее кровавая Мери - водка отдельно, томатный сок отдельно.

[mazzy]

Цитата:

Сообщение от Андре

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

А чем легче, чем при традиционном?

Цитата:

Сообщение от Андре

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

отвечю чуть ниже

Цитата:

Сообщение от belugin

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

parm1(someComplexType _var)
{
    // модифицируется и проверяется _var
    return this;
}
parm2(someComplexType _var)
{
    // модифицируется и проверяется _var
    return this;
}

classvar.parm1(func1(var1)).parm2(func2(var1));

в каком порядке будут вызваны parm1, parm2, func1, func2?
Если вдобавок внутри происходит модификация переменных, то...

Не помню у кого, но видел в подписи выражение типа (i=1;i+=(i++)+(i++);cout<<i);
запись через точку порождает примерно такие же головоломки

Цитата:

Сообщение от belugin

Каким образом return this может превратиться в Null

Во всей Аксапте принято возвращать null или пустую запись, если что-то не получилось.

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

Цитата:

Сообщение от belugin

Так как builder нацелен на создание Query, у него все сделано для того, чтоб эта задача решалась максимально просто и лаконично.

А... дык, это только для создания query...

[belugin]

Цитата:

Сообщение от mazzy

А чем легче, чем при традиционном?

отвечю чуть ниже

     parm1, parm2, func1, func2?

Если бы не было return this, to все было то же самое. кроме повторения названия переменных.

func1, parm1, func2, parm2.

Цитата:

Если вдобавок внутри происходит модификация переменных, то...

Не помню у кого, но видел в подписи выражение типа (i=1;i+=(i++)+(i++);cout<<i);
запись через точку порождает примерно такие же головоломки

не.. тут зависимости видны явно.

Разве есть разница между

query.proc1(func1(x));
query.proc2(func2(x));

и

query.proc1(func1(x))
        .proc2(func2(x));

Цитата:

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

Тоже исключение.

Цитата:

А... дык, это только для создания query...

Именно! Этою билдер - оно и в названии отражено.

[oip]

Цитата:

Сообщение от belugin

ok. Сущсвуют ли по твоему мнению такие условия, когда примемение EQB приемлемо?

Не знаю. Пока я думаю, что разве что в учебных целях, но не на реальном проекте внедрения. Ну или в каких-то сторонних приблудах типа Табакса.

Цитата:

Сообщение от belugin

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

Вот пусть и изучает бизнес-сущности, а не способ кодирования. Не важно, изолирован модуль или нет. Абсолютно не важно.

Цитата:

Сообщение от belugin

т.к. под ногами не будет болтатьсся всякие fetchMode(0) и прочие дубли

Мне эти фетчмоды не мешают, я к ним уже привык.