Tell don't ask + trust

Идея проекта зародилась из принципа Tell don't ask. Оригинальная версия принципа говорит о том, что мы не должны принимать решение какой метод объекта вызывать на основе данных от этого объекта, а должны просто сказать объекту, что он должен сделать

Этот принцип натолкнул на размышления о том, как на самом деле объекты в программе общаются друг с другом. Когда объект А вызывает метод объекта B и ожидает результат, который будет возвращен методом объекта B через return, такая организация кода заставляет объект B отвечать даже в те моменты, когда у объекта B нет какого-то хорошего, значащего результата

Такая ситуация при использовании return заставляет объекты подобные B возвращать не полные результаты или вообще не возвращать результаты. Например, если объект B работает асинхронно, обращаясь к серверу, то объект B не может вернуть значение в условиях JS. Объект B может вернуть только Promise - обещание того что значение будет когда-то позже, но проблема в том, что сам объект B больше не отвечает за этот результат, результат может вернуться, а может и не вернуться, даже если мы обработаем ошибку с помощью catch мы все равно обязаны что-то отвечать ожидающему объекту, что - то не значащее, что нужно будет перепроверять, а следовательно доверие к объекту B пропадет, каждый его ответ нужно проверять

Также возможна ситуация, что у объекта B просто нет ответа и нам приходится возвращать null, а null переносит ответственность на объект который общается с объектом B. И получается что с объектом B уже общаться не приятно, потому что он не может гарантировать результат, его все время нужно перепроверять, никто ему не доверяет

Responsible

Всё что описано выше под заголовком Tell don't ask говорит нам о том, что хороший объект должен уметь отвечать за те результаты, которые другие объекты ожидают от него получить. И чтобы реализация этой ответственности за результат стала возможной - объект у которого результат есть должен видеть того, кому этот результат нужен, чтобы полностью контролировать отдачу результата своему посетителю Вокруг этой ключевой идеи и построена вся библиотека. Посетители объекта делятся на гостей - те кому сообщить значение нужно один раз и забыть о нем пока он сам не вернется если захочет и патроны - те кому нужно постоянно сообщать о новых значениях, пока они сами не решат удалиться из пула патронов

Result

Из того что написано под заголовком Responsible можно сделать вывод что использование Библиотеки Patron накладывает на вас ограничение - не использовать return, а вместо этого возвращать данные посетителю вызывая его метод give, либо пользуясь отдельной функцией give

Но в этом разделе(Result) хотелось бы отметить еще одну важную философскую основу, на которую идет опора при разработке на библиотеке Patron. Классы(статический код class) которые мы создаем считаются результатом который нам нужен по нашей логике, позже при создании объекта из класса мы получаем частично примененную версию класса тот же класс с привязанными данными к нему и позже, чтобы получить конкретный результат вычисления в виде данных нам нужно вызвать метод объекта. Последовательность описанная в предыдущем предложении противоположна процедурной последовательности выполнения - сначала вычисление потом результат. Программируя в ООП стиле мы имеем результаты раньше чем происходит вычисление. Наши классы и есть представления нужных нам результатов. Эта идея считается ключевой для понимания принципа разработки последующего кода. Мы создаем большой результат, потом создаем результаты поменьше нужные большому, и так далее пока не опишем наше приложение. Пирамида результатов строится сверху вниз от самого важного для нашей бизнес логики к менее важному и более конкретному (конкретность тут в смысле относящийся к вычислению на компьютере)

Посетитель + Наблюдатель

Можно сказать, что библиотека Patron построена на основе(или вдохновлена) двух паттернов(или двумя паттернами) ООП: Наблюдатель и Посетитель. Объекты имеющие данные не отдают их неизвестно кому (оператором return), а вместо этого ждут посетителя и отдают данные вежливому посетителю который пришел и представился Посетитель может представиться патроном, что для объекта источника данных будет значить что в случае если у этого объекта будут новые данные, то патрону будет интересно об этих данных узнать. Общение между объектами происходит уважительно, никто никого не использует и не принуждает давать ответы. Если источнику данных нечего сказать, то он может просто молчать и не давать бесполезные ответы

Потребители и Источники

Библиотека выделяет две основные категории классов. Первая - потребители это классы или функции совместимые с интерфейсом GuestType , этой категории нужны данные. Вторая источники - эта категория имеет данные и может отдать их потребителю, источники совместимы с интерфейсом SourceType

Хороший пример разделения на потребители и источники это классы для описания REST, например запросы с методом GET это источники данных, потому что могут отдать данные после получения ответа от сервера, а запросы с методами PUT, POST, DELETE это потребители, потому что могут совершить действие после получения данных.