и? Это примеры, зачем там ООП? Им главное набросать пример использования, а не выстроить архитектуру приложения.

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

Ну я про то, что совсем не обязательно везде использовать ооп. Меня же Ron пытался носом натыкать в Гугл. А я показал, что и Гугл не гнушается другими парадигмами. Там, где это выгоднее, пусть даже в примерах.

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


_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

"пусть даже в примерах" это звучит не убедительно

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

Почему? Давай разберемся. В самом начале примера мы видим это:

$analytics = initializeAnalytics();
$profile = getFirstProfileId($analytics);
$results = getResults($analytics, $profile);

Простые функции, можно сказать - процедурный код. Предположим, что это написано в расчете на меня :) бестолочей, которые не понимают толк в ООП. Однако в первой же функции куча объектов:

  $client = new Google_Client();
  $client->setApplicationName("Hello Analytics Reporting");
  $client->setAuthConfig($KEY_FILE_LOCATION);
  $client->setScopes(['https://www.googleapis.com/auth/analytics.readonly']);
  $analytics = new Google_Service_Analytics($client);

Значит человек, работающий с этим API как минимум должен знать основы ООП. А человеку, знающему основы, лучше сразу показать right way. Оформить все это классом(ами) и вызывать методы, а не функции. Тогда можно было бы сделать все по канонам, по "взрослому". А так что мы видим? Ну ладно инициализация, где то нужно это сделать, никуда не денешься от богомерзкой композиции. Ладно вывод результата, это техническая функция. А как же с основным функционалом? Почему там куча ветвлений, почему повторы кода, почему оформлено не классом? Ну и оформили бы сразу, это же так "по взрослому". Собственно никакой разницы, пользоваться функциями или методами. Аргумент, что это для дурачков, как предположил Ron, не канает. Я вначале написал почему. Кто взялся интегрировать это API, не должен бояться классов как минимум. Так почему? Может в Гугле тоже сидят отсталые прогеры, игнорирующие "новейшие технологии"? Вроде нет. Так чего?

А ответ прост. Это нафиг не нужно, ибо ничего кроме неоправданного усложнения здесь не даст. Кому нужно - сами в класс(ы) засунут, наворотят паттернов, фабрик каких-нибудь и иже с ними. А кому не надо и так вполне годно. Элементарное следование принципам KISS и YAGNI. Которые кстати совсем не обязательно применимы только к ООП.

Ребята использовали тот инструмент, который лучше всего подходит к данной задаче - написать пример. Без оглядки на то, что фанатики скажут - это же говнище!

Так вот я про что и талдычу. Далеко не всегда ООП выгодно и оптимально. И в веб таких вариантов куча, стоит только немного посмотреть по сторонам, снять шоры, которыми вы гордитесь, и которые всячески стараетесь напялить на новобранцев, оправдывая их всякими несуразностями плана - так делают миллионы! Пусть делают, их право. Но не факт, что делают это они верно.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.