ну скажем XML

на вход и выход

один класс клиент с тремя публичными методами и возможно больше одного интерфейса. У него будет зависимость которая собирает/разбирает xml

далее зависит от сложности задачи

но в целом если у меня все это будет в одном классе у меня SRP не будет нарушен, так как причина для изменений у меня только одна - что-то поменялось в работе с внешним сервисом

чтобы более конкретно, давай возьмем какой-нибудь FedEx, это для доставки методы: получение размеров коробки на заданные параметры получение ценников на заданную коробку/коробки оформление заказа на доставку коробок

один класс клиент с тремя публичными методами и возможно больше одного интерфейса. У него будет зависимость которая собирает/разбирает xml

собирает и разбирает это 1 класс?

скорее всего да

во всяком случае не имея больше деталей я бы не стал дробить больше

а сам сервис будет заниматься еще отправкой запроса на апи?

или куда-то делегировать?

преждевременное дробление нужно для упрощения жизни в ситуациях, когда ты можешь предсказать изменения

а сам сервис будет заниматься еще отправкой запроса на апи?

зависит от того что ты подразмеваешь. Но да, вся работа с сетью будет зашита в еще один сервис

по поводу "предсказать изменения" - ну мол попробовать представить себе "какие более менее вероятные причины для изменений"

ок, в итоге мы на данный момент имеем класс с 3я публичными методами такими же как и у апи, интерфейсы на каждый метод 2 зависимости: - на парсинг и распарсинг запросов и ответов - на самого клиента который отправляет запросы по http

так?

скажем если ты используешь сервис гугла ты можешь не беспокоиться что они "внезапно" перейдут с tcp на http

или наоборот

а если ты используешь какой-то APNS с наркоманским бинарным API поверх сокетов

опять ты эти богомерзские суффиксы юзаешь... ну да ладно. Тип так

А что плохого в этих суффиксах?

А что плохого в этих суффиксах?

а что хорошего?)

я уже приводил пример почему эти суффиксы плохо

А что плохого в этих суффиксах?

это в кодстайле симфони прописано плохого - они не нужны)

ну то есть это не то что "плохо"....

это лишний информационный мусор

который не дает тебе никакой пользы

@fes0r возвращаясь к теме) как ты на все это дело будешь писать тесты?

а еще ты не можешь взять и заменить класс на интерфейс без грязи в дифе коммитов

у тебя есть дока по апи, примерные запросы и ответы, но тебе не желательно делать заказы на отправку через апи

@fes0r возвращаясь к теме) как ты на все это дело будешь писать тесты?

в смысле? работа с внешним миром у нас изолирована в отдельной фигне. Разбор/сбор xml - отдельная херня

все спокойно мокается

ну вот интересно что и в каком порядке ты будешь тестить

модуль полностью изолирован

ну вот интересно что и в каком порядке ты будешь тестить

я бы начал с основного класса

при помощи моков я бы составил требования к интерфейсам сервисов зависимостей

и покрыл бы их тест кейсами исходя из нужд клиента (ну то есть кода который их юзает)

тесты этого класса будут выглядеть примерно так замокали сервис для парсинга и для клиента который отправляет запросы и на каждый метод - проверяем вызов сервиса для сборки запроса, вызов клиента и опять парсинга. все?

класс же получается ничего кроме этого не делает?

тесты этого класса будут выглядеть примерно так замокали сервис для парсинга и для клиента который отправляет запросы и на каждый метод - проверяем вызов сервиса для сборки запроса, вызов клиента и опять парсинга. все?

а он больше ничего не делает?

не формирует какой-то результат?

ну этим занимается парсер ответа ведь?

ну нет, он просто избавляет от необходимости работы с XML

который не дает тебе никакой пользы

Хз. Лично мне это позволяет быстрее ориентироваться по иерархии файлов проекта и четко понимать, что "вот тут вот у меня завязка на интерфейс, а не реализацию" не переходя к другому файлу.

Хз. Лично мне это позволяет быстрее ориентироваться по иерархии файлов проекта и четко понимать, что "вот тут вот у меня завязка на интерфейс, а не реализацию" не переходя к другому файлу.

пхпшторм уже показывает и без этого где интерфейсы

Хз. Лично мне это позволяет быстрее ориентироваться по иерархии файлов проекта и четко понимать, что "вот тут вот у меня завязка на интерфейс, а не реализацию" не переходя к другому файлу.

А что это тебе дает? Чем плохо если там будет класс а не интерфейс?

да и тебе должно быть пофиг это интерфейс или конкретная реализация

А что это тебе дает? Чем плохо если там будет класс а не интерфейс?

Тем что завязка на конкретную реализацию, а не абстракцию.

Тем что завязка на конкретную реализацию, а не абстракцию.

началось)

refactor -> rename (Catalog -> DoctrineCatalog) refactor -> extract interface (Catalog)

в diff коммита у тебя будет

1 изменение в файле

и один новый файл

а с суффиксами - либо втупую лепить интерфейсы где надо и где нет, либо потом страдать из-за больших diff-ов

late binding это важно конечно, но не тогда когда он тебе не нужен

Значит, видимо, мне не приходилось работать с достаточно сложными проектами, если я не боюсь длинных diff.

late binding это важно конечно, но не тогда когда он тебе не нужен

Я и не говорил, что везде его пихать.

да просто код ревью неудобно делать

Я и не говорил, что везде его пихать.

> Тем что завязка на конкретную реализацию, а не абстракцию.

говорил)

Я не это имел в виду, но ладно. Я с телефона в срач ударяться не хочу. Пока из минусов вижу только diff - и то только если класс на интерфейс поменяли.

еще ты фокусируешься на различиях - интерфейс и класс, хотя разницы нет

у класса есть интерфейс (или контракт который он обязан соблюдать) и без явного указания какого-то интерфейса

интерфейсы как сущность всего-лишь дают тебе возможность объявлять этот контракт вне контекста конкретной реализации

Я это понимаю.

но коду, который будет юзать эти зависимости должно быть глубоко на это насрать

ну у тебя будет либо Catalog, CatalogInterface либо CatalogImpl, Catalog либо CatalogDefault, Catalog но мне чет 1й вариант больше до сих пор нравится)

что что его волнует - это соблюдение некой штукой некого контракта

ну у тебя будет либо Catalog, CatalogInterface либо CatalogImpl, Catalog либо CatalogDefault, Catalog но мне чет 1й вариант больше до сих пор нравится)

приведи более конкретный кейс

наприме штука которая что-то делает

подправил

почему не App\Service\Doctrine\ProductRepository implements Catalog

Блин, как приятно на канале!))

ооок, MergerInterface

ээээм.... он же не тупо мерджит)

ну вот тебе приведу кейс из одного из своих проектов

у меня есть две апишки

там где много реализаций может быть - все просто)

1-ая выдает статистику по продажам в ресторанам, вторая тоже выдает статистику, но уже другую по тем же рестаранам

а там где только 1?

а там где только 1?

но у тебя же есть название апишки?)

ну вот как с Merger, он 1 и хоть убейся)

короч в примере с двумя апишками у меня интерфейс будет что-то типа RestaurantReportProvider

пример с одной апишкой...

ок! UserService)

во

у меня на проекте есть чаты

для них я использую Layer.com

и у меня соответственно есть интерфейсы ConversationRegistry, BanList, BadgeProvider

там где разные адаптеры или несколько стратегий - ок, названия разные в любом случае будут

и класс LayerUsers, LayerConversation

ок! UserService)

что он делает?

пусть будет регать юзера и искать юзера? ок ладно скажешь это 2 интерфейса

прикол в том что спустя 3 месяца разработки мы скорее всего будем пилить свою реализацию этих чатов на ноде и мне придется потом переходить на другие чаты. А на них завязан солидный кусок системы

пусть будет регать юзера и искать юзера? ок ладно скажешь это 2 интерфейса

UserManager

блин

не

просто UserRepository

и DoctrineUserRepository

у меня за регистрацию юзеров всегда отвечает один сервис - RegisterUserHandler