The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Sometimes Very often I need a class that implements an interface by making an instance of another class. Sound weird? Let me show you an example. There are many classes of that kind in the Takes Framework, and they all are named like *Wrap. It’s a convenient design concept that, unfortunately, looks rather verbose in Java. It would be great to have something shorter, like in EO for example.
Взгляните на RsHtml из Takes Framework. Его дизайн выглядит так (упрощенная версия с одним основным конструктором):
Теперь давайте посмотрим на ту RsWrap, которую она расширяет:
Как видите, этот “декоратор” ничего не делает, кроме “простого украшения”. Он инкапсулирует другой Response и передает все вызовы методов.
Если это еще не ясно, я объясню назначение RsHtml. Допустим, у вас есть текст, и вы хотите создать Response:
Вместо того чтобы делать эту композицию декораторов снова и снова во многих местах, вы используете RsHtml.
Это очень удобно, но RsWrap очень многословен. Слишком много строк, которые ничего особенного не делают; они просто перенаправляют все вызовы методов к инкапсулированному Response.
А что если мы введем новую концепцию “декораторов” с новым ключевым словом decorates:
Затем, чтобы создать объект, мы просто вызываем:
У нас нет новых методов в декораторах, только конструкторы. Единственная цель этих парней - создавать другие объекты и инкапсулировать их. Они не являются полноценными объектами. Они только помогают нам создавать другие объекты.
Вот почему я бы назвал их “украшательными конвертами”.
Эта идея может выглядеть очень похожей на паттерн проектирования Фабрика, но у нее нет статических методов, которые мы пытаемся избежать в объектно-ориентированном программировании.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:51
