Имхо есть простые end-to-end тесты, которые могут помочь контроллировать целостность приложения. Они не так сложны в написании и поддержке, но разные простые вещи типа «изменили формат X но забыли поменать его разбор в Y» могут проверить.
Неважно. «Посылка почты в приложении X» может иметь свою специфику по сравнению с «посылкой почты вообще», каковую специфику полезно выделить в отдельный юнит.
Мы рассматриваем этот мейлер — каковой вызывается статическим методом. Это раз.
А два — ваш мейлер может оборачивать готовый с целью внести специфику приложения (например — добавляет стандартную для приложения подпись и т.д.)
foreach($modifiedObjects as &$object)
{
if ($object -> validate())
{
$object -> save()
}
else
{
$objectsWithErrors -> add($object)
}
}
Процедурный стиль, ООП стиль, функциональный стиль — это лишь инструменты. И не в выборе инструментов дело.
Иногда в них. Я сомневаюсь, что PHP хороший язык для функционального программирования (ленивые вычисления, классы типов, функции как значения первого класса есть?), а ООП в нем уже общее место.
habrahabr.ru/company/eastbanctech/blog/236563/
А в питоне и руби разве нет?
А два — ваш мейлер может оборачивать готовый с целью внести специфику приложения (например — добавляет стандартную для приложения подпись и т.д.)
Where there's muck, there's brass
Pretty much any job that you can get paid for includes dealing with one gnarly problem.
см. hexagonal architecture
Зачем какому-то пользователю регистрировать чье-то другое имя и email — наверное $users -> register($user)?
функциональщики говорят, что у них это тоже есть (type classes)
Способ, конечно же, есть
Итого: мы согласились с тем, что хорошего способа нет.
Нет способа хорошо выделять общий код типа:
Процедурный стиль, ООП стиль, функциональный стиль — это лишь инструменты. И не в выборе инструментов дело.
Иногда в них. Я сомневаюсь, что PHP хороший язык для функционального программирования (ленивые вычисления, классы типов, функции как значения первого класса есть?), а ООП в нем уже общее место.