Начало: клик
Помедитировал над этим и пришел к тому, что вообще-то такая абстракция это неплохой контракт или декларация того, что делают разработчики, особенно если их много и у них разный уровень понимания проекта.
Разбиваю по фактам себя январьского, смотреть без регистрации и смс.
Мне иррационально не нравилось отсутствие абстракций, я это рационализировал. Смотрите.
1️⃣ У объекта итак должны существовать свойства, в противном случае что-то поломается. И как будто бы не надо дополнительно навешивать на него декларацию, ведь если свойства не будет, то мы узнаем что оно должно быть? Но поломка это нехороший случай, и новичку/агенту который этим занимается будет трудно найти и понять причину поломки. Лучше явно прописать правила. Можно это сделать в доке, но доку сложно держать актуальной, а код удобен для чтения и там еще компилятор/тайпчекер напинает если сделать что-то неправильно. А если новичок нарушит правила и решит поменять контракт, то есть абстракцию, то это сразу же вскроется на ревью. Так мы даем новичку/ai-агенту комфортное и безопасное место, в котором он может сделать свою таску. Ну и вообще явное лучше неявного же.
2️⃣ Совсем не обязательно писать супер универсальную абстракцию с максимально широким применением. Допустим, у вас есть какой-нибудь класс DatabaseOperator, это абстракция. От неё наследуется PostgresOperatorImplementation. Первый класс - это декларация того, как все должно выглядеть чтобы это было удобно использовать; второй класс - уже реализация, он наследуется от первого.
И есть мысль, которой хорошо моет мозги слоистая архитектура: нужно иметь возможность заменить слой на аналогичный в любой момент. Не могу сказать, что она совсем плохая, но здесь она неприменима, потому что этот принцип создавался для другого. Как часто надо поменять БД на абсолютно любую, включая NoSQL-базы? - Примерно никогда.
Но если вам действительно нужно поменять БД, о чём вы будете думать: о переносе данных и тп или о том, что в коде надо поменять пару строк? - Наверное, всё-таки о первом, первое вызовет больше сложностей, а значит такая абстракция нерациональна и бессмыслена.
Поэтому, дорогой разработчик, ну давай сделаем класс который декларирует взаимодействие с конкретным postgres: PostgresOperator и PostgresOperatorImplementation. Никаких архитектурных проблем, которые вырастут в потерю контроля над масштабируемостью это не вызовет, просто ну вот такой у нас проект - работает только с постгресом. А если всё-таки поменяем postgres на MySQL, то изменим пару методов и название. Теперь у нас есть декларация методов без переусердствования с абстракциями.
P.S. И надо сабнуться на тгк: https://t.me/dmkjfss
Top comments (0)