Почему так? new без параметров, инициализация через parm-методы

[S.Kuskov]

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

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

[mazzy]

Цитата:

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

А что в этом подходе плохого?

Почему плохого?

А что плохого, например, в ноже? Инструмент и инструмент. У всего есть область применения.

Лучше расскажите что хорошего.

Цитата:

Сообщение от S.Kuskov

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

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

А почему такой стиль делает программное создание более удобным?

=============
Накину в обсуждение:
* стиль с parm-методами "скрывает" обязательные для объекта параметры
* стиль с parm-методами вынуждает добавлять валидацию внутреннего состояния объекта в начале каждого метода

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

[S.Kuskov]

Цитата:

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

А почему такой стиль делает программное создание более удобным?

Создание объекта становится не атомарной операцией. Её можно разделить на этапы и ответственность за каждый этап делегировать. Появляется бОльшая гибкость.

[mazzy]

Цитата:

Сообщение от S.Kuskov

Создание объекта становится не атомарной операцией. Её можно разделить на этапы и ответственность за каждый этап делегировать. Появляется бОльшая гибкость.

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

собственно и вопрос - а что с таким полусобранным (не гарантированным) объектом делать?
и не превысят ли затраты на валидацию преимущества такой гибкости?

может быть, я еще каких-нибудь преимуществ не знаю?

[S.Kuskov]

Цитата:

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

собственно и вопрос - а что с таким полусобранным (не гарантированным) объектом делать?

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

Цитата:

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

и не превысят ли затраты на валидацию преимущества такой гибкости?

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

Нет универсального ответа. Для каждой задачи своё решение.

[mazzy]

Цитата:

Сообщение от S.Kuskov

Создание объекта становится не атомарной операцией. Её можно разделить на этапы и ответственность за каждый этап делегировать. Появляется бОльшая гибкость.

Цитата:

Сообщение от S.Kuskov

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

Нет универсального ответа. Для каждой задачи своё решение.

Не, нет гибкости.
есть тупость порождающего алгоритма.

* сложность одинакова и для геренации параметров конструктора, и для генерации вызова parm-методов. буквально пара if
* порождающий алгоритм должен знать какие параметры являются обязательными и для параметров конструктора, и для parm-методов. Но в parm-методах это знание не выражено явно
* из-за неявности, приходится добавлять валидацию перед каждым методом объекта, который порожден parm-методами.

Повторю: вопрос не в том "что плохого, что хорошего"? и это не вопрос, который требует универсального ответа 42.

Собственно вопрос: Почему так? При каких условиях parm-методы все-таки эффективнее? Только авто-генерация кода? Но в Аксапте её практически нет.