Цитата:
Сообщение от
mazzy
Не совсем. Уровней вложености много.
Надо проверить....
Цитата:
1. заниматься оптимизацией и улучшизмами можно отдельно от кода (может отдельный человек)
В принципе, да, есть примеры в реальности? Как фиксируется интерфейс Query (то есть то, что нельзя менять при такой оптимизации - состав полей, порядок записей)
Цитата:
2. апгрейд сильно упрощается, поскольку самым трудоемким является апгрейд кода. А количество кода при использовании Query из АОТ сильно уменьшается.
Я мало занимался апгрейдом, но при закачке внутренних обновлений обычно код сравнивать легче, чем, например, формы.
Я за то, чтобы не использовать Builder в модицикациях кода подверженного апгрейдам (имеется ввиду сторонний код).
Цитата:
2. по-моему, нельзя будет поставить точку останова на конкретный метод (дебаггер остановится на первом вызове, а затем в дебаггере нужно будет заходить в каждый парм-метод)
Согласен.
Цитата:
3. возникают очень тонкие и неявные побочные явления, связанные с порядком вызова методов и их аргументов
Вот тут не очень понятно, можено пример? Вроде порядок вызова четко определен.
Цитата:
4. не дай бог какому-нибудь из методов вернуть значение Null.
Каким образом return this может превратиться в Null
Цитата:
5. непонятно как возвращать параметры
Так как builder нацелен на создание Query, у него все сделано для того, чтоб эта задача решалась максимально просто и лаконично. Возврат параметров просто будет методами с более длинными названиями. Либо через Query
Цитата:
В общем, все равно весь код в подобном стиле написать не получится.
Значит будет дикая смесь нотаций: традиционной и через-точку.
Ну не согласен что смесь - скорее кровавая Мери - водка отдельно, томатный сок отдельно.