вот есть у нас класс Код (Text): class A {} мы можем создать столько объектов этого класса сколько нашей душе угодно Код (Text): $class = new A(); $class2 = new A(); и т.д. и они буду работать совершенно не зависимо друг от друга(статические методы и свойства не считаем) так вот вопрос. я ни как не могу понять, где вообще используется множество объектов класса? вот к примеру информация о пользователе которую предоставляет класс User(). зачем мне много объектов когда один все делает? единственная мысль пришедшая мне в голову по созданию множества объектов, так это допустим блог. У нас есть класс Blog() который возвращает массив всех постов в блоге. так же есть класс Article() который возвращает массив с одним постом. так вот объект класса Blog() должен создавать объекты класса Article() и результат его работы помещать в массив. но для этого нужен третий класс который даст нам информацию о том какие посты содержаться чтобы класс Article() мог их брать. к чему такая сложность? ведь проще создать один класс который все сделает. _____________ ну или про третий класс я загнул. тут возможно будет достаточно метода который даст список. хотя все таки помоему отдельный класс буде лучше, т.к. его можно будет использовать как фильтр при расширении приложения.
Нету сложности, есть недопонимание. 1) есть класс Blog() 2) есть класс Article() в классе Article есть свойство blog_id, которое служит для чего?
1) Не используйте классы там, где они не нужны. PHP прекрасно переваривает гибридный подход. 2) У меня, к примеру, изоляция компонентов системы друг от друга идет с помощью объектов. И наследуются они от единого предка, реализующего общую часть кода, дабы не множить энтропию. При этом сама система 100% процедурная, потому что ей для работы классы не нужны, кроме пары статичных регистров.
Вот, кстати, вам пример из моей CMS (которую сейчас сочиняю): есть модульная позиция, а в ней есть много модулей.
Скажем так. В вебе в 99% случаев объект не нужен. Несколько объектов нужно тогда, когда нужно несколько объектов. Объект это прежде всего инкапсуляция свойств и методов. Т.е. передавая его куда-либо, ты передаешь объект со всем его личным уникальным барахлом. Внешне он выглядит проще, чем внутри. И так проще жить. Таким образом объекты полезны не только, когда надо несколько индивидуальностей одной сущности, но и когда просто не хочется вытаскивать всю кухню наружу. В пхп своя специфика. Тут всё рождается и умирает распланировано. Однако, когда ситуация требует чистить данные, прежде чем внести новые - проще убить объект со всем его содержимым и родить новый, чистый. Таким образом танцевать надо от печки, а не от правильности и концептуальности.
Ну да, прописаны. Цель - чтоб модуль можно было засунуть в любое место шаблона. Но это не только Joomla-way. В WordPress это называется виджетами, в Drupal - блоками, в Open Cart и InstantCMS - тоже модулями. Короче, это уже как стандартное решение для CMS Добавлено спустя 6 минут 10 секунд: Не, ну хранятся в объекте только свойства. Методы же существуют в единственном экземпляре, просто они получают скрытый параметр $this, так что передаются только свойства.
У всех объектов класса A методы одинаковые. У объектов-наследников могут быть другие методы, но в любом случае они не передаются как чаcть хранимой с объектом информации. Они - обычные функции php, только имеющие скрытый параметр $this.
В пхп это не так. Это верно в 99%. Но по факту переопределить методы можно при сохранении типа. Скриптовые языки типа пхп и Js крайне демократичны.
Заинтриговали. Про JS знаю как это сделать, в JS вообще нету классов как таковых, про PHP - нет. Можете кодом продемонстрировать? Код (PHP): class A { public function b() {echo "aaa"; } } $a = new A; Переопределите пожалуйста метод b() прямо у $a, сохранив тип
ну не. если это предусмотрено извнутре. потенциально в пхп есть возможность вызвать что-то по названию в строке аж двумя способами. и этот экземпляр может исполнять другой код из того же метода, что другой объект из этого же метода. плюс есть ивал. А в яваскрипте совсем безумие с этим конечно. в примере с замыканиями можно предусмотреть переопределение функции http://us3.php.net/ru/functions.anonymous.php и будет тебе два одинаковых объекта одного класса, но с разным кодом в том же методе. Объект может по-разному вести себя в зависимости от данных, и ведет =) Если у вас эта ваша статья из бложика, она объект того же класса, что и другая. А на выходе ее методов всё иначе. И вполне если надо можно переопределять методы тем же ивалом. В CMS поддерживается исполнение кода из БД. По сути это другой код в том же методе. Там что угдно может быть. Таким образом наличие экземпляра объекта гарантирует что он не другой такой же, а именно этот. и код там правильный и данные те. это снимает груз с мозгов. в противном случае нужно как-то морочиться с одинаковой инициализацией, передавать данные, которые однажды уже были собраны в объект. Это всё куда сложнее, чем тот же самый объект гонять. т.е. объекты являются способом упрощения рабочего процесса, а не способом решения задачи.
и что? =) метод тот же, код другой, результат другой. Плюс есть трейты. Они писали с высокой колокольни на все наследования. =) Это ж PHP, ребят. Тут рамок почти нет. А в JS нет вообще.
Ээээ.....нет. Не они плевали, а ты У них-то как раз все работает правильно. Просто ты не до конца понимаешь смысл наследований и перекрытий. Метод тот же, код тот же, результат зависит от какого-то флага, переданного в параметрах. Это не перекрытие. Перекрытие это когда название метода то же, метод другой, код другой, результат другой. Сама суть перекрытий - не заставить метод работать иначе. Ради таких вещей не делают отдельные классы. Суть в том, чтобы переопределить реализации унаследованных методов класса. В 95% это выглядит как: Код (PHP): class Parent{ public function foo(); } class ChildA extends Parent{ public function foo(){ echo "Hi!";} } class ChildB extends Parent{ public function foo(){ echo "Pewpew!!!";} } И есть где-то какая-то функция, которая понятия не имеет о класах ChildA и ChildB, но она умеет работать с Parent и знает, что у него есть метод foo. И подобное перекрытие гарантирует, что эта функция будет прекрасно работать с потомками, потому что они реализуют те же методы, но по-своему. А если родительский класс пометить абстрактным, то вообще, потомки будут обязаны реализовать все абстрактные методы, иначе ничего не будет работать.
Это в сях так. И то можно изловчиться. А тут весь выполняемый код может быть иным. Ладно. Разговор был о другом. =) О том, что в объектах, идентифицируемых как один и тот же класс, легко может жить разный код. В том или ином виде. Поэтому и делают объекты и их передают. Разговор пошел по кругу. Это тема наследования. Вопрос был зачем делать экземпляры объектов. Именно экземпляры.
При чем тут си? Что значит изловчиться? О чем ты сейчас? Как тут весь исполняемый код может быть иным? Через eval? Для такой функции исполняемый код всегда один и тот же, меняется только содержимое параметра: Код (Text): function foo($code){ eval($code); } Не может. Если может, покажи пример. Именно разного кода, а не разного поведения. Код будет всегда один и тот же. IF не меняет код, он указывает, какой вариант развития событий должен соответствовать определенному правилу. Это прекрасно работает без объектов. Можно просто создать функцию и дергать ее. Другое дело, если у тебя есть, скажем, родительский класс "компонент". У него есть метод "инициализация". И для каждого потомка она своя, потому что у каждого свои кишки и каждый потомок сам определяет, как эти кишки правильнее развернуть. Делает это, переопределяя "инициализацию" и являясь отдельным объектом. И есть у тебя система, которая получает набор компонентов и не знает о них воообще ничего, кроме того, что у них всех есть метод "инициализация", который надо дернуть в нужный момент, чтобы компонент развернулся. Ей плевать, что при этом произойдет и какой код там внутри, объект сам решает, как реагировать на это. Чтобы в разных объектах, реализующих общий интерфейс, работал разный код, делают наследование и перекрытия. И это будут объекты разного типа с общим предком. Но никак не однотипные. За тем, что класс определяет структуру объекта, а объект является экземпляром класса. Не пытайся перевести тему, а признайся, что несколько заблуждаешься в плане ООП ввиду того, что мало с ним работал. Это нормально. Я на пхп точно так же юзаю ООП на крайне примитивном уровне, потому что другое тут и не нужно. Но до пхп был немалый опыт Java, C++, C#, потому имею представление о том, что говорю. Там хочешь не хочешь выкуришь всю теорию на этот счет на зубок, просто потому что постоянно с этим работаешь
да. ты топик почитай сверху. вопрос не о том. если ты мне покажешь границу между этими понятиями в скриптовом языке, я подумаю =) Добавлено спустя 45 секунд: весь топик об этом. Добавлено спустя 47 секунд: я не спрашивал =) Добавлено спустя 2 минуты 31 секунду: я вообще не перевожу тему. я искренне воспринимаю пхп как язык у которого всё весьма аморфно и прозрачно. хочу - меняю. не хочу - не меняю. механизмы есть. а делать так или нет - это вопрос уместности. у них нельзя подменить КОД и отправить его на компиляцию в любой момент работы программы. а в пхп - можно. вы старые свои навыки в новый монастырь несете и негодуете, что есть люди, которые так не делают. =)
Ты правда не видишь разницу между ветвлением и переопределением? И при чем тут скриптовый язык? Эхехе... Какой бы ты не вбил параметр, код функции ты не меняешь. Просто функция является оберткой над eval. Но ее код ты никак не можешь поменять. В противном случае покажи мне, как ты подменяешь код в любой момент работы программы. Инклудом? Это обычный сишный инклуд. Любая вставка кода инклудом - не смена такового, а лишь упрощение работы программиста. Инклуд позволяет меньше печатать и копипастить и не раздувать исходники дубликатами кода. С тем же успехом можно просто написать if (){ простыня на тыщщу строк } else{ вторая простыня } Или даже бомбануть свитч. Но это не подмена кода во время выполнения. Это все один и тот же код, который ветвится. Более того, в компилируемых языках есть такая штука как reflection. Можно на лету в оперативке собирать фрагменты программы, которые изначально в ней не содержатся. Как бы код, пишущий код. При чем, в отличие от php не между вызовами, а прямо во время работы. Но даже это не является "заменой кода" или "подменой кода". Класс четко и конкретно описывает то, что содержится внутри объекта. Нужно другое содержимое - заводи другой класс.
я считаю иначе =) я вообще не вижу разницу как именно скармливать интерпретатору код. а если инклуд? =) а если каждый раз разное содержимое инклуда? а если содержимое вообще генерится? окей, я тупое говно. оставайся в своих рамках мышления. ты так упорно защищаешь свою клетку, которую бережно выстроил в компилируемыех языках, что я чуток фигею.
то это будет справедливо для каждого экземпляра данного класса. Во всех экземплярах будет заново сгенеренный инклуд. Любая программа - есть связная система. Любая система подчиняется определенной логике. Если эта логика основана на рандоме, то ты теряешь контроль над системой. С тем же успехом можно на рандоме фигачить свойства объектов и верить, что в данный момент у данного объекта будет именно то значение и того типа, которое нужно. Это справедливо не только для скриптов. В компилируемых такое тоже замутить можно. И толку? не, просто тебе трудно принять чужую мысль И в споре я не преследую цель унизить оппонента. С тем же успехом я могу сказать, что ты так одичал в своем скриптовом лесу, что боишься зайти даже в деревянный туалет. В лесу проще, какай где угодно, подтирайся чем хошь, хоть листочком, хоть бельчонком. А в туалете стены, ограничивающие обзор, срать нужно только в дырку, и подтираться нечем, кроме бумаги. Если тереться об косяк, можно занозы набрать. Но туалет логичен, однозначен, легко обслуживается и имеет четкие интерфейсы. Беда в том, что если Сишник приходит в ПХП и начинает посреди леса строить туалет, то туалет работает. А если пхпшник приходит в сишный дом и начинает срать по углам и ездить попой по ковру, это кончается печально. Но эт так, метафоры. Соль в том, что все, то ты описываешь, не требует объектов. Ты просто не совсем понимаешь, в чем их суть и начинаешь спорить ради спора.