Your comments
Avoiding the direct construction of products on the client code is a whole point of the pattern. If you don't have this problem, you don't need to apply the pattern. If you can get away with a simple interface, then do it—the simpler the code, the better.
Hi Bruno!
Thanks, that's a good question! In most languages I'm aware of, an interface can not contain fields. I think the main goal of interfaces in Typescript was to ensure type safety in a wild variety of possible JavaScript objects, rather than implement or enforce any of the OOP concepts.
Hi Marko!
Hm, what do you define under "portability"?
Здравствуйте!
Спасибо за ваш отзыв, рад, что вам понравилась книга.
Для паттренов, примеры на TS уже есть. На счёт Dart пока не уверен, появятся ли. Для рефакторинга примеров на TS/Dart нет, но TS версия появится во второй редакции курса (даты выхода пока неизвестны).
Thank you for the feedback, Victor! I'm glad that you like my work.
Здесь под "расширенным" имеется в виду "реализованный" тем или иным образом.
Hi Bruno!
Implementation is established between interfaces/abstract classes and concrete classes which implement the specific behavior (please check the Encapsulation part in the "Pillars of OOP" chapter for details).
Please let me know if you have any further questions.
Здравствуйте, Владислав! К сожалению, пока что курс всё ещё работе. Мои изначальные анонсы делались ещё в пре-ковидные месяцы, с того времени очень много что поменялось и сроки изрядно сдвинулись.
Customer support service by UserEcho
Hi!
Thanks for a good question.
Strictly speaking, making the base products interfaces would be the most purist and minimal thing to do, because we are only interested in communicating the fact that the concrete products have a common parent. However, this doesn't mean that you have to specifically declare interfaces for this purpose. If you already have a class hierarchy, using the base class in the creation method result types would do just fine.