Your comments

Hi Alberado!


I'm sorry for the very late reply. I think the non-obvious part of the examples is that this null check can be shifted to the place where you get the customer instance originally, a getter for example. Then you can eliminate dozens of null checks across the code that uses the customer object for a price of one initial null check in the getter.

Thanks a lot for your feedback, I'm glad that you like it.

Сергей, здравствуйте!

Вероятно это чувство вызвано вот этим куском:

this.button = this.dialog.createButton();

this.button.onClick(()=> {
console.log(`Hello ${this.env}`);
})

console.log(this.button.render());

Этот код напрашивается на перенос в саму фабрику. В этом патерне, чаще всего пользователем создаваемого продукта выступает остальной код Создателя (класс Dialog), поэтому я и не люблю называть Создателя "фабрикой" — в какноничном устройстве паттерна он производит продукты чисто для себя. Расширяя этот класс, вы подменяете создаваемый продукт, расчитывая что основной код Создателя теперь станет работать с этим новым продуктом.

Вообще, для практики я бы вам рекомендовал конвертировать примеры с PHP, там прекрасный сет примеров с web-спецификой, который для вас, вероятно, будет куда ближе, чем джавовские GUI.

Hi!

I'm sorry to give a vague answer, but it's all based on the tradeoff. If you have 9 independent codebases, which are a real pain to maintain then, sure, go for it and try to extract the common modules. If these 9 independent codebases still have a lot of differences and you're extracting modules today which won't make a lot of sense tomorrow, then don't.

Спасибо за добрые слова, рад что вам всё понравилось!