Адаптер адаптує заданий клас / об'єкт до нового інтерфейсу. У випадку з попередніми зазвичай застосовується багатократне успадкування. В останньому випадку об'єкт загортається відповідним адаптерним об'єктом і передається навколо. Проблема, яку ми тут вирішуємо, - це несумісні інтерфейси .
Фасад більше схожий на простий шлюз до складного набору функціоналу. Ви робите чорну скриньку, щоб ваші клієнти менше турбувалися, тобто спрощували інтерфейси .
Проксі надає той самий інтерфейс, що і для класу proxied для класу, і, як правило, робить деякі речі по господарству самостійно. (Отже, замість того, щоб робити кілька копій важкого об'єкта, Xви робите копії легкого проксі-сервера, Pякий, в свою чергу, керує Xта переводить ваші дзвінки за потребою.) Ви вирішуєте проблему клієнта від необхідності керувати важким та / або складним об'єктом .
Декоратор використовується для додавання більшої кількості пороху до ваших об'єктів (зверніть увагу на термін "об'єкти", як правило, ви декоруєте об'єкти динамічно під час виконання). Ви не приховуєте / не пошкоджуєте існуючі інтерфейси об'єкта, а просто розширюєте їх під час виконання .
Тепер, коли ви залучили декоратора, ви, ймовірно, захочете дізнатися, чому наголос на об’єкті слова - деякі мови (як-от Java) просто не дозволяють віртуальному успадкуванню (тобто багатократному успадкуванню, як це робить C ++), щоб дозволити вам це зробити в час складання.
Оскільки ми затягнули декілька спадків (і жахливий алмаз), ви будете шукати міксин - які впорядковані лінійними ланцюжками інтерфейсів, щоб вирішити проблеми багаторазового успадкування. Однак міксини не так добре змішуються. І ми закінчуємо рисами - так, ті маленькі краплинки поведінки, які ви бачите весь час у параметрі шаблону в C ++. Риси намагаються вирішувати питання композиції та декомпозиції поведінки на вишуканий спосіб, не збираючись ні для множинних спадок, ні для впорядкованого прикування.