Как лучше организовать код (проектирование, работа с функциями)?

@useruser · Регистрация: 29.06.2015

Студворк — интернет-сервис помощи студентам

По мере изучения php, написанию все больших и сложных проектов, возникает все больше вопросов по организации кода.
Я решил объединить несколько небольших вопросов в одну тему т.к. они имеют общий смысл - организация кода, логики в проекте. Наверно это уже проектирование.

1 Пространства имен. Как правильно их задавать?
Стандарт PSR (0-4) говорит нам

Code
1
 \<Vendor Name>\(<Namespace>\)

Пример

PHP
1
namespace Foo\Bar\subnamespace;

Причем во многих учебниках написано, что пространство имен должно повторять структуру каталогов.
Тем не менее в некоторых проектах я видел, что это не так.

Как я делаю сейчас.

В каталоге site есть 2 каталога modul1 и modul2.
В каталоге modul1 есть файл functions.php
В каталоге modul2 есть файл functions.php
Тогда в каталоге modul1, в файле functions.php я задаю пространство имен так

PHP
1
namespace site\modul1\functions;

Что мне не нравится. Я не соблюдаю стандарт - а именно надо писать пространства с заглавной буквы.
Но у меня имена каталогов прописными. И с заглавной мне не надо. Не состыковка.

2) Функции.
Разумеется, хочется писать "самодостаточные" функции.
Т.е. требующие минимальное количество данных на входе. Меньше думать, меньше кода - своего рода волшебство.
Вызвал - а как дальше, пусть она сама всё там делает, ищет что надо и т.д. Универсальное решение под все ситуации.

Пример (псевдокод)
Функция пишет лог. А именно вставляет в базу id пользователя и код ошибки.

Вариант 1. На входе только код ошибки.

PHP
1
2
3
4
5
function write_log($code)
{
//Тут определяем  id пользователя (запрос к базе, например)
//Тут пишем в БД id пользователя и код ошибки
}

Удобно, универсально. Нам действительно нужно передавать только код ошибки.

А теперь представим, что у нас такой код проекта (псевдокод)

PHP
1
2
3
//Тут определяем id пользователя (запрос к базе, например)
//Проверяем id пользователя - для чего либо
write_log($code);

Уже не оптимально. У нас в коде выше уже есть "определяем id пользователя (запрос к базе, например)" и в функции тоже есть "определяем id пользователя (запрос к базе, например)" .

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

PHP
1
2
3
//Тут определяем id пользователя (запрос к базе, например)
//Проверяем id пользователя - для чего либо
write_log($code, $user_id);

Оптимально.
И код функции будет таким.

PHP
1
2
3
4
function write_log($code, $user_id);
{
//Тут пишем в БД id пользователя и код ошибки
}

Но функция потеряла универсальность. И её вызов обяжет нас в любом файле определять id пользователя.
Что делать? Плодить кучу подобных функций - c id, без id? Неясно.

3) Аргументы функции.
Пусть есть такая функция (псевдокод)

PHP
1
2
3
4
function test($a, $b, $c, $d, $e, $f, $g);
{
//Код функции
}

Её вызов

PHP
1
test('some text 1', 'some text 2', 'some text 3',  'some text 4',  'standart text 1',  'standart text 2',  'standart text 3');

Длинно, не красиво.

Предположим, что в 90% при вызове функции последние аргументы всегда будут 'standart text 1', 'standart text 2', 'standart text 3'.
Тогда

PHP
1
2
3
4
function test($a, $b, $c, $d, $e='standart text 1', $f='standart text 2', $g='standart text 3');
{
//Код функции
}

И вызов

PHP
1
test('some text 1', 'some text 2', 'some text 3',  'some text 4');

Красиво, писать меньше. Но во многих языках так не принято. Да и логика становится не такой четкой - нет явного указания аргумента. Потом, например, можно и забыть а что она там делает - в смысле что там по умолчанию передается?
Как тут быть?

@Jewbacabra · 30.01.2019, 11:43

useruser, речь именно о функциях (процедурном подходе), не ООП?

@useruser · 30.01.2019, 12:02 **[ТС]**

Сообщение от Jewbacabra

useruser, речь именно о функциях (процедурном подходе), не ООП?

Написал как есть. Мне самому пока сложно понять. Иду к ООП.
При очередной разработке проекта встали вот такие вопросы.
Пока решил всё организовать с помощью функций и пространства имен. такое разделение.

Также пока не понятно, как организовывать - разделять функции. По какому признаку?
Та же функция логирования пишет в бд логов. Скорее всего все функции связанные с логированием нужно поместить в один файл с

Code
1
namespace site\logs

И вызывать

PHP
1
site\logs\write_log($code);

С другой стороны, эта функция обеспечивает безопасность - аудит отказов например. И её нужно поместить в другой файл функций

Code
1
namespace site\security

И эту функцию будут использовать и другие модули. И подобные функции могут использовать кучу баз.
Становится вообще непонятна организация проекта.
Но это уже отдельный вопрос...

@estic · 30.01.2019, 14:08

Это деление было придумано прежде всего для совмещения кода из разных библиотек разных разработчиков. Для чего-то масштабного наподобие фреймворков можно использовать деление фреймворк-компоненты, что по сути то же самое, т.к. здесь "фреймворк" - бренд, ассоциируемый с вполне конкретной группой разработчиков. Если код пока не рассчитан на массовое повторное использование, можете использовать ваше деление сайт-модуль или вообще не делать никакой унификации собственных библиотек под массовые "стандарты". И PSR изначально под ООП писались. Когда дойдете, можно будет предметно обсуждать. Если не дойдете, ничто не мешает совмещать код, написанный по "стандартам", со своим.

@useruser · 30.01.2019, 14:46 **[ТС]**

Сообщение от estic

PSR изначально под ООП писались

Это мне нужно. Например в плане пространств имен. Проект модульный.
Бывает, что часть модулей из старого проекта, включается в новый. В новом - старые и новые функции.
В старом - только старые. Что то чистить и искать - долго.
Подключаем оба файла без пространств имен - конфликт т.к. имена функций совпали.
А так новый проект - новый вендор. И всё хорошо.

Пространства имен действительно необходимость. Хотя раньше писал вендора как префикс функции.

@estic · 30.01.2019, 15:48

Сообщение от useruser

А так новый проект - новый вендор. И всё хорошо.

Я для кого писал предыдущее сообщение? Вендор - это прежде всего разработчик. Для несложных проектов собственное пространство имен по большому счету не нужно, но можно использовать что-нибудь обобщенное, например App или Site, с дальнейшим делением по модулям или без. Со временем, если специально написанный для проекта код будет повторно использоваться, формируйте из него библиотеку Useruser\Superlib. Сразу это делать необязательно.

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Обработчик клика мыши в браузере ПК и касания экрана в браузере на мобильном устройстве 8Observer8 02.02.2026 Содержание блога Для начала пошагово создадим рабочий пример для подготовки к экспериментам в браузере ПК и в браузере мобильного устройства. Потом напишем обработчик клика мыши и обработчик. . .	Философия технологии iceja 01.02.2026 На мой взгляд у человека в технических проектах остается роль генерального директора. Все остальное нейронки делают уже лучше человека. Они не могут нести предпринимательские риски, не могут. . .	SDL3 для Web (WebAssembly): Вывод текста со шрифтом TTF с помощью SDL3_ttf 8Observer8 01.02.2026 Содержание блога В этой пошаговой инструкции создадим с нуля веб-приложение, которое выводит текст в окне браузера. Запустим на Android на локальном сервере. Загрузим Release на бесплатный. . .	SDL3 для Web (WebAssembly): Сборка C/C++ проекта из консоли 8Observer8 30.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .
SDL3 для Web (WebAssembly): Установка Emscripten SDK (emsdk) и CMake для сборки C и C++ приложений в Wasm 8Observer8 30.01.2026 Содержание блога Для того чтобы скачать Emscripten SDK (emsdk) необходимо сначало скачать и уставить Git: Install for Windows. Следуйте стандартной процедуре установки Git через установщик. . . .	SDL3 для Android: Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 29.01.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами. Версия v3 была полностью переписана на Си, в. . .	Инструменты COM: Сохранение данный из VARIANT в файл и загрузка из файла в VARIANT bedvit 28.01.2026 Сохранение базовых типов COM и массивов (одномерных или двухмерных) любой вложенности (деревья) в файл, с возможностью выбора алгоритмов сжатия и шифрования. Часть библиотеки BedvitCOM Использованы. . .	SDL3 для Android: Загрузка PNG с альфа-каналом с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 28.01.2026 Содержание блога SDL3 имеет собственные средства для загрузки и отображения PNG-файлов с альфа-каналом и базовой работы с ними. В этой инструкции используется функция SDL_LoadPNG(), которая. . .

@Jewbacabra 4925 / 3920 / 1620 Регистрация: 24.04.2014 Сообщений: 11,441
	30.01.2019, 11:43
	useruser, речь именно о функциях (процедурном подходе), не ООП? 0

@estic 1306 / 998 / 232 Регистрация: 01.10.2018 Сообщений: 3,884
	30.01.2019, 14:08
	Это деление было придумано прежде всего для совмещения кода из разных библиотек разных разработчиков. Для чего-то масштабного наподобие фреймворков можно использовать деление фреймворк-компоненты, что по сути то же самое, т.к. здесь "фреймворк" - бренд, ассоциируемый с вполне конкретной группой разработчиков. Если код пока не рассчитан на массовое повторное использование, можете использовать ваше деление сайт-модуль или вообще не делать никакой унификации собственных библиотек под массовые "стандарты". И PSR изначально под ООП писались. Когда дойдете, можно будет предметно обсуждать. Если не дойдете, ничто не мешает совмещать код, написанный по "стандартам", со своим. 0