Дело в том, что в программировании нет такого понятия "правильно" и "как нужно". Например, у меня есть определенное понимание, какие решения лучше принимать в той или иной ситуации, но вам я свой опыт передать никак не смогу, только если несколько лет буду с вами парным программированием делать проекты и ни на минуту не замолкать. И никто не сможет. Это опыт, его нужно заработать трудом.
Не видел ни одной статьи "10 вещей, которые вы хотели спросить про разработку SPA, но боялись спросить" и сомневаюсь, что они существуют. Чем разработка SPA принципиально отличается от любой другой клиентской разработки?
Вы не прокрастинируйте, а возьмите и попробуйте что-нибудь сделать :) сразу и вопросы конкретные появятся.
Так и работают. Вы объясните толком, в чём ваш вопрос конкретно, потому что "советы не только на этот счет, но и вообще" на этом сервисе не дают, тут на конкретные вопросы отвечают.
Во-первых, нет, не будет. А во-вторых, проблема на самом деле вовсе не в том, что у переменной неправильная область видимости, а в том, что код асинхронный. Заголовок вопроса вводит в заблуждение, но по коду всё становится ясно.
Ну, тут, как бы, до чтения мыслей далеко, в вопросе звучит "в имени файла есть цифры от 0 до 2", а не "в имени файла есть только одна цифра от 0 до 2".
У вас провайдер предоставляет публичный интерфейс. Как и что он делает внутри - это его дело (именно поэтому, например, hasNewsGrabber лучше, чем instanceof).
Поэтому, если у newsGrabber'ов разных соц. сетей разный публичный интерфейс, это не страшно, ведь с каждым конкретным граббером работает конкретный провайдер, который об этом интерфейсе знает.
Что касается трейтов: если вы используете трейты, то это значит, что провайдер проявляет черты авторизатора, парсера новостей и т.п. Но это же на самом деле не так, провайдер, в полном соответствии со своим названием предоставляет доступ к функционалу, а уж сам функционал реализован в отдельных независимых классах.
Преимущества подхода те же самые, что и у следования SOLID-принципам, потому что он именно их и реализует :)
В таком случае, провайдер - это просто фасад-агрегатор, внутри него должен быть authorizer, newsGrabber и т.п. Если все эти функции засунуть в него, то действительно, получится несвязная лапша.
Вот так будет лучше:
foreach($accounts as $account) {
$provider = Manager::getProvider($account);
if ($provider->hasNewsGrabber()) {
$news = $provider->getNews();
//...
} else continue;
}
