git bisect - Определяем, в каком коммите появился баг
Найти конкретный коммит, который вызвал регрессионную ошибку в проекте
git bisect start # Начать поиск нужного коммита
git bisect good commit0001 # Ввести коммит, при котором бага не было
git bisect bad commit9999 # Ввести коммит, при котором баг есть
# --- начинается поиск бага
# Теперь нужно проверить выбранный коммит:
git bisect bad # если баг остался
git bisect good # если бага нет
# --- когда нашли нужный коммит, необходимо выйти из режима bisect
git bisect reset
Вы продолжаете тестировать выбранные коммиты, каждый раз указывая good или bad. При этом диапазон подозреваемых коммитов уменьшается в два раза на каждом шаге. После нескольких шагов (не более 10-11 для 2088 коммитов) git bisect сообщает, что нашел первый коммит, в котором появился баг:
commit1234 is the first bad commit
commit commit1234
Author: Some Person
Date: Wed Oct 16 13:43:01 2024 -0400
[commit message]
За опечатку спасибо большое, поправлю, за создание лучше на мой взгляд можно использовать сервис по созданию сущности из которой будет запрос в бд на уникальность например тайтла и уже создание через фабрику(принимает уже валидные данные) сущности
Насчет название и смысла - так может показаться, если прийти к ValueObject через интуицию(то есть не прибегая к специализированному материалу). Например логика может быть такая: переводится как объект значение - ну тут все понятно)) Пойду кодить)))
Что же касается смысла, причин использования и примеры на мой взгляд интересных реализаций - это можно подсмотреть в книге Вон Верон "Предметно-ориентированное проектирование". Там достаточно подробно это все описано.
Опять же это мое видение. А что касается конкретного названия - смею предположить, что нужно было как то назвать этот подход и тут "Объект-значение" в контексте архитектурного подхода и в контексте синтаксиса выбранного языка программирование - может означать разный смысл. В первом случае(контекст подхода) - это осмысление текущего объекта со стороны бизнес логики Во втором случае(контекст синтаксиса ЯП) - можно предположить, как раз таки, что у объекта есть какое то значение и ни про какую бизнес логику или осмысление тут уже речь не идет.
И закончу ответ фразой: "Отвергаешь - предлагай". То есть, какое название с Вашей точки зрения - было бы удачное?
Насчет замечания по поводу исключений - такой подход так же имеет место быть. Я же хотел - как можно максимальнее сосредоточить статью на DTO и VO. Что бы все внимание досталось именно им.
Что же касается - логирования - в текущем контексте - это был лишь инструмент для того, что б показать абстрактный пример обработки исключения на одном из слое. Возможно нужно было - подобрать немного иную абстракцию.
У DDD подобный подход, и у луковой архитектуры тоже. То есть вышеперечисленные используют подобный общий подход. Думаю Ваше суждение верное, как и если бы сказали, что это DDD - то тоже было бы верно
Отличная статья, хорошие примеры (хотя можно было и побольше) и описание. Полностью поддерживаю автора. Заранее хотелось бы добавить, что для ее понимания для начала надо понять сам SOLID, а уже потом то, что не нужно его везде вставлять. Хочется сделать отсылку к фильму "Всегда говори да".
git bisect - Определяем, в каком коммите появился баг
Найти конкретный коммит, который вызвал регрессионную ошибку в проекте
Вы продолжаете тестировать выбранные коммиты, каждый раз указывая good или bad. При этом диапазон подозреваемых коммитов уменьшается в два раза на каждом шаге. После нескольких шагов (не более 10-11 для 2088 коммитов) git bisect сообщает, что нашел первый коммит, в котором появился баг:
За опечатку спасибо большое, поправлю, за создание лучше на мой взгляд можно использовать сервис по созданию сущности из которой будет запрос в бд на уникальность например тайтла и уже создание через фабрику(принимает уже валидные данные) сущности
Насчет название и смысла - так может показаться, если прийти к
ValueObjectчерез интуицию(то есть не прибегая к специализированному материалу).Например логика может быть такая: переводится как объект значение - ну тут все понятно)) Пойду кодить)))
Что же касается смысла, причин использования и примеры на мой взгляд интересных реализаций - это можно подсмотреть в книге Вон Верон "Предметно-ориентированное проектирование". Там достаточно подробно это все описано.
Опять же это мое видение.
А что касается конкретного названия - смею предположить, что нужно было как то назвать этот подход и тут
"Объект-значение"в контексте архитектурногоподходаи в контекстесинтаксисавыбранного языка программирование - может означатьразный смысл.В первом случае(
контекст подхода) - этоосмыслениетекущего объекта со стороныбизнес логикиВо втором случае(
контекст синтаксиса ЯП) - можно предположить, как раз таки, что у объекта естькакое то значениеи ни про какую бизнес логику или осмысление тут уже речь не идет.И закончу ответ фразой: "Отвергаешь - предлагай". То есть, какое название с Вашей точки зрения - было бы удачное?
Насчет замечания по поводу исключений - такой подход так же имеет место быть. Я же хотел - как можно максимальнее сосредоточить статью на DTO и VO. Что бы все внимание досталось именно им.
Что же касается - логирования - в текущем контексте - это был лишь инструмент для того, что б показать абстрактный пример обработки исключения на одном из слое. Возможно нужно было - подобрать немного иную абстракцию.
'empty' поправил(убрал) - спасибо, Вы правы)
У DDD подобный подход, и у луковой архитектуры тоже. То есть вышеперечисленные используют подобный общий подход. Думаю Ваше суждение верное, как и если бы сказали, что это DDD - то тоже было бы верно
Отличная статья, хорошие примеры (хотя можно было и побольше) и описание. Полностью поддерживаю автора. Заранее хотелось бы добавить, что для ее понимания для начала надо понять сам SOLID, а уже потом то, что не нужно его везде вставлять. Хочется сделать отсылку к фильму "Всегда говори да".