Текущий дизайн
В нынешнем виде этот код не реализует шаблон адаптера. Что касается известных шаблонов проектирования, этот код не удовлетворяет всем, что я знаю. Вместо этого в приведенной ниже схеме используются базовые программные принципы: наследование и псевдопредложения.
![uml diagram](https://i.stack.imgur.com/hK8uI.png)
Ваша цель - «преобразовать PageInfo в ResponseDto». Я предполагаю, что вы имеете в виду, что хотите передать экземпляр ResponseDto, который инкапсулирует и делегирует классу PageInfo.
Причина, по которой это не является примером шаблона Adapter, заключается в том, что в настоящее время нет интерфейса, уникального для ResponseDto. На самом деле, он вообще не имеет интерфейса и не делегирует PageInfo & ndash; Задача 1.
Шаблон адаптера специально создан для инкапсуляции различных интерфейсов.
Примечания / Предложения / Вопросы:
- PageResponseDTO в настоящее время нарушает закон Деметры; он слишком много знает о внутренней структуре PageInfo.
- PageInfo ломает инкапсуляцию, раскрывая всю ее внутреннюю структуру.
- Вместо того, чтобы PageResponseDTO копировать все из PageInfo, почему бы просто не сохранить ссылку на экземпляр PageInfo и делегировать его при необходимости?
- Вы всегда можете скопировать интерфейс делегата, а не раскрывать его, но, если вы обнаружите, что копируете слишком много его функциональных интерфейсов, рассмотрите возможность его предоставления. В «Рефакторинге» Мартин Фаулер называет это «Инкапсуляция делегата» и «Исключение человека посередине» соответственно.