Тут доклад про плохие абстракции и пример, где якобы не подходит DRY - Don't Repeat Yourself - принцип, говорящий о том, что код нужно переиспользовать, а не дублировать. И действительно, иногда формально похожая логика может быть принципиально отличной из-за разной бизнес ценности. Но пример какой-то идиотский приведен. И зачем-то разжевывается на 20 минут времени.
У нас есть класс A и класс B, которые мы хотим распечатывать. Первый способ решения якобы нарушающий DRY - два класса APrinter и BPrinter. Второй - якобы соблюдащий - один класс GeneralPrinter. Причем ставится условие, что классы A и B должны печататься по-разному. Тут же из задачи очевидно, что есть две разные логики. Объединить их в одну реализацию можно будет только через ветвление. И сигнатура метода окажется с флагом - плохая абстракция.
Вообще говоря, - это хрестоматийный пример, когда говорят про полиморфизм. Мол вместо лесенок из условных конструкций используйте его. Это не про DRY - логика всегда будет разная, просто выбор логики происходит не в момент выполнения, а при создании объекта. А вот абстракцию в таком случае хочется иметь одну, т.к. по сути действие выполняется одно и то же. Поэтому обычно в таком случае классам А и B дают интерфейс Printable, и создают интерфейс Printer с методом print(Printable $printable), который реализуют APrinter и BPrinter. Таким образом, на уровне абстракции мы получаем общее api, а на уровне реализации оставляем две разные логики. Что гуд, но DRY тут не причем.

В качестве примера получше можно придумать класс PostService, абстрагирующий crud и дающий наружу в т.ч. методы store($post) и update($post), которые на самом деле имеют одинаковый бойлерплейт. Когда отсутствует бизнес-логика, оба метода выглядят идентично, т.к. просто реализуют какую-то валидацию входных параметров, сгружают пост в базу данных и т.д., Действительно, возникает соблазн объединить их в общий метод, например, save($post), чтобы избежать дублирования кода.
Но в реальности создание и обновление объекта - это две принципиально разные операции, которые тем дальше друг от друга, чем больше бизнес-логики нужно реализовать. Именно поэтому они должны быть реализованы отдельно друг от друга, несмотря на похожесть и существование DRY.

Такие дела. 🍂