Изящные методы на “случайных служебных функциях”, [закрытых]
5 ответов
Я стараюсь вообще избегать декларирования функций в глобальном пространстве имен. Очень редкие случаи, когда я это делаю, это когда добавляю пользовательские реализации функций, которые не входят в мою версию PHP, например
if(false === function_exists('lcfirst'))
{
function lcfirst( $str ) { /* ... */}
}
Functions like this could go in a compatibility.php, который будет включен в файл bootstrap, так что они доступны во всем приложении, и проверка function_exists гарантирует, что я не столкнусь с проблемами после того, как версия PHP будет иметь нативную поддержку этой функции.
Для всех остальных функций я бы сначала попробовал посмотреть, не могут ли они перейти на выделенный объект. Обычно "случайные" функции просто неуместны. Посмотрите, какие объекты используют функции вашей утилиты, а затем посмотрите, можно ли переместить туда методы. Может быть, там есть суперкласс, который ждет выхода. Также смотрите Information Expert pattern .
Если нет объектов, которые эти методы могут продолжать, то их все равно можно сгруппировать в статическом модуле с именем Utils в уникальном пространстве имён, чтобы они не загромождали глобальное пространство имён. Таким образом, вы можете быть уверены, что не столкнетесь с другими сторонними функциями в глобальном пространстве имён.
До версии 5.3 я бы сгруппировал их , следуя конвенции об именах PEAR и префиксом имен классов, следуя структуре ваших папок, например, если бы модуль находился в com/mattmueller/utils.php, вы бы использовали
class Com_MattMueller_Utils
{
public static function something($a, $b) { /* ... */ }
}
Начиная с PHP5. 3, у нас есть реальные пространства имен и вы можете сделать
namespace com\mattmueller\Utils;
class Utils
{
public static function something($a, $b) { /* ... */ }
}
В Javascript вы не имеете пространств имен, но можете легко имитировать их добавлением функций в объект, например
// JavaScript
var com = (com) ? com : {};
com.mattmueller = {
'Utils': {
'something' : function(a,b) { /* ... */ }
}
};
Обычно общие фреймворки также реализуют функции для создания пространств имен.
В JavaScript создайте новый файл и сгруппируйте его под объектом
global.js :
/* Function definitions */
var myFunctions = new Object();
myFunctions.func = function () {
alert("hello");
}
Та же идея может быть использована для PHP. Благодаря этому вам не нужно беспокоиться о конфликтах в соглашениях об именах, когда ваша программа становится больше.
Для Javascript я обнаружил, что первым выбором должна быть интеграция моих утилит в jQuery. Это так же просто, как написать любую другую функцию, а когда все становится сложнее, здорово иметь возможность использовать парадигму, которую jQuery накладывает на все (и на весь мой другой код для конкретной страницы на сайте).
Я обычно резервирую functions.php или common.php для всех моих странных функций, которые должны иметь в идеале было в первую очередь на PHP. (Имеется в виду, совсем не относящийся к моему проекту).
Это может быть что-то вроде расширения стандартной функции на многомерные массивы или что-то еще, что подходит к этой категории.
Когда я меняю проект, я просто копирую этот файл в следующий проект, и он может легко пойти со мной куда угодно. Затем я просто убеждаюсь, что он загружен в мой скрипт загрузки, и я успешно расширил язык.
Для конкретных проектов я использую класс Misc , который содержит действительно странные вызовы функций, которые, в то же время, относятся к конкретному проекту.
Я могу представить, что к функциям Javascript применимо то же самое. Если вы хотите создать файл типа functions.js или global.js , вы, вероятно, можете использовать ту же логику.
Я всегда использую вспомогательный класс, куда могу поместить весь свой не ООП код, LOL. Я имею в виду, что это путь помощников, которые все еще являются OOO и имеют методы вместо функций, с тем преимуществом, что вы можете организовать свои функции в разрозненных помощниках. Например, StringHelper, DBHelper и т.д..