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

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

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

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


php design-patterns procedural-programming
person ektrules    schedule 11.07.2010    source источник
comment
Проверьте это сообщение: stackoverflow.com/questions/2492446/   -  person Plamen Paskov    schedule 18.04.2012

Ответы (2)


arrow_upward
7
arrow_downward

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

С такой же вероятностью вы нашли ДЕЙСТВИТЕЛЬНО плохой процедурный код. Его столько же, сколько и плохого ООП-кода.

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

person cHao    schedule 11.07.2010

arrow_upward
0
arrow_downward

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

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

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

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

person mario    schedule 11.07.2010
comment
Можно выполнять ООП, даже не сказав класс. Суть процедурного кода не в том, что вы не используете классы; дело в том, что данные - это то, чем нужно манипулировать, а не объекты с собственной идентичностью. GDK довольно объектно-ориентирован и написан на C. - person cHao; 12.07.2010