Советы по дизайну для PHP-функции Включение файлов - PullRequest
Новая
       4

Советы по дизайну для PHP-функции Включение файлов

4 голосов
/ 02 марта 2009

Хороший дизайн требует написания каждой функции только один раз. В PHP я делаю это с помощью включаемых файлов (таких как Utils.php и Authenticate.php) с помощью команды PHP include_once. Однако я не смог найти какие-либо стандарты или лучшие практики для включаемых файлов PHP. Что бы вы предложили в StackOverflow?

Я ищу:

  • Стандарты именования
  • Стандарты кодов
  • Шаблоны проектирования
  • Предложения по определению типов возвращаемых общих функций (сейчас я просто использую ассоциативные массивы).

Ответы [ 4 ]

7 голосов
/ 02 марта 2009

Одно соглашение, которое мне нравится использовать, заключается в том, чтобы поместить каждый класс в свой собственный файл с именем ClassName.class.php, а затем настроить автозагрузчик для включения файлов классов. Или иногда я помещаю их все в подкаталог классов / классов и просто называю их ClassName.php. Зависит от того, сколько я ожидаю от класса против внекласса.

Если вы организуете свои служебные функции в классы и вместо этого делаете их статическими методами, вы можете избежать записи только 10000 * require_once () в файлы верхнего уровня. Этот подход может или не может быть подходящим для вашего кода или стиля кодирования.

Что касается возвращаемых типов, я стараюсь следовать соглашениям, используемым во встроенных функциях. Вернуть тип, соответствующий запросу, или вернуть false при ошибке. Просто убедитесь, что вы используете оператор === при проверке на ложность в результатах.

Тот факт, что вы обеспокоены условностями, говорит о том, что вы уже на правильном пути. Если вы знакомы с любым другим языком ООП, таким как Java, C ++, C # и т. Д., Вы обнаружите, что можете следовать многим тем же соглашениям благодаря ООП в PHP5 .

3 голосов
/ 02 марта 2009

Какое бы соглашение о присвоении имен вы ни использовали (я предпочитаю брать подсказки с Java или C #, где это возможно), убедитесь, что вы используете включаемые файлы для функций, которые на самом деле не выполняют никакого кода при включении, и никогда не включайте один и тот же файл дважды. (используйте include-Once или require-Once )

2 голосов
/ 02 марта 2009

Некоторые такие стандарты уже написаны. Большинство крупных проектов будут следовать своим собственным стандартам.

Вот один, написанный Zend и являющийся стандартом, используемым в среде Zend. http://framework.zend.com/manual/en/coding-standard.html

Кроме того, у PEAR всегда были довольно строгие стандарты кодирования: http://pear.php.net/manual/en/standards.php

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

0 голосов
/ 02 марта 2009

Я сделал следующее. Сначала я создал фильтр перехвата, для перехвата всех веб-запросов, я также создал версию, которая будет работать с командами командной строки.

Оба перехватчика будут отправлены в файл загрузочной ленты, который настроит автозагрузчик. Этот файл как функция автозагрузки и хеш. Для хэша ключ - это имя класса, а значение - путь к файлу класса. Функция автозагрузки просто берет имя класса и запускает требование для файла.

Несколько советов по производительности, если они вам нужны, используйте одинарные кавычки при определении файла, так как они немного быстрее, так как они не интерпретируются, также используйте require / include вместо их версий _once, это гарантированно работает один раз, а первый немного быстрее.

Вышеприведенное замечательно, на самом деле, даже с большой базой кода и множеством классов, хеш не такой большой, а производительность никогда не была проблемой. И что еще более важно, мы не женаты на каком-то сумасшедшем соглашении об именовании классов пространства псевдо-имен, см. Ниже.

Другой вариант - имя с разделителями, трюк с псевдо-пространством имен. Это менее привлекательно, так как пространства имен будут поставляться с 5.3, и я считаю, что это грубо, поскольку переименование их по всей базе кода будет менее увлекательным. Независимо от того, как это работает, примите рут для всего вашего кода. Затем все классы именуются на основе обратного пути в каталогах, необходимого для того, чтобы попасть туда, и разделяются символом, таким как '_', а затем имя самого класса, однако имя файла будет названо в честь класса. Таким образом, местоположение класса кодируется в имени, и автозагрузчик может использовать это. Проблема с этим методом, кроме действительно_long_crazy_class_names_MyClass, заключается в том, что при каждом вызове выполняется немало обработки, но это может быть преждевременной оптимизацией, и снова появляются пространства имен.

например. 

/code root
ClassA ClassA.php
  /subfolder
  subFolder_ClassB ClassB.php
...