Спасибо на добром слове, Максим.

That's a nice catch! Here's a difference, though. In the book, I'm talking about objects—I meant that a component object can't act on its own, so when you create objects you will most likely create both the container and the component. There's no reason to create an instance of a component (make it exist) on its own. But when we're talking about classes, there's a slight distinction that I pointed out in the previous comment. I'll make a note to myself to revise this part in the book to eliminate the confusion.

Hi Martin!

Thanks for a good question. I don't think it's a requirement of the composition. There are certainly cases when both the container and the component don't make sense without each other. But I can also imagine the composition, where the component can be used in several different containers, and it's the container that can't exist without a component.

嗨！

https://github.com/RefactoringGuru/design-patterns-java/tree/master/src/refactoring_guru/adapter/example

你好！

抱歉，英语链接，但包含您问题的答案：

https://feedback.refactoring.guru/en/knowledge-bases/5/articles/1878-why-dont-the-book-include-the-interpreter-pattern

Thanks for the suggestion and examples, Gillian! I'll keep this in mind for future versions of design patterns content. I'm fond of the exercies as well.

Thank you for reporting this issue. I fixed it and sent the updated version to deployment. It'll be live in half an hour. Thanks again!

我已经解决了这个问题。 请从您的帐户下载该书的新版本。 再次感谢！

你好！ 感谢您的举报，我将再次检查Kindle的格式。

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

Спасибо за хороший вопрос. В какой-то степени, да, противоречит. В то же время, от разделения может и не быть очень большого выигрыша. Принципы SOLID не являются чем-то высеченным в камне.

Если у вас есть небольшой класс для работы с отчетами, в котором есть фабричный метод, то выделив всю фабричную часть в отдельный класс вы точно сделаете код сложнее, но не факт, что этим будет удобнее пользоваться.