Я думаю, дело в том, что, как правило, вы не знаете точно, что вы не будете переопределять это поле или добавлять его позже. Вся суть инкапсуляции и скрытия данных заключается в том, что тогда вы можете делать все это без изменения публичного интерфейса и последующего разбиения зависимых классов. Если ваши аксессоры свойств просто просты, то они все равно будут скомпилированы до этого, так что они не связаны с производительностью - учитывая, что ваш вопрос должен быть, есть ли веская причина не использовать их?
Напишите свой код так, чтобы не смешивать определения и код времени выполнения. Обычно это источник всех «проблем» с включениями.
Это часть стандарта PSR – 1 (поэтому есть инструменты, которые могут автоматизировать проверку этого для вас, например PHP Code Sniffer):
Файлы ДОЛЖНЫ либо объявлять символы (классы, функции, константы) и т. д.) или могут вызывать побочные эффекты (например, генерировать выходные данные, изменять настройки .ini и т. д.), но НЕ СЛЕДУЕТ делать то и другое.
https://www.php-fig.org/psr/psr-1/
blockquote>Напишите свой код с учетом автозагрузки.
Следуйте общепринятым правилам организации кода, проще всего просто использовать pds / skeleton , который уже провел исследование и описывает общий паттерн.
Упакуйте и используйте результат с помощью Composer. Это может показаться «вовлеченным», но, поверьте мне, Composer полностью отрицателен в усилиях. Все, что вы пытаетесь изобрести или сделать «проще», в конечном итоге будет сложнее, чем просто использовать для этого Composer.
Дело не в том, что ваш вопрос не является хорошим или рациональным, просто он не очень подходит для стекового потока. Stackoverflow больше подходит для вопросов конкретного типа программирования. Подробнее об этом вы можете прочитать в разделе сайта «Как задавать вопросы». Считай, что тебе повезло, что ты получил только один голос. Я ожидал бы, что это будет быстро закрыто.
Сказав это, я собираюсь соединить вас с одним из моих собственных грехов и использовать ответ не для того, чтобы ответить на вопрос, а для того, чтобы получить немного больше информации. Я предполагаю, что ваша путаница в основном терминологическая. Твои слова говорят об одном, но я подозреваю, что ты просишь о другом. Это одна из причин, почему stackoverflow любит иметь немного кода в своих вопросах.
В частности:
Операторы php require и include не очень помогают в этом, потому что вы не можете просто поместить несколько блоков функций / кода в файл include / require, по крайней мере, из моего опыта, без создания вспомогательного класса-оболочки.
blockquote>Честно говоря, я не знаю, что вы подразумеваете под "функциями / кодовыми блоками". Очевидно, что это работает:
# functions.php function func1() { echo "func1\n"; } function func2() { echo "func2\n"; } function func3() { echo "func3\n"; } # main.php require_once 'functions.php'; func1(); func2(); func3();
Не требуется «служебный класс-обертка». Но опять же, я уверен, что вы это знаете.
Подумайте над тем, чтобы обновить свой вопрос конкретным примером того, что вы пытались сделать. Даже ваше вступительное заявление об использовании вашего «файла проекта Symfony» очень неясно. У Symfony есть куча файлов, но я не знаю ни одного из них, которые обычно называют файлом проекта.
Ответ Керада заставил меня переосмыслить, как использовать оператор require, особенно там, где его можно использовать. Я обновил свой оригинальный вопрос, чтобы показать, что не сработало, а что сработало. Надеюсь, кто-то, если кто-то еще, кто пропустил эту деталь, как я, мог бы найти этот ответ полезным.
Спасибо всем за отклик.