Вадим, здравствуйте!

Для курса рефакторинга примеров на TypeScript пока не существует. Причём, я имею в виду расширенные "живые" примеры. Я планирую добавить их в рамках второй редакции курса, которая запланирована на конец года.

Спасибо за ваш отзыв, Арсений! Рад, что вам всё понравилось.

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

Примеры на чистом JS всё ещё в планах. Я попытался митигировать этот недостаток примерами на TypeScript, но понимаю, что не для всех это подходит.

Thanks, I'm glad that you like it.

Hi!

Thanks a lot for your feedback! I'm glad that you like it here! Graphis for the site is a result of me generating very crappy first drafts and the illustrator Dmitry Zhart turning them into something really nice.

Thanks for the kind words, Ahsan!

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

Спасибо за идею! Ничего не могу гарантировать, но я подумаю над этим.

Максим, здравствуйте!

Оба паттерна действительно похожи механизмом реализации — оба работают как обёртки. Полагаю, вы уже видели этот кусок из главной статьи:

Декоратор и Заместитель имеют схожие структуры, но разные назначения. Они похожи тем, что оба построены на композиции и делегируют работу другим объектам. Паттерны отличаются тем, что Заместитель сам управляет жизнью сервисного объекта, а обёртывание Декораторов контролируется клиентом.

...поэтому могу предположить, что вопрос для вас не до конца раскрыт.

Могу добавить, что паттерны это не только про код, но и про общение, общий словарь для программистов. Если вы скажете кому-то "я делаю прокси для класса базы данных" он однозначно поймёт, что вы делаете либо кеш, либо ленивую инициализацию, или что-то вроде того. Он не будет предполагать, что ваш "прокси" можно будет оборачивать другими "прокси", как это было бы возможно с декоратором.

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

Никаких чётких норм на этот счёт, к сожалению, нет. Проще всего определить большой класс используя принцип единственной ответственности. Если ваш класс делает слишком много разных дел, то вероятно его лучше разделить на части.