Шаблоны проектирования и инкапсуляция для процедурного программирования?
Я работаю над довольно большим проектом PHP, написанным в процедурном стиле (он был написан до PHP 5), и я не могу не чувствовать, что некоторые вещи, которые я делаю, немного "хакерские". Модификация в другом месте может легко сломать приложение. Все шаблоны проектирования и лучшие практики, которые я видел, похоже, применимы только к ООП. Я мог бы начать писать часть своего кода, используя функции ООП PHP 5, но я не уверен, что все остальные разработчики достаточно знакомы с ОП.
Является ли это просто природой процедурного программирования, чтобы казаться "хакерским" людям, более знакомым с ООП? Существуют ли книги "лучшие практики", в которых рассказывается о том, как поддерживать большие процедурные приложения в рабочем состоянии и снижать вероятность появления новых ошибок?
Я знаю, что мог бы применить принципы/шаблоны проектирования ООП процедурным способом, но если бы я собирался это сделать, я мог бы просто использовать функции ООП PHP. Может быть, я просто недостаточно хорошо понимаю процедурная парадигма?
2 answers
Процедурное программирование, особенно в PHP, не имеет конкретного понятия "инкапсуляции" - все доступно, просто не ваша задача его изменять, поэтому вы этого не делаете. Для тех, кто не знает ничего, кроме ООП, или кого учили, что процедурный код - это БААААААД, да, это может выглядеть халтурно и неправильно. Но люди делают это уже ДАВНО, и это действительно работает.
Теперь столь же вероятно, что вы нашли какой-то ДЕЙСТВИТЕЛЬНО плохой процедурный код. Там его столько же так как есть плохой код ООП.
Основные методы для процедурного кода не сильно отличаются от ООП - по возможности избегайте глобальных функций, группируйте связанные функции вместе и старайтесь, чтобы они были короткими. На самом деле "шаблонов" как таковых не существует, поскольку процедурное программирование предшествует движению шаблонов на несколько десятилетий. Но чистый процедурный кодекс не обязательно должен быть таким уродливым, как хотели бы заставить вас поверить фанатики ООП.
Мой процедурный кодекс на самом деле выглядит довольно уныло. Довольно часто у меня есть функции, которые передают составную структуру, например, $page. И это сделало бы довольно простым переход любого set_title ($страница, $заголовок) в $страница->set_title($заголовок), если это необходимо. Это просто другая нотация, нет никакой практической разницы в том, чего достигают эти методы.
Шаблоны проектирования - это широкая область. Безусловно, есть вещи, которые будут выглядеть глупо, если их применить к процессуальному кодексу. И, честно говоря, некоторые Шаблоны проектирования ООП также не очень разумны в коде, основанном на классах. Но если есть четкий вариант использования для переписывания унаследованной базы кода, попробуйте. Я сомневаюсь, что у ваших коллег-копрограммистов аллергия на объектно-структурированные интерфейсы.
Звучит так, как будто проблемы в вашем приложении проистекают из устаревшей и запутанной структуры. Если он был написан в стиле PHP3, например, все еще использует $HTTP_GET_VARS, то не пытайтесь. Если, однако, это просто глобальные переменные и независимое состояние кода, то привнесение некоторой объектной структуры выполнимо.
PS: Глобальные переменные: Синглеты в ООП - это просто чрезмерно сложные глобальные переменные. Большинству приложений требуется набор настроек конфигурации (просто считывайте, никогда не записывайте). Они принадлежат глобальному объекту или массиву. Все остальное опасно.