Шаблоны проектирования и инкапсуляция для процедурного программирования?

Question

Я работаю над довольно большим PHP-проектом, написанным в процедурном стиле (он был написан до PHP 5), и я не могу не чувствовать, что некоторые вещи, которые я делаю, немного "хакерские"."Модификация где-то еще может легко сломать приложение.Кажется, что все шаблоны проектирования и лучшие практики, которые я видел, применимы только к ООП.Я мог бы начать писать часть своего кода с использованием функций ООП в PHP 5, но я не уверен, достаточно ли хорошо знакомы все другие разработчики с ООП.

Это просто природа процедурного программирования, чтобы казаться "хакерской"людям, знакомым с ООП?Существуют ли книги по «передовому опыту», в которых рассказывается о том, как обеспечить поддержку больших процедурных приложений и снизить вероятность появления новых ошибок?

Я знаю, что могу применять принципы / шаблоны разработки ООП процедурным способом, но еслиЯ собирался сделать это, я мог бы просто использовать функции ООП PHP.Может быть, я просто недостаточно хорошо понимаю процессуальную парадигму?

Answer 1

Процедурное программирование, особенно в PHP, не имеет конкретного понятия «инкапсуляция» - все доступно, его модификация - не ваша задача, так что нет.Для тех, кто ничего не знает, кроме ООП, или их учили, что процедурный код - это BAAAAAAD, да, он может выглядеть хакерским и неправильным.Но люди занимаются этим ДЛИННОЕ время, и оно работает.

Теперь, также вероятно, что вы нашли ФАКТИЧЕСКИ плохой процедурный код.Их столько же, сколько и плохого ООП-кода.

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

Answer 2

Мой процедурный код на самом деле выглядит довольно на ура. Довольно часто у меня есть функции, которые передают сложную структуру, например $ Стр. И это сделало бы довольно простым преобразование любого set_title ($ page, $ title) в $ page-> set_title ($ title) при необходимости. Это просто другое обозначение, нет практической разницы в том, что выполняют методы.

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

Звучит так, как будто проблемы в вашем приложении проистекают из устаревшей и запутанной структуры. Если это было написано в стиле PHP3, например все еще использует $ HTTP_GET_VARS, тогда не пытайтесь. Однако, если это всего лишь глобальные переменные и независимое от кода состояние, то можно добавить некоторую объектную структуру.

PS: Глобальные переменные: синглтоны в ООП - это слишком сложные глобальные переменные. Большинству приложений нужен массив настроек конфигурации (просто читайте, никогда не пишите). Они принадлежат глобальному объекту или массиву. Все остальное опасно.