Comments 48
Делайте всё на классах, то есть, все эти файлы которые вы загружаете, делайте в них класс, и после загрузки возвращайте экземпляр загруженного класса.
И вообще мне кажется это не место где стоит задавать такие вопросы. Задавайте их в специализированных форумах. Например винград или пхпклаб.
В моих вопросах есть не только смысл получить ответ. Гораздо важнее изменить направление мысли. Вот видите, только что вы изменили моё мнение, вместо функции использовать объект. Думаю каждый кто заглянул в этот пост сталкивался с самописным фреймворком, пытался его делать, возможно делает. Стало быть это будет всем полезной темой для обсуждения.
Спасибо за ваш совет с классом, но хотелось бы программера который только что подключился к проекту, избавить от объяснения как работать с фреймворком. Грубо говоря, садись, пиши прогу, весь результат выводи в переменную $html[]. Для удобства добавил пару функций и классов, которые можно использовать а можно не использовать… В общем вот.
Спасибо за ваш совет с классом, но хотелось бы программера который только что подключился к проекту, избавить от объяснения как работать с фреймворком. Грубо говоря, садись, пиши прогу, весь результат выводи в переменную $html[]. Для удобства добавил пару функций и классов, которые можно использовать а можно не использовать… В общем вот.
Для этого существуют интерфейсы. даете новому члену команды необходимые интерфейсы и говорите: реши задачу так чтоб в итоге получился класс поражденный от этого интерфейса. В этом случае ему даже не нужно показывать сам фреймвок.
Если сильно нужны глобальные переменные(зачем?) то можно использовать шаблон синглтон, но в 99% лучше понять почему глобальные переменные не нужны.
Если сильно нужны глобальные переменные(зачем?) то можно использовать шаблон синглтон, но в 99% лучше понять почему глобальные переменные не нужны.
С проблемой я сталкнулся когда начал загружать через неё модули. [...] То есть, я не могу в одном модуле назначить переменную, а в другом её использовать.
С проблемой вы столкнулись, когда захотели передавать информацию между модулями без использования специализированного механизма — иными словами, решили использовать абсолютно произвольный протокол обмена.
require_once отлично справляеться сама по себе. Измините архетектуру, откажитесь от использования глобальныйх переменных.
Да, я знаю что require_once справляется. :) Это самый простой выход, но как быть с проверками?
Пока что вариант «откажитесь от использования глобальныйх переменных» самый вероятный. Одна переменная $_G и харе. Модули будут иметь большую абстракцию друг от друга.
Пока что вариант «откажитесь от использования глобальныйх переменных» самый вероятный. Одна переменная $_G и харе. Модули будут иметь большую абстракцию друг от друга.
Одна переменная $_G это не есть отказаться от использования глобальных переменных :)
Не совсем понимаю какой абстракции или гибкости вы пытаетесь добиться(добились) глобальными переменными? Объясните подробнее пожайлуста.
Не совсем понимаю какой абстракции или гибкости вы пытаетесь добиться(добились) глобальными переменными? Объясните подробнее пожайлуста.
Совсем отказаться от глобальных переменных не получится, надо же в View тоже что-нибудь отдать. Все остальные переменные умрут когда модуль обработался. Это и есть некая абстракция модулей. Не смейтесь, пожалуйста ;)
Как вы видите, я стою перед выбором. Вот тут посоветовали расширять классы, тоже отличный вариант, более современный ;)
Как вы видите, я стою перед выбором. Вот тут посоветовали расширять классы, тоже отличный вариант, более современный ;)
то что нужно отдать что либо во View (MVC как я понимаю) ещё не значит что это что то должно быть глобальным. Вы можете в управляющем классе объявить методы для изменения данных, хотя ИМХО правильнее было бы из управляющего класса вызывать методы классов-модулей и получать от них данные и передавать в представление.
«но как быть с проверками?» — без проверок и так и так не обойдешься
К сожелению, хочу вам сообщить, что проблема находится не там где вы ее ищете. Скажем так, ваша проблема состоит не в том, что вы не можете нормально использовать глобальные переменные между модулями, а в том, что вы не знаете как вообще работает «велосипед».
Скажем так, вы пытаетесь использовать такую удобную с первого взгляда вещь, как гвоздь (глобальные переменные) во всех деталях велосипеда, даже не понимая, что если колесо прибить гвоздями, то оно будет крутится отаврительно, если вообще будет. А если мы попытаемся использовать те же гвозди и для велосипедной цепи — то тут уж совсем тяжко будет. Хотя для сидения и руля — они сгодятся не хуже чем шурупы, гайки и болты. Правда если мы захотим поменять руль или сиденье, то придется нам раскорячивать старые гвозди (глобальные переменные), и на место них забивать новые, которые держать будут хуже, и не факт что руль по дороге не отвалится, а на сиденье будет вообще не сташно сесть. А если мы используем большие гвозди, которые пронают несколкьо компонетов сразу — то тут вообще начинается полная жопа, и рука тянется к сварочному аппарату (мы связываем компонентны нашей системы до такой степени, что использовать их отдельно уже врядли когда-нибудь получиться), что неочень хорошо.
А если по существу, то у вас сейчас есть два выхода:
Первый, самый легкий, который реализуется за 20 минут, паттерном Registry реализованным в виде Singleton-а или статического класса с методами set\get\isset\delete. Все глобальные перменные скидываете туда и они становятся доступны из любой точки вашего приложения. В результате имеем тот же набор гвоздей пронизывающих весь наш велосипед, только теперь смена одного гвоздя на другой упрощается, это если мы грамотно все построим. Да и с точки зрения псевдо ооп-шников, прочитавшись пару книг и решившись все заворачивать в классы это будет очень круто, гибко и зачотно.
Второй — потяжелее, и заставит нас потратить не только на несколько порядков больше времени, но еще и денег. Потому что этот способ подразумевает собой долгое обучение в мастерской, где нам покажут какие бывают велосипеды (а они бывают не только децкие, горные и шосейники), где мы поймем что такое руль и для чего он нужен, как работает передняя вилка, как должна выглядеть втулка, из каких материалов лучше сделать раму, почему очень плохо крепить цепь на гвозди, и почему же на bmx-ы все спошь синглспиды (однаскоростные). И вот после того, как мы потратим год или полтора на изучение всего этого материала, пытаясь дома сконструировать свой первый удобный руль, выпелить педаль с шипами, которая бы не травмировала ногу велосипедиста если случайно она слетит и если он по глупости своей не надел защиту (у автора от таких педалей два шрама на левой ноге...). И вот только тогда мы будем готовы собрать свой велосипед, подсматривая и даже воруя идеи у других конструкторов, уже успешных моделей, на которых катает не один десяток тысяч человек.
Так что, выбор за вами…
Скажем так, вы пытаетесь использовать такую удобную с первого взгляда вещь, как гвоздь (глобальные переменные) во всех деталях велосипеда, даже не понимая, что если колесо прибить гвоздями, то оно будет крутится отаврительно, если вообще будет. А если мы попытаемся использовать те же гвозди и для велосипедной цепи — то тут уж совсем тяжко будет. Хотя для сидения и руля — они сгодятся не хуже чем шурупы, гайки и болты. Правда если мы захотим поменять руль или сиденье, то придется нам раскорячивать старые гвозди (глобальные переменные), и на место них забивать новые, которые держать будут хуже, и не факт что руль по дороге не отвалится, а на сиденье будет вообще не сташно сесть. А если мы используем большие гвозди, которые пронают несколкьо компонетов сразу — то тут вообще начинается полная жопа, и рука тянется к сварочному аппарату (мы связываем компонентны нашей системы до такой степени, что использовать их отдельно уже врядли когда-нибудь получиться), что неочень хорошо.
А если по существу, то у вас сейчас есть два выхода:
Первый, самый легкий, который реализуется за 20 минут, паттерном Registry реализованным в виде Singleton-а или статического класса с методами set\get\isset\delete. Все глобальные перменные скидываете туда и они становятся доступны из любой точки вашего приложения. В результате имеем тот же набор гвоздей пронизывающих весь наш велосипед, только теперь смена одного гвоздя на другой упрощается, это если мы грамотно все построим. Да и с точки зрения псевдо ооп-шников, прочитавшись пару книг и решившись все заворачивать в классы это будет очень круто, гибко и зачотно.
Второй — потяжелее, и заставит нас потратить не только на несколько порядков больше времени, но еще и денег. Потому что этот способ подразумевает собой долгое обучение в мастерской, где нам покажут какие бывают велосипеды (а они бывают не только децкие, горные и шосейники), где мы поймем что такое руль и для чего он нужен, как работает передняя вилка, как должна выглядеть втулка, из каких материалов лучше сделать раму, почему очень плохо крепить цепь на гвозди, и почему же на bmx-ы все спошь синглспиды (однаскоростные). И вот после того, как мы потратим год или полтора на изучение всего этого материала, пытаясь дома сконструировать свой первый удобный руль, выпелить педаль с шипами, которая бы не травмировала ногу велосипедиста если случайно она слетит и если он по глупости своей не надел защиту (у автора от таких педалей два шрама на левой ноге...). И вот только тогда мы будем готовы собрать свой велосипед, подсматривая и даже воруя идеи у других конструкторов, уже успешных моделей, на которых катает не один десяток тысяч человек.
Так что, выбор за вами…
такое чувство, как будто вы — бывший программист, ставший профессиональным велосипедистом :).
круто описали проблему. оч доходчиво :)
круто описали проблему. оч доходчиво :)
Думаю все же профессиональный программист, занимавшийся немного стритом.
Кстати, очень интересный вопрос — кто с чем сравнивает своё программирование.
Я своё, наверное, с пластилином )
Я своё, наверное, с пластилином )
Как ни банально, но я четко ассоцирую написание кода со стоительством. Сказалось влияние родителей, книжек по строительству в которых были красивые для меня каритнки зданий, с различным описанием, непонятными цифрами, в разрезе\под разными углами\схематически, и долгих вечеров когда я собирал из лего кучу всего. В гораздо меньшей степени с написанием картины или музыки (это больше соотношу с дизайном).
А вот к примеру электроника у меня чотко ассоциируется с программированием. Только без повторного использования одних и тех же компонентов :)
А вот к примеру электроника у меня чотко ассоциируется с программированием. Только без повторного использования одних и тех же компонентов :)
А Вам не интересно было бы расширить эту тему? Из миллиона фреймворков получится единственный который работает на ассоциациях :)
:)
Ну, это шутка юмора конечно, однако, ассоциации программера сильно влияют на его $result ;)
$result = new Lego();
$result->addDetail("кубик")->put("тудым");
return $result;:)
Ну, это шутка юмора конечно, однако, ассоциации программера сильно влияют на его $result ;)
> А вот к примеру электроника у меня чотко ассоциируется с программированием. Только без повторного использования одних и тех же компонентов :)
Зря вы так думаете, просто смотрите с другой стороны. Например микросхема это тоже своего рода кубик, функция или даже целый фраемворк и используется во многих устройствах. Представьте что это класс и для каждого устройства нужно создавать свой объект :)
Зря вы так думаете, просто смотрите с другой стороны. Например микросхема это тоже своего рода кубик, функция или даже целый фраемворк и используется во многих устройствах. Представьте что это класс и для каждого устройства нужно создавать свой объект :)
Я говорил немножко про другое. Про то, что мы можем одновременно использовать один компонент, только в одном месте — т.е. если у нас есть усилительный каскад, то он может использоватся только в одном компоненте этой схемы в одно время.
Ну и в тоже время в любом языке объект класса также используется одновременно только в одном месте если вы думаете что к одному объекту можно обращаться из разных потоков то это зачастую плохо кончается а вот каскады в электроники зачастую как раз работаю на несколько фронотов :). Если рассматривать функцию то это некий алгоритм с входными данными как например тригер, суматор, дешифратор ну и т.д. по сути используется много раз и много везде. В программирование функции это код на диске также как и в электронике схемы на бумаге бери и используй сколько угодно раз и где угодно. И я думаю интелектуалные ценности куда вожнее материальных.
Отличное сравнение, ashofthedream, и я с вами согласен. Я сам тысячу раз уже убеждался, что взять кем-то давно написанный элемент или весь фреймворк бывает и лучше и качественнее и быстрее. Но как же быть с движением вперёд? Можно отупеть, вечно роясь в кем-то сколоченных библиотеках. Немного грубовато, но так и есть.
Я далеко ещё не программер (не такой программер каким хотел бы быть), а пробуя, ошибаясь и примеряя новое — я расту. Совсем недавно верхом для меня было написать с десяток функций и импортировать их в каждой страничке. А теперь вот познаю OOP и MVC. С Singleton я ещё не знаком, а после ваших комментариев обязательно познакомлюсь, спасибо. С учителями в наших краях тяжко, но это вопрос скорее финансовый, вот почему я задал свой вопрос здесь ;)
Благодарю за прекрасное сравнение нашей работы с жизнью. Но всё-же, Вы не ответили на первоначальный вопрос ;) Вопрос был таким «как все переменные в функции load сделать глобальными?» и можно ли? Пример: встроенная функция require() импортирует файл не изолируя глобальные переменные.
Я далеко ещё не программер (не такой программер каким хотел бы быть), а пробуя, ошибаясь и примеряя новое — я расту. Совсем недавно верхом для меня было написать с десяток функций и импортировать их в каждой страничке. А теперь вот познаю OOP и MVC. С Singleton я ещё не знаком, а после ваших комментариев обязательно познакомлюсь, спасибо. С учителями в наших краях тяжко, но это вопрос скорее финансовый, вот почему я задал свой вопрос здесь ;)
Благодарю за прекрасное сравнение нашей работы с жизнью. Но всё-же, Вы не ответили на первоначальный вопрос ;) Вопрос был таким «как все переменные в функции load сделать глобальными?» и можно ли? Пример: встроенная функция require() импортирует файл не изолируя глобальные переменные.
1. В модулях все глобальные переменные объявлять вот так вот:
$_GLOBALS['имя переменной'] = 'чтонебудь'; //
2. Использовать регистри, в самом простом виде:
В модулях писать так:
Registry:: set('название переменной', 'значение');
Доставать соответсвенно так:
echo Registry:: get('название переменной'); // получим «значение».
$_GLOBALS['имя переменной'] = 'чтонебудь'; //
2. Использовать регистри, в самом простом виде:
class Registry {
private static $collection = array();
public function set($name, $value) {
self::$collection[$name] = $value;
}
public function get($name) {
return self::$collection[$name];
}
}
В модулях писать так:
Registry:: set('название переменной', 'значение');
Доставать соответсвенно так:
echo Registry:: get('название переменной'); // получим «значение».
Ой. Я не знал что класс можно использовать без создания объектов этого класса ($obj = new Registry).
Если это так (сейчас проверю) то проблема решена. Это для меня, действительно, важный опыт. Спасибо.
Если это так (сейчас проверю) то проблема решена. Это для меня, действительно, важный опыт. Спасибо.
Только я думаю еще стоит добавить методы exists и delete. К каждой функции добавить модификатор static, и в методах delete и get проверять вначале существует ли значение с помощью isset(), что бы не было лишних нотисов.
UFO just landed and posted this here
UFO just landed and posted this here
Хм, я для загрузки модулей делал класс Module, который содержал метод Module:: run($name, $params=null), при вызове которого создавался объект класса ModuleImplementation, который собственно и являлся объектом загружаемого модуля. Из других частей системы доступ к параметрам(переменным) отдельно взятого модуля мы получаем с помощью того же класса Module, а точнее его объекта. В классе Module был описан метод __get(). Таким образом мы можем обращаться к модулю например так:
$Module = new Module();
$Module->run(«MyMod»);
$MyModObject = $Module->MyMod;
Так же объект модуля содержит ряд свойств, таких как return, vars, permissions. В return хранится ассоциативный массив данных которые передаются в шаблон(-ы), в vars так же ассоц. массив с переменным модуля, которые поступают к нему из вне, например параметры при вызове. В permissions — права доступа, тоже массив.
P.S. Ну это я так, поделился мыслями своими, возможно почерпнёте новых идей =)
$Module = new Module();
$Module->run(«MyMod»);
$MyModObject = $Module->MyMod;
Так же объект модуля содержит ряд свойств, таких как return, vars, permissions. В return хранится ассоциативный массив данных которые передаются в шаблон(-ы), в vars так же ассоц. массив с переменным модуля, которые поступают к нему из вне, например параметры при вызове. В permissions — права доступа, тоже массив.
P.S. Ну это я так, поделился мыслями своими, возможно почерпнёте новых идей =)
Используйте классы и исполькуйте autoload
Глобальные переменные не нужны. Их можно заменить членами статического класса или синглтона.
Например MyDviglo::$myData, MyDviglo::$cache->clear('users', 'posts')
Глобальные переменные не нужны. Их можно заменить членами статического класса или синглтона.
Например MyDviglo::$myData, MyDviglo::$cache->clear('users', 'posts')
UFO just landed and posted this here
ужс :) рано вам пока свой фреймворк писать. (не обижайтесь)
посмотрите как подобные вещи реализованы в популярных фреймворках, появится и понимание процесса.
(глобальных переменных вообще избегайте)
посмотрите как подобные вещи реализованы в популярных фреймворках, появится и понимание процесса.
(глобальных переменных вообще избегайте)
Я думаю «рано» не бывает. Ровно как и «поздно». Использование простейшего метода работы с данными, через переменные, каждый запишет в плюс или минус (в зависимости от опыта, наверное). Я не делаю его для всех, покамест только для себя, типа как упражняюсь. Плюс делаю удобную основу для вебсистемы, с которой работать (программить) удобно будет мне, которую знаешь от и до. В общем, это те подробности, которых я писать не хотел :)
изучали бы лучше ruby
Sign up to leave a comment.
Функция Load для собственного framework