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

[Raven Melancholic]

Справедливости ради стоит заметить, что во многих классах, в которых new защищенный так же защищенным (или приватным) является construct. А создание и инициализация выполняется методами-фабриками классов (типа newPurchInvoice и т.п.) которые конструируют и настраивают класс.
Так что какой-то проблемы вроде бы и нет. Хорошо это или плохо наверное и не сказать - ну есть такой подход.
Насколько помню, было даже время, когда Best practic ругался на код внутри метода с наименованием construct, если там было что-то помимо new.

[skuull]

Цитата:

Сообщение от Raven Melancholic

Хорошо это или плохо наверное и не сказать - ну есть такой подход.

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

[Raven Melancholic]

Цитата:

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

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

Абсолютно верно. Я сам очень часто использую именно подход с фабричным методом (а в сложных случаях и с отдельным классом - фабрикой) именно по этим причинам.
На мой взгляд, есть просто потрясающий пример плюса данного подхода. В DAX есть семейство классов SysExcel*, работает через COM.
Уважаемый gl00mie создал семейство, работающее через более надежный NET (ну точнее COM тожеможно сделать боле-менее надежным при помощи Dispatch, но речь не про это). Переключение старого на новое потребовало только изменить фабричный метод. А вот если взять ComOfficeDocument_RU, то реализация на NET в общем-то несложная, но вот переключение на его использование уже напрягает.