К сожелению, хочу вам сообщить, что проблема находится не там где вы ее ищете. Скажем так, ваша проблема состоит не в том, что вы не можете нормально использовать глобальные переменные между модулями, а в том, что вы не знаете как вообще работает «велосипед».
Скажем так, вы пытаетесь использовать такую удобную с первого взгляда вещь, как гвоздь (глобальные переменные) во всех деталях велосипеда, даже не понимая, что если колесо прибить гвоздями, то оно будет крутится отаврительно, если вообще будет. А если мы попытаемся использовать те же гвозди и для велосипедной цепи — то тут уж совсем тяжко будет. Хотя для сидения и руля — они сгодятся не хуже чем шурупы, гайки и болты. Правда если мы захотим поменять руль или сиденье, то придется нам раскорячивать старые гвозди (глобальные переменные), и на место них забивать новые, которые держать будут хуже, и не факт что руль по дороге не отвалится, а на сиденье будет вообще не сташно сесть. А если мы используем большие гвозди, которые пронают несколкьо компонетов сразу — то тут вообще начинается полная жопа, и рука тянется к сварочному аппарату (мы связываем компонентны нашей системы до такой степени, что использовать их отдельно уже врядли когда-нибудь получиться), что неочень хорошо.
А если по существу, то у вас сейчас есть два выхода:
Первый, самый легкий, который реализуется за 20 минут, паттерном Registry реализованным в виде Singleton-а или статического класса с методами set\get\isset\delete. Все глобальные перменные скидываете туда и они становятся доступны из любой точки вашего приложения. В результате имеем тот же набор гвоздей пронизывающих весь наш велосипед, только теперь смена одного гвоздя на другой упрощается, это если мы грамотно все построим. Да и с точки зрения псевдо ооп-шников, прочитавшись пару книг и решившись все заворачивать в классы это будет очень круто, гибко и зачотно.
Второй — потяжелее, и заставит нас потратить не только на несколько порядков больше времени, но еще и денег. Потому что этот способ подразумевает собой долгое обучение в мастерской, где нам покажут какие бывают велосипеды (а они бывают не только децкие, горные и шосейники), где мы поймем что такое руль и для чего он нужен, как работает передняя вилка, как должна выглядеть втулка, из каких материалов лучше сделать раму, почему очень плохо крепить цепь на гвозди, и почему же на bmx-ы все спошь синглспиды (однаскоростные). И вот после того, как мы потратим год или полтора на изучение всего этого материала, пытаясь дома сконструировать свой первый удобный руль, выпелить педаль с шипами, которая бы не травмировала ногу велосипедиста если случайно она слетит и если он по глупости своей не надел защиту (у автора от таких педалей два шрама на левой ноге...). И вот только тогда мы будем готовы собрать свой велосипед, подсматривая и даже воруя идеи у других конструкторов, уже успешных моделей, на которых катает не один десяток тысяч человек.
Посмотрите профайлер/дебаггер в Zend Studio Neon, у которого есть еще и плагинчек для ie и ff. Правда он платный (т.е. входит в комплект платной студии).
Не совсем теряется, просто у нас появляются еще один механизм для гибкости нашего дерева, простой пример:
class Foo {
public:
void getPrivateMethod() { this->privateMethod(); }
private:
virtual void privateMethod() { cout << «foo:: privatemethod»; }
};
class Bar: public Foo {
private:
void privateMethod() { cout << «bar:: privatemethod»; }
};
и написав:
Bar *bar = new Bar();
bar->getPrivateMethod();
мы получим bar:: privatemethod, потому как функция у нас виртуальная, сделав ее обычной то мы, как и в случае пхп и явы, которые работают абсолютно идентично, получили бы foo:: privatemethod.
Впринципе в жизни такое тоже можно использовать, хотя для этого отлично подходит и protected с abstract в других языках.
Не сказал бы что загадочный, но все таки с немного другим типом мышления, подпорченным плюсами, где все это спокойно регулируется его виртуальными механизмами. Там же по сути с помощью них мы можем заставить работать все наше дерево классов, как бы в одной плоскости последнего чайлда, а можем и в этой самой иерархии.
Вот потому что «Смешно и бессмысленно раскладывать», большинство людей и не могут ничего сделать сами. Умение говорить — это не какой-то дар, свалившийся с неба, дарованый одному из миллиарада.
Оратор — он как музыкант, должен понимать что к чему, а не монотонно читать написанный текст, да и еще неизвестно кем написанный. И он, этот самый оратор, что бы понимать что собственно к чему и как, должен на чем-то учится.
Как учатся музыканты — на партиях других музыкантов, как учатся актеры — правильно, на игре других актеров, как учатся художники — на примере других художников. И только уже потом вносят что-то свое, что будет разобрано сотней других людей, а может быть и нагло скопированно — для большей убедительности.
Так что разбирать надо, а еще надо думать, к примеру поиграть с этими шаблонами, фишками, штуками что ты откопал в процессе этого разбора — сразу появится куча мест где можно их использовать для себя, в своих речах, даже перед аудиторией в три человека.
Так вот мне в последнее время приходят мысли о том, что програмера новому языку следуюет учить по схеме:
Погонять по мануалу, показать что вообще есть в языке, дать почитать «Совершенный код», и после посадить на изучение кода какого-нибудь фреймворка, что пограмотнее написан, что бы посмотрел сразу как надо правильно использовать возможности языка. Осилит все это — готовых решений от него ждать надо будет недолго, неосилит — да и не нужен такой.
1. Первым делом пишем в гугле установка apache и php. Узнаем что такое apache, php и mysql.
2. Настраиваем все это, пытаемся понять, что по сути вместо apache и mysql, могут быть различные компоненты, nginx, iss, postresql, oracle и т.д.
3. Лезем на php.net/manual/ru и узнаем как вообще пишется на этом языке
4. Покупаем книжку «Совершенный код», начинаем читать.
4.х Если новичек в програминге вообще — то покупаем кучу книг по программингу, желательно больше теоретические, всякий мусор типа PHP в поддлиннике для супер-профи — лучше не брать, хоть все будет гораздо легче, но потеряете много времени, потому как будете считать что именно вот так вот надо писать код, как написано в них. А в них по большей части написан бред для полоумных.
5. Пишем простенькие приложения, смотрим что куда, как и что, вникаем в тонкости языка. Радуемся первому собственноручно написаному блог-движку, форуму и левой цмс-ки которая вообщем то ничего и не умееет.
6. Качаем ZF, Symfony, Prado, CodeIgniter, Solar, CakePHP и изучаем код и возможности, пытаясь понять как вообще используется язык на котором будем писать.
7. Понимаем что вообщем-то стали уже довольно сильными девелоперами и выбираем путь сами…
Хуже отсутствия комментов, комменты на английском, человеком который владеет только русским. Нет, признаюсь, что и я иногда пишу не в том времени, но когда ты читаешь и видишь только набор бессвязных слов да и еще с ошибками…
Так вот мне в последнее время приходят мысли о том, что програмера новому языку следуюет учить по схеме:
Погонять по мануалу, показать что вообще есть в языке, дать почитать «Совершенный код», и после посадить на изучение кода какого-нибудь фреймворка, что пограмотнее написан, что бы посмотрел сразу как надо правильно использовать возможности языка. Осилит все это — готовых решений от него ждать надо будет недолго, неосилит — да и не нужен такой.
Насчет нравится почти все — мне нравилось почти все (кроме скорости работы наверное) только в одним из четырех (ZF, Symfony, CI, Prado) фремвоков — zf. У которого еще, по каким-то странным стечением обстоятельств и слабая связанность компонентов, поэтому в отличие от какого-нибудь Prado, у которого можно выдрать только монтировкой что-нибудь, зенд вливается в другие проекты ну просто на ура, и многими разработчиками считается как вообще какой-то нативный компонент своего языка.
Немножко несогласен, что когда набирается достаточное количество решений то приходится писать все меньше и меньше. У меня, да и еще парочки знакомых девелоперов, которые использовали свои велосипеды в десятках различных веб-приложений появляется одна проблема — внутренний рефакторинг этого самого велосипеда (хотя если быть точнее то переписывание некоторых компонентов практически с нуля). Потому как сложно использовать старый код, написаный полтора года назад, но полностью рабочий, решающий свои задачи, проверенный временем; когда за это время ты узнал еще о десятке способов решения данной проблемы, и тебя решение, которое у тебя есть на данный момент не устраивает полностью.
Одной рукой за готовые решения, другой — за велосипеды. Потому как готовые решения как правило — добро, они могут сэкономить нам очень много времени, нервов и дать некоторых недостающих знаний. А вся чепуха то, что мы вот сами напишем лучше — едва ли действует и в двадцати случаях, в которых нужно действительно что-то адаптировать именно под конкретные условия конкретного проекта, а не стандартные условия, для которых и писалось это решение.
А вот свои велосипеды частенько приходится использовать уже вместе с готовыми решениями — да, получается иногда такой суповой набор, с немножко разными стандартами кодирования, немного подпиленный и забитый по сути в адаптеры, которые и не дают ему полностью развалится и позволяют всему общатся между собой, без особых проблем.
Сейчас вот к примеру активно пользуюсь Zend Framework, изучая его, черпая что-то новое и внося в свой небольшой фреймворк (если раньше создавался как решение от всех моих проблем, то сейчас — скорее это некий sandbox позволяющий эксперементировать и получать новые знания), который уже наверное по сути является клоном самого зенда. Наверное это хорошо когда твоя идеология и видения фреймворка совпадает с видением довольно неглупых людей, у которых еще и можно подсмотреть как это лучше сделать.
Ам, понятно. Просто я по наивности своей считал, что вроде как в пыхе дела плохи только с поздним статическим связыванием, и никогда не натыкался на такие вот вещи, на которые мне пришлось наткнутся сегодня…
Кстати, сегодня наткнулся на интересную возможность в пхп:
class Foo {
private $id = 0;
public function getId() {
return $this->id;
}
}
class Bar extends Foo {}
$bar = new Bar();
$bar->id = 10;
var_dump($bar->id);
var_dump($bar->getId());
var_dump($bar);
После запуска получим такие вот результаты:
int 10
int 0
object(Bar)[1]
private 'id' => int 0
public 'id' => int 10
Что она дает нам? Ответ прост — лишнуюю головную боль, потому как судя по этому куску кода $this, работает так же как и self::. Потому как если перенести getId в чайлд, то получим две десятки. Да и нахождение в объетке двух id — это слегка черезчур…
Искал новую, старой на момент ухода не было. Нашел без проблем, везде где был работу предлагали, несмотря на то, что по его словам ситуацию работодателям объяснял. Хотя и не удивительно — хороших прогеров на пхп, готовых развиватся дальше и им интересно работать — мало, очень мало.
А насчет возврата в старую компанию. По большему счету это тоже самое что и устроится на новую, в компаниях где я работал, стабильно за год менялось 90% сотрудников, работающих над поектами. А вот бугалтерия, манагеры — оставились впринципе теми же.
К сожелению вы изобретаете велосипед, даже не до конца изучив что же это за зверь такой, двухколесный и с педалями. Вы сейчас, своими силами, без ООП парадигмы пришли к такой чтуке как Factory, правда немножко своеобразной.
Не хочу сказать что это плохо, но если вы извлекли из этого какие-то знания — то скорее всего время потрачено не зря
Скажем так, вы пытаетесь использовать такую удобную с первого взгляда вещь, как гвоздь (глобальные переменные) во всех деталях велосипеда, даже не понимая, что если колесо прибить гвоздями, то оно будет крутится отаврительно, если вообще будет. А если мы попытаемся использовать те же гвозди и для велосипедной цепи — то тут уж совсем тяжко будет. Хотя для сидения и руля — они сгодятся не хуже чем шурупы, гайки и болты. Правда если мы захотим поменять руль или сиденье, то придется нам раскорячивать старые гвозди (глобальные переменные), и на место них забивать новые, которые держать будут хуже, и не факт что руль по дороге не отвалится, а на сиденье будет вообще не сташно сесть. А если мы используем большие гвозди, которые пронают несколкьо компонетов сразу — то тут вообще начинается полная жопа, и рука тянется к сварочному аппарату (мы связываем компонентны нашей системы до такой степени, что использовать их отдельно уже врядли когда-нибудь получиться), что неочень хорошо.
А если по существу, то у вас сейчас есть два выхода:
Первый, самый легкий, который реализуется за 20 минут, паттерном Registry реализованным в виде Singleton-а или статического класса с методами set\get\isset\delete. Все глобальные перменные скидываете туда и они становятся доступны из любой точки вашего приложения. В результате имеем тот же набор гвоздей пронизывающих весь наш велосипед, только теперь смена одного гвоздя на другой упрощается, это если мы грамотно все построим. Да и с точки зрения псевдо ооп-шников, прочитавшись пару книг и решившись все заворачивать в классы это будет очень круто, гибко и зачотно.
Второй — потяжелее, и заставит нас потратить не только на несколько порядков больше времени, но еще и денег. Потому что этот способ подразумевает собой долгое обучение в мастерской, где нам покажут какие бывают велосипеды (а они бывают не только децкие, горные и шосейники), где мы поймем что такое руль и для чего он нужен, как работает передняя вилка, как должна выглядеть втулка, из каких материалов лучше сделать раму, почему очень плохо крепить цепь на гвозди, и почему же на bmx-ы все спошь синглспиды (однаскоростные). И вот после того, как мы потратим год или полтора на изучение всего этого материала, пытаясь дома сконструировать свой первый удобный руль, выпелить педаль с шипами, которая бы не травмировала ногу велосипедиста если случайно она слетит и если он по глупости своей не надел защиту (у автора от таких педалей два шрама на левой ноге...). И вот только тогда мы будем готовы собрать свой велосипед, подсматривая и даже воруя идеи у других конструкторов, уже успешных моделей, на которых катает не один десяток тысяч человек.
Так что, выбор за вами…
class Foo {
public:
void getPrivateMethod() { this->privateMethod(); }
private:
virtual void privateMethod() { cout << «foo:: privatemethod»; }
};
class Bar: public Foo {
private:
void privateMethod() { cout << «bar:: privatemethod»; }
};
и написав:
Bar *bar = new Bar();
bar->getPrivateMethod();
мы получим bar:: privatemethod, потому как функция у нас виртуальная, сделав ее обычной то мы, как и в случае пхп и явы, которые работают абсолютно идентично, получили бы foo:: privatemethod.
Впринципе в жизни такое тоже можно использовать, хотя для этого отлично подходит и protected с abstract в других языках.
Вот… как-то так…
Оратор — он как музыкант, должен понимать что к чему, а не монотонно читать написанный текст, да и еще неизвестно кем написанный. И он, этот самый оратор, что бы понимать что собственно к чему и как, должен на чем-то учится.
Как учатся музыканты — на партиях других музыкантов, как учатся актеры — правильно, на игре других актеров, как учатся художники — на примере других художников. И только уже потом вносят что-то свое, что будет разобрано сотней других людей, а может быть и нагло скопированно — для большей убедительности.
Так что разбирать надо, а еще надо думать, к примеру поиграть с этими шаблонами, фишками, штуками что ты откопал в процессе этого разбора — сразу появится куча мест где можно их использовать для себя, в своих речах, даже перед аудиторией в три человека.
1. Первым делом пишем в гугле установка apache и php. Узнаем что такое apache, php и mysql.
2. Настраиваем все это, пытаемся понять, что по сути вместо apache и mysql, могут быть различные компоненты, nginx, iss, postresql, oracle и т.д.
3. Лезем на php.net/manual/ru и узнаем как вообще пишется на этом языке
4. Покупаем книжку «Совершенный код», начинаем читать.
4.х Если новичек в програминге вообще — то покупаем кучу книг по программингу, желательно больше теоретические, всякий мусор типа PHP в поддлиннике для супер-профи — лучше не брать, хоть все будет гораздо легче, но потеряете много времени, потому как будете считать что именно вот так вот надо писать код, как написано в них. А в них по большей части написан бред для полоумных.
5. Пишем простенькие приложения, смотрим что куда, как и что, вникаем в тонкости языка. Радуемся первому собственноручно написаному блог-движку, форуму и левой цмс-ки которая вообщем то ничего и не умееет.
6. Качаем ZF, Symfony, Prado, CodeIgniter, Solar, CakePHP и изучаем код и возможности, пытаясь понять как вообще используется язык на котором будем писать.
7. Понимаем что вообщем-то стали уже довольно сильными девелоперами и выбираем путь сами…
А фреймворки это — ZF, Symfony, Prado, CodeIgniter, Solar, CakePHP.
Погонять по мануалу, показать что вообще есть в языке, дать почитать «Совершенный код», и после посадить на изучение кода какого-нибудь фреймворка, что пограмотнее написан, что бы посмотрел сразу как надо правильно использовать возможности языка. Осилит все это — готовых решений от него ждать надо будет недолго, неосилит — да и не нужен такой.
Насчет нравится почти все — мне нравилось почти все (кроме скорости работы наверное) только в одним из четырех (ZF, Symfony, CI, Prado) фремвоков — zf. У которого еще, по каким-то странным стечением обстоятельств и слабая связанность компонентов, поэтому в отличие от какого-нибудь Prado, у которого можно выдрать только монтировкой что-нибудь, зенд вливается в другие проекты ну просто на ура, и многими разработчиками считается как вообще какой-то нативный компонент своего языка.
А вот свои велосипеды частенько приходится использовать уже вместе с готовыми решениями — да, получается иногда такой суповой набор, с немножко разными стандартами кодирования, немного подпиленный и забитый по сути в адаптеры, которые и не дают ему полностью развалится и позволяют всему общатся между собой, без особых проблем.
Сейчас вот к примеру активно пользуюсь Zend Framework, изучая его, черпая что-то новое и внося в свой небольшой фреймворк (если раньше создавался как решение от всех моих проблем, то сейчас — скорее это некий sandbox позволяющий эксперементировать и получать новые знания), который уже наверное по сути является клоном самого зенда. Наверное это хорошо когда твоя идеология и видения фреймворка совпадает с видением довольно неглупых людей, у которых еще и можно подсмотреть как это лучше сделать.
Все таки загадочный язык этот пых…
Просто очень странно, почему getId, находящийся в предке, используя this лезет именно в предка, а не в чайлда, который инстанцирован.
class Foo {
private $id = 0;
public function getId() {
return $this->id;
}
}
class Bar extends Foo {}
$bar = new Bar();
$bar->id = 10;
var_dump($bar->id);
var_dump($bar->getId());
var_dump($bar);
После запуска получим такие вот результаты:
int 10
int 0
object(Bar)[1]
private 'id' => int 0
public 'id' => int 10
Что она дает нам? Ответ прост — лишнуюю головную боль, потому как судя по этому куску кода $this, работает так же как и self::. Потому как если перенести getId в чайлд, то получим две десятки. Да и нахождение в объетке двух id — это слегка черезчур…
А насчет возврата в старую компанию. По большему счету это тоже самое что и устроится на новую, в компаниях где я работал, стабильно за год менялось 90% сотрудников, работающих над поектами. А вот бугалтерия, манагеры — оставились впринципе теми же.
Не хочу сказать что это плохо, но если вы извлекли из этого какие-то знания — то скорее всего время потрачено не зря