php в классе использовать другой класс
ООП: использование экземпляра класса в другом классе
6epcepk
Новичок
ООП: использование экземпляра класса в другом классе
Сегодня осуществил вторую попытку написания логики ядра на ООП.
Пример:
Mr_Max
Первый класс. Зимние каникулы ^_^
whirlwind
TDD infected, paranoid
Пью пиво
6epcepk
Новичок
Mr_Max
Понял, исправился.
whirlwind
Стыдно, про самое простое и забыл 
Но допустим ситуация: я подключаю сторонний класс к своей системе и тогда мне приходится переделывать аргументы всех методов?
AmdY
Конструктор как раз использует все нижеописанные методы (я их подсократил), просто вынес по отдельности все.
Пью пиво
6epcepk
Новичок
Пью пиво
whirlwind
TDD infected, paranoid
Используйте паттерн Adaptor
PS. Пора переходить на ООП.
джамшут
Новичок
6epcepk
Новичок
AmdY
Сейчас вникаю в Symfony, пока разобрал как взаимодействует класс ядра, класс конфигураций и класс утилит, никак не могу найти как обрабатываются модули.
whirlwind
А если сделать гибрид между Adaptor и Singleton?
То есть в модуль будет передаваться ссылка на экземпляр ядра, но каждый класс в свою очередь вызывается единожды, поэтому по методу getInstance в ядро и модуль.
джамшут
Ядро получается параметры конфигурации системы (настройки, языки, сайты), подгружает модули, следит за правами доступа и т.п.
whirlwind
TDD infected, paranoid
Вот честно пытался понять, но не осилил.
Теперь Вы понимаете как нелепо звучит «каждый класс в свою очередь вызывается единожды»? Это то же самое, что один раз на всю программу использовать одну строку, один раз число и т.п. Такие классы ничего не улучшают и не облегчают, они только усложняют и запутывают.
6epcepk
Новичок
whirlwind
Да конечно, это была игра слов, извиняюсь.
Попытаюсь описать скелет моей логики, что-то взял из Symfony, что-то сам домыслил:
Есть класс Config, его методы (первоначальная загрузка параметров конфигурации из БД, получение значение конфигурационного параметра по ключу) используются в других методах других классов многократно (Kernel, Module).
Есть класс Kernel, в нем определен конструктор, отвечающий за загрузку модулей.
При загрузке системы идет обращение к методу-конструктору однократное.
Есть класс Module, в нем определен конструктор, возвращающий данные модуля, предназначенные для вывода на экран.
При загрузке класса идет обращение к методу-конструктору однократное.
После определения классов:
Я не особо понял чем лучше использование передачу ссылки на экземпляр класса в другой класс (Adaptor), чем просто использовать базовый класс и производный. (Хотя последнее видимо есть какой-то другой паттерн.)
Вызов и вывод объекта одного класса в другом классе(методе)
Имеется вот такой класс Dbtest подключения к бд через PDO. Так же имеется другой класс в котором я бы хотел бы соединяться с бд и делать выборку информации.И последнее после выборки хотелось бы вывести эту информацию для проверки. Так как маловато опыта в oop пытаюсь все освоить на практике)Проблема с вызовом обьектов класса и передачей информации из одного класса в другой.Для вывода в классе я использовал вот такую конструкцию:
По сути метод getPriceWithVat класса Testcon должен подключиться к бд сделать выборку и вывести ее для проверки.(Не судите строго я новичек)
1 ответ 1
Для того, чтобы использовать объект класса Dbtest в другом классе, его надо передать в этот класс через конструктор.
Никакое наследование тут не должно применяться. Наследование, вообще, самый неоднозначный и опасный из элементов ООП, и его не следует применять до тех пор, пока не будет четкого понимания основ.
Статический метод/синглтон это тоже так себе решение, сойдет для классического похапе-гуанокода, но если хочется учить правильный ООП, то класс для работы с БД надо передавать в другие классы в качестве зависимости.
Кроме того в классе есть много своих косяков.
В итоге всю эту красоту надо переписать по крайней мере так
Соответственно, в остальные классы передаем БД в конструктор
Подробно об объектах и классах в PHP
Сегодня объекты используются очень активно, хотя это трудно было предположить после выхода PHP 5 в 2005 году. Тогда я ещё мало что знал о возможностях этого языка. Пятую версию PHP сравнивали с предыдущей, четвёртой, и главным преимуществом нового релиза стала новая, очень мощная объектная модель. И сегодня, десять лет спустя, около 90% всего PHP-кода содержит объекты, не изменившиеся со времени PHP 5.0. Это убедительно говорит о том, какую роль сыграло внедрение объектной модели, неоднократно улучшавшейся на протяжении последующих лет. В этом посте я хотел бы рассказать о том, как всё устроено «под капотом». Чтобы люди понимали суть процессов — почему сделано так, а не иначе — и лучше, полнее использовали возможности языка. Также я затрону тему использования памяти объектами, в том числе в сравнении с эквивалентными массивами (когда это возможно).
Я буду рассказывать на примере версии PHP 5.4, и описываемые мной вещи справедливы для 5.5 и 5.6, потому что устройство объектной модели там почти не претерпело изменений. Обратите внимание, что в версии 5.3 всё не так хорошо с точки зрения возможностей и общей производительности.
В PHP 7, который пока ещё активно разрабатывается, объектная модель переработана не сильно, были внесены лишь незначительные изменения. Просто потому что всё и так хорошо работает, а лучшее — враг хорошего. Были добавлены возможности, не затрагивающие ядро, но здесь об этом речи не пойдёт.
В качестве демонстрации начну с синтетических бенчмарков:
Здесь объявляется простой класс с тремя атрибутами, а затем в цикле создаётся 1000 объектов этого класса. Обратите внимание, как в этом примере используется память: при создании объекта класса Foo и переменной для его хранения выделяется 262 байт динамической памяти PHP.
Давайте заменим объект на эквивалентный массив:
Вот ещё один пример:
Теперь давайте разберём, как всё это устроено в недрах PHP, подкрепив теорией практические наблюдения.
Всё начинается с классов
Внутри PHP класс представляется с помощью структуры zend_class_entry:
Важно знать ещё об одном моменте, связанном с zend_class_entry — о PHP-комментариях. Они также известны как аннотации. Это строковые переменные (в языке С — буферы char* ), которые тоже надо разместить в памяти. Для языка С, не использующего Unicode, в отличие от PHP, правило очень простое: один символ = один байт. Чем больше у вас в классе аннотаций, тем больше памяти будет использовано после парсинга.
У zend_class_entry поле doc_comment содержит аннотации класса. У методов и атрибутов тоже есть такое поле.
Пользовательские и внутренние классы
Пользовательский класс — это класс, заданный с помощью PHP, а внутренний класс задаётся либо благодаря внедрению исходного кода в сам PHP, либо с помощью расширения. Самое большое различие между этими двумя видами классов заключается в том, что пользовательские классы оперируют памятью, выделяемой по запросу, а внутренние — «постоянной» памятью.
Это означает, что когда PHP заканчивает обработку текущего HTTP-запроса, он убирает из памяти и уничтожает все пользовательские классы, готовясь к обработке следующего запроса. Этот подход известен под названием «архитектура без разделения ресурсов» (the share nothing architecture). Так было заложено в PHP с самого начала, и изменять это пока не планируется.
Итак, каждый раз при формировании запроса и парсинге классов происходит выделение памяти для них. После использования класса уничтожается всё, что с ним связано. Так что обязательно используйте все объявленные классы, в противном случае будет теряться память. Применяйте автозагрузчики, они задерживают парсинг/объявление во время выполнения, когда PHP нужно задействовать класс. Несмотря на замедление выполнения, автозагрузчик позволяет грамотно использовать память, поскольку он не будет запущен, пока действительно не возникнет потребность в классе.
С внутренними классами всё иначе. Они размещаются в памяти постоянно, вне зависимости от того, использовали их или нет. То есть они уничтожаются только тогда, когда прекращается работа самого PHP — после завершения обработки всех запросов (подразумеваются веб SAPI, например, PHP-FPM). Поэтому внутренние классы более эффективны, чем пользовательские (в конце запроса уничтожаются только статические атрибуты, больше ничего).
Обратите внимание, что даже при кешировании опкодов, как OPCache, создание и уничтожение класса осуществляется при каждом запросе, как и в случае с пользовательскими классами. OPCache просто ускоряет оба этих процесса.
Как вы заметили, если активировать много PHP-расширений, каждое из которых объявляет много классов, но при этом использовать лишь небольшое их количество, то теряется память. Помните, что PHP-расширения объявляют классы во время запуска PHP, даже если в последующих запросах эти классы использоваться не будут. Поэтому не рекомендуется держать расширения активными, если они не применяются в данный момент, иначе вы будете терять память. Особенно если эти расширения объявляют много классов — хотя они могут забить память и чем-нибудь другим.
Классы, интерфейсы или трейты — без разницы
Не слишком хорошо, что здесь используется 912 байт всего лишь для декларирования интерфейса BarException.
Привязка класса
Многие разработчики не вспоминают о привязке класса, пока не начинают задавать вопросом, а как же всё устроено на самом деле. Привязку класса можно описать как «процесс, в ходе которого сам класс и все связанные с ним данные подготавливаются для полноценного использования разработчиком». Этот процесс очень прост и не требует много ресурсов, если речь идёт о каком-то одном классе, не дополняющем другой, не использующем трейты и не внедряющим интерфейс. Процесс привязки для таких классов полностью протекает во время компиляции, а в ходе выполнения ресурсы на это уже не тратятся. Обратите внимание, что речь шла привязке класса, задекларированного пользователем. Для внутренних классов тот же самый процесс выполняется, когда классы зарегистрированы ядром или расширениями PHP, как раз перед запуском пользовательских скриптов — и делается это лишь один раз за всё время работы PHP.
Всё сильно усложняется, если речь заходит о внедрении интерфейсов или наследовании классов. Тогда в ходе привязки класса у родительских и дочерних объектов (будь то классы или интерфейсы) копируется абсолютно все.
Тут добавить нечего, простой случай.
Для каждой из таблиц функций (методов) используется do_inherit_method :
Что касается наследования, то здесь, в принципе, всё то же самое, что и при внедрении интерфейса. Только вовлечено ещё больше «участников». Но хочу отметить, что если PHP уже знает о классе, то привязка осуществляется во время компилирования, а если не знает — то во время выполнения. Так что лучше объявлять так:
Кстати, рутинная процедура привязки класса может привести к очень странному поведению:
В первом варианте привязка класса В отложена на время выполнения, потому что когда компилятор доходит до объявления этого класса, он ещё ничего не знает о классе А. Когда начинается выполнение, то привязка класса А происходит без вопросов, потому что он уже скомпилирован, будучи одиночным классом. Во втором случае всё иначе. Привязка класса С отложена на время выполнения, потому что компилятор ещё ничего не знает о В, пытаясь скомпилировать его. Но когда во время выполнения начинается привязка класса С, то он ищет В, который не существует, поскольку не скомпилирован по причине того, что В является дополнением. Вылетает сообщение “Class B doesn’t exist”.
Объекты
Итак, теперь мы знаем, что:
Теперь поговорим об объектах. В первой главе показано, что создание «классического» объекта («классического» пользовательского класса) потребовало очень мало памяти, около 200 байт. Всё дело в классе. Дальнейшая компиляция класса тоже потребляет память, но это к лучшему, потому что для создания одиночного объекта требуется меньше байт. По сути, объект представляет собой крохотный набор из крохотных структур.
Управление методами объекта
Вы могли заметить интересную вещь, посмотрите на первые строки:
Во время компиляции функции/метода происходит немедленный перевод в нижний регистр. Вышеприведённая функция BAR() превращается в bar() компилятором при добавлении метода таблице классов и функций.
В приведённом примере первый вызов статический: компилятор вычислил key для строковой “bar”, а когда приходит время вызова метода, ему нужно делать меньше работы. Второй вызов уже динамический, компилятор ничего не знает о “$b”, не может вычислить key для вызова метода. Затем, во время выполнения, нам придётся перевести строковую в нижний регистр и вычислить её хеш ( zend_hash_func() ), что не лучшим образом сказывается на производительности.
Управление атрибутами объекта
Вот что происходит:
Так что, создавая объект, мы «всего лишь» создаём структуру zend_object весом 32 байта:
Далее движок создаёт вектор признаков нашего объекта:
Вероятно, у вас возникли два вопроса:
Пока вы не пишете в объект, его потребление памяти не меняется. После записи он занимает уже больше места (пока не будет уничтожен), поскольку содержит все записанные в него атрибуты.
Объекты, ведущие себя как ссылки благодаря хранилищу объектов
Объекты не являются ссылками. Это демонстрируется на маленьком скрипте:
Все сейчас скажут, что «в PHP 5 объекты являются ссылками», об этом упоминает даже официальный мануал. Технически это совершенно неверно. Тем не менее, объекты могут вести себя так же, как и ссылки. Например, когда вы передаёте переменную, являющуюся объектом функции, эта функция может модифицировать тот же объект.
object(MyClass)#1 (0) < >/* #1 is the object handle (number), it is unique */
Когда мы вызываем метод, движок изменяет область видимости:
Вот так можно получать доступ к приватным членам объектов, не принадлежащим вам, но являющимся дочерними по отношению к вашей текущей области видимости:
Эта особенность стала причиной большого количества баг-репортов от разработчиков. Но так устроена объектная модель в PHP — на самом деле, мы задаём область видимости на основе не объекта, а класса. В случае с нашим классом “Foo”, вы можете работать с любым приватным Foo любого другого Foo, как показано выше.
О деструкторе
Деструкторы опасны, не полагайтесь на них, поскольку PHP их не вызывает даже в случае фатальной ошибки:
А что насчёт порядка вызова деструкторов в том случае, если они всё-таки вызываются? Ответ хорошо виден в коде:
Здесь продемонстрированы три стадии вызова деструктора:
PHP не вызывает деструкторы в случае возникновения какой-либо фатальной ошибки. Дело в том, что в этом случае Zend работает нестабильно, а вызов деструкторов приводит к выполнению пользовательского кода, который может получить доступ к ошибочным указателям и, в результате, к падению PHP. Уж лучше сохранять стабильность системы — поэтому вызов деструкторов и блокируется. Возможно, в PHP 7 что-то и поменяется.
Суммируя вышесказанное: не доверяйте деструкторам критически важный код, например, управление механизмом блокировки (lock mechanism), поскольку PHP может и не вызвать деструктор или вызвать его в неконтролируемой последовательности. Если всё-таки важный код обрабатывается деструктором, то как минимум самостоятельно контролируйте жизненный цикл объектов. PHP вызовет деструктор, когда refcount вашего объекта упадёт до нуля, а это значит, что объект больше не используется и его можно безопасно уничтожить.
Использование класса в другом классе
мне нужно применить переменные класса Settings в классе Work но мне пишет
Помощь в написании контрольных, курсовых и дипломных работ здесь.
получение объекта в другом классе и его использование
Здравствуйте, не давно изучаю php, и столкнулся с такой проблемой: Допустим есть класс Request и.
Обьявление экземпляра класса в другом классе
Здравствуйте дорогие форумчане, не могу понять почему дочерний класс контроллера, не вызывает метод.
Вызов статического метода класса в другом классе
Как вызвать статический метод из одного класса в другом? вот этот код не работает class A<.
Как вызвать метод класса в другом методе этого же класса?
12
мне нужно чтобы один класс собирал все настройки которые нужны для дальнейшей работы а остальные классы использовали эти переменные (настройки) в своих функциях.
вы предлагаете просто переменные настроек сделать публичными и тогда применять в функциях других классов как простые переменные?
или как вы посоветуете сделать мною задуманное правильно?
Добавлено через 5 минут
да и как мне вообще использовать функцию одного класса в другом?
caballero, На самом деле ситуации разные могут быть. Может, у нас будет 7 табуреток с одними настройками и 2 табуретки с другими настройками, а также кирпичи все с одинаковыми настройками и шкафы с индивидуаотными настройками каждый. В конце концов, при необходимости можно же и от настроек унаследовать дочерние классы c определенными отличиями.
В общем, спорить можно долго и бессмысленно. Все зависит от конкретной ситуации. Где-то лапша длинная, где-то короткая.
с другой стороны, многие разработчики считают такой подход плохим тоном.
вы приходите в магазин, берете нужный товар, на кассе с Вас просят 200руб.
Вы же не даете кассиру свой кошелек со словами «Возьми сколько тебе надо»? 
Лучший способ использовать класс внутри другого класса
Я создал этот класс, который выбирает все данные поста из базы данных.
Наряду с постом, мне также нужно получить все данные пользователя, создавшего пост. У меня есть три способа сделать это:
1) Вызовом класса User внутри класса Post.
2) Расширяя класс Post классом User.
Затем вызов методов из класса User
3) Создавая черту User и используя ее в классе Post.
Затем вызов методов из черты пользователя
Между этими тремя, какой из них является лучшим подходом с точки зрения внедрения зависимостей, производительности и чистоты кода?
Решение
Этот вопрос может оказаться в аду, потому что вы запрашиваете мнение, но я добавлю два цента.
Вы в основном строите свой собственный базовый ORM. В той ORM вы имеете дело с сущностями. Разные сущности должны обрабатываться разными классами (моделями), и между базовой таблицей БД и моделью должна быть эквивалентность 1: 1.
Есть отношения между вашими сущностями. У сущности Yous Post есть автор, который должен быть экземпляром сущности User. Однако вы бы не сказали, что связь между таблицей записей и таблицей пользователей означает, что они могут быть представлены одной и той же Моделью или разными разновидностями родительской Модели.
Если бы вы использовали полный ORM (Doctrine, Propel, RedbeanPHP), вы увидите, что такое отношение, как автор сообщения, означает, что при использовании таких методов, как getById() (в твоем случае getPost() ) по умолчанию извлеченная сущность Post будет обрабатывать каждую зависимую сущность.
Итак, если вы считаете, что слишком рано использовать ORM, первый подход легче поддерживать и переносить, когда придет время.
Несвязанное мнение
На данный момент, чтобы получить информацию о посте, вам нужно сделать
Если вы изменили конструктор и добавили метод getById (),
вместо этого вы можете получить данные поста в одну строку
Другие решения
Все зависит от того, что вы собираетесь продолжать делать. С расширенным классом было бы лучше иметь дело, если вы собираетесь использовать постоянные методы других классов. Если вам нужна только часть другого класса, просто вызовите класс и его метод.
ВНИМАНИЕ: расширенный класс ведет себя как один класс. Здесь может быть много коллизий, если у вас одинаковые имена методов и функций.
Я думаю, что это зависит от других аспектов вашего кода. Лично я бы просто расширил класс User, так как не думаю, что использование черт необходимо в данном конкретном случае.
Здесь есть полезная статья об использовании черт в PHP —
Использование черт в PHP 5.4