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.
Спасибо за добрые слова, рад что вам всё понравилось!
Спасибо, поправил!
Customer support service by UserEcho
Закрываю как дубль: https://feedback.refactoring.guru/communities/1/topics/530-izdat-pechatnuyu-versiyu-knigi