Hi Bruno!

Yes, you understand the implications of composition correctly. However, the Professor class wasn't meant to instantiate Student objects. It may receive a reference to a student by other means (via the constructor or some setter).

Здравствуйте!

Думаю, PHP вам будет ближе всего.

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.

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.

Duplicate for https://feedback.refactoring.guru/en/communities/3/topics/2007-translate-persian

Здесь под "расширенным" имеется в виду "реализованный" тем или иным образом.