необходимо множественное наследие
- Автор темы Духовность™
- Дата начала
вот ещё один вариант, правда сильноупрощённый
PHP:
abstract class Multi {
protected $_parents = array();
public function __construct() {
$parents = func_get_args();
$this->_parents = array_merge($this->_parents, $parents);
}
public function __call($a, $b) {
foreach ($this->_parents AS $v) {
if (method_exists($v, $a)) {
$v->{$a}();
break;
}
}
}
}
class FirstParent {
public function doThis() {
echo 'FirstParent<hr/>';
}
}
class SecondParent {
public function doThis2() {
echo 'SecondParent<hr/>';
}
}
class Test extends Multi {}
$o = new Test(new FirstParent(), new SecondParent());
$o->doThis();
$o->doThis2();Подрыв мозга
Новичок
Да, только это не наследование - класс Test не пройдет в функцию, принимающую аргумент типа FirstParent или SecondParent
PHP:
function doSometing(FirstParent $param)
{
}
doSomething(new Test()) // <- Ошибка
Духовность™
Продвинутый новичок
В общем, это я тупил. Т.н. "множественное наследие", то, что мне нужно было, у меня не получилось в виду банальной ошибки. На самом деле пост Тони вправил мозги. Под множественным наследованием я имел в виду способность класса С иметь доступ к методам и свойствам класса А:
я доволен 
PHP:
class a
{
protected $a;
function __construct()
{
$this->a = 1;
}
public function priint()
{
echo $this->a.'<br>';
}
}
class b extends a
{
function __construct()
{
parent::__construct();
}
}
class c extends b
{
function __construct()
{
parent::__construct();
}
}
$a = new a();
$a->priint();
$b = new b();
$b->priint();
$c = new c();
$c->priint();ну так и множественного наследоания как такового нету в пхп, да и вообще это весьма сомнительная штука, так что type hinting-гу не место, там где используют костыли.
а о сторонних библиотеках не совсем понял, их можно с лёгкостью интегрировать, хотя с ИМХО минимальным переписыванием
cDLEON
Онанист РНРСlub
На самом деле не вижу смысла наследовать сразу две модели.
Помоему, этот метод немножко похож на рождение ребёнка.
Учавствуют два объекта, один рожает, а 3-ий из них получается, только вот какие гены и у кого 3-ий унаследовал ни фига не ясно.
Вариант Тони самый правильный...
Помоему, этот метод немножко похож на рождение ребёнка.
Учавствуют два объекта, один рожает, а 3-ий из них получается, только вот какие гены и у кого 3-ий унаследовал ни фига не ясно.
Вариант Тони самый правильный...
Подрыв мозга
Новичок
Это не костыли. По поводу библитотек: предположим авторы PEAR решили что в этот метод должен передаваться класс типа IPearClass, ссответственно, ваш класс, не реализующий этого интерфейса туда не влезет, не сморя на то, что синатуры методов совпадают. Вы можете убрать type hint в сигнатуре но, нет никакой гарантии, что где-то в недрах кода не происходит привдение к данному типу или передача другой функции, ожидающей параметер этого типа. Кроме того, ваш коллега кодер Вася, может ничего не знать о подобных вмешательствах, или произойдет слияние вашей компании с другой, использующей ту же немодифицированную библиотеку. Далее, это возможно только при доступном исходном коде... А еще есть удаленные методы на внешних серверах... В общем, вариантов получить геморой много. А потом выйдет новая версия библиотеки... и все надо будет делать заново.
type hint в отношении множественного наследование бесполезная штука.
я предложил зачатки _одного_ _из_ _методов_ реализации подобия множественного наследования на php. плюсы метода в том, что однажды написав класс его можно использовать для создания видимости множественного наследования с минимальным изменением кода наследуемых классов. используя делегирование и магические методы получается простенький код, без нагромаждения интерфейсов, и кучи лишнего кода.
минус - отсутствие type hint
в любом методе код получится диким и вредным.
я предложил зачатки _одного_ _из_ _методов_ реализации подобия множественного наследования на php. плюсы метода в том, что однажды написав класс его можно использовать для создания видимости множественного наследования с минимальным изменением кода наследуемых классов. используя делегирование и магические методы получается простенький код, без нагромаждения интерфейсов, и кучи лишнего кода.
минус - отсутствие type hint
в любом методе код получится диким и вредным.
Подрыв мозга
Новичок
ORM и ООП тесно связаны - ORM как раз-таки находится на стыке функцинального и объектного программирования, фактически, это мост между ними, и являются очень хорошим местом, где можно невзначай "прострелить себе ногу".
Большинство веб-сайтов ни что иное, как интерфейс к базе данных. По классической схеме ООП, магазин, трогующий карандашами, бубликами и яхтами должен, был бы выглядеть так: классы Покупатель, Заказ, Товар; классы Карандаш, Бублик, Яхта наследуют от Товара. Все здорово - берем вычитываем в книжке Фаулера про шаблон Active Record и храним все объекты в базе. Но это работает только в том случае, если все классы в модели известны заранее, а в случае с магазином это не так.
Между карандашами, бубликами и яхтами нет ничего общего кроме идентификатора, поэтому класс Товар сделать можно, но кроме технических полей он ничего полезного содержать не будет. Как добвлять\удалять потомки класса Товар? Попытака генерить классы кодогенератором и компилировать их после того, как пользователь добавит их в интерфейсе CMS обречена - пользователь может не знать английского языка, принципов ООП, и вообще он может в любой момент удалить поля товара, так что расчитывать на неизменную структуру класса не стоит. Классы в мейнстримовых языках не могут изменяться, поэтому на арену выходят всякие DataSet'ы, RecordSet'ы, ассоциативные массивы. В этом месте вы будете вынуждены пересмореть классическую схему и заменить классы-товары на ассоциативные массивы, которые и хранить в базе.
В ООП классы содержат ссылки друг на друга. Чтобы получить все товары, заказанные Покупателем вам надо путем переходов по графу объектов перебрать часть графа, пока не будет найдено то, что нужно. Я не буду утомлять объяснениями, почему навигационная система классов в реальной жизни проигрывает запросной системе SQL.
Вместо классов - массивы, вместо навигации - запросы. Признаем очевидное: вы эмулируете с помощью ООП-языка фишки функциональных языков. Даже бизнес-логика, если она есть, работает не над объектом, а над ассоциативным массивом. А если это все равно эмуляция, не проще ли добавить ФП в уже существующий ООП-язык? Так оно и проиcходит: забегали люди с лопатами и начали хоронить кто С++, кто Java. "Нас не интересует судьба Java - если Java умрет, мы перейдем на Scala." - говорят они. Все больше IDE поддерживат Ruby и Groovy; всеми любимый Miсrosoft вводит элементы ФП в С# 3.0 и спонсирует разработку F#; в PHP проснулись и робко заговорили о лямбдах и замыканиях; отчаявшишиь расшевелишь Sun, энтузиасты хачат Java. Растущее количество процессоров прямо подталивает к рапараллеливаню, как следствие к ФП. Люди устали от старых, дряхлых языков, и гиганты индустрии неохотно вынуждены реагировать на это.
Первые популярные ORM появились давно - тогда попытка подогнать данные под объекты казалась естественной. Испытание временем показало: иногда это работает, иногда нет. Сейчас ситуация меняется - чем больше ФП проникет в мейнстрим, тем меньше приходится извращаться, но чтобы успешно использовать это (или наоборот - избегать ошибок) требуется изменить сознание и начать думать иначе. Например, использоать ROM вместо ORM, интересующиеся могут поискать в сети на тему Microsoft LINQ to SQL или зайти на форум rsdn.ru - там эти темы часто обсасываются.
korchasa
LIMB infected
Разве продаются карандаши, бублики и яхты, а не товары? Разве яхты, бублики и карандаши можно только продавать? Цена, скидка, дата начала продажи, количество на складе - это же свойства товара, да?
Хранении данных в виде DataSet'ов и прочих "массивов" имеет смысл, когда это настолько снижает стоимость добавления новых сущностей, что экономия на этом покрывает расходы на усложнение общей логики сущности Товар. Для валидации свойств сущностей Яхта, Карандаш и прочих, придется вводить какие спец инструкции. Для обеспечение работы этих инструкций придется писать код. Рано или поздно придется добавлять новые валидаторы, а следовательно опять понадобиться программист. К тому же по данным в "массивах" тяжело делать аналитику.
ЗЫ: Далеко не все системы требуют частого добавления новых сущностей. Даже магазины
Духовность™
Продвинутый новичок
atv
Новичок
Подрыв мозга, большинство твоих рассуждений касается КОНКРЕТНОЙ АБСТРАКЦИИ называемой ORM, а не ООП парадигмы в целом. Поэтому ещё раз говорю, что не стоит целиком распространять выводы касательно такой АБСТРАКЦИИ как ORM на ООП. Тот же DataSet (или RecordSet) - это тоже АБСТРАКЦИЯ существующая в рамках того же ООП.
И ещё по поводу термина "функциональное программирование". Дело в том, что существуют "процедурное программирование" и "функциональное программирование", что не совсем одно и тоже. Функциональное программирование, это более новый подход, опять же, используемый в своей области. Какой именно подход имел ввиду ты в своём посте?
И ещё по поводу термина "функциональное программирование". Дело в том, что существуют "процедурное программирование" и "функциональное программирование", что не совсем одно и тоже. Функциональное программирование, это более новый подход, опять же, используемый в своей области. Какой именно подход имел ввиду ты в своём посте?
Подрыв мозга
Новичок
>>> Разве продаются карандаши, бублики и яхты, а не товары? Разве яхты, бублики и карандаши можно только продавать? Цена, скидка, дата начала продажи, количество на складе - это же свойства товара, да?
Да свойства Товара. В программной реализации это может быть Объект, Кортеж или Запись. Не факт, что Объект - это лучшая форма пердставления товара.
>>> Для валидации свойств сущностей Яхта, Карандаш и прочих, придется вводить какие спец инструкции. Для обеспечение работы этих инструкций придется писать код. Рано или поздно придется добавлять новые валидаторы, а следовательно опять понадобиться программист.
Понимаю, пример можно, чтобы не абстрагироваться?
>>> К тому же по данным в "массивах" тяжело делать аналитику.
Тоже примерчик не помешало бы.
Вратце: когда я увижу, что вас каждой позиции товара в магазине соответствет отдельный класс (в случае с Амазоном это десятки тысяч классов) я поверю, в то что это OOП - иначе это не объекты, а кортежи.