Наследование классов

[Screjet]

Лиди, как считаете, может стоит ввести в ПХП множественное наследование, чтоб вместо такого кода:

class Foo {

var $bar;
var $baz;

function Foo(){
	require_once('Bar.class');
	$bar = new Bar();
	require_once('Baz.class');
	$baz = new Baz();
	}

function doBar(){
	$this->bar->doBar();
	}

function doBaz(){
	$this->baz->doBaz();
	}
}

использовать такой код:

require_once('Bar.class');
require_once('Baz.class');

class Foo extends Bar, Baz {
// все атрибуты(свойства) и операции(методы) наследуются автоматически
}

Я не думаю, что это будет очень сложно, а прирост скорости, по моему, очевиден. Нужно как-то развивать язык.

 

[si]

Я не думаю, что это будет очень сложно

Вы так действительно думаете ?

Нужно как-то развивать язык.

А кто вам мешаает ? Разработка идет, присоединяйтесь к ней.

 

[pachanga]

Screjet:
Это будет вообще просто, если еще будет известно, какой из двух интерфейсно одинаковых методов родителя будет вызываться в потомке...
Скажем, есть метод calculate() в обоих родительских классах - какой из них будет вызываться в потомке(та же история и с аттрибутами класса)?

Делай продуманный дизайн - всегда есть 1000 и 1 способ избежать множественного наследования.

 

[Screjet]

pacha,
ты про полиморфизм слышал?
да и понятия интерфейса к ПХП не относится, читай внимательно топик..
да и дизайн, вроде, к коду мало относится..

 

[pachanga]

он издевается

 

[Screjet]

Можно было бы использовать нечто такого:

class Bar extends Foo,Baz {

	function doStop(){
		Foo::doStop($args1);
		Baz::doStop($args2);
	}
}

но только смысла особого не вижу объявлять такие же самые операции(методы) что и в родителе.. В том то и смысл, что потомок дополняет родителя, а не перекрывает его.

 

[pachanga]

думаешь, ты всегда вот так просто знаешь, какие методы могут перекрываться, а если у тебя 4 класса множественно наследуются, каждый имеет еще свою иерархию родителей?

интересно, а что ты будешь делать с одинаковыми по имени аттрибутами, несущими разную смысловую нагрузку?

как бы полиморфизм здесь не причем

пару слов про интерфейс:
при объявлении объектом любой операции должны быть заданы: имя операции, объекты, передаваемые в качестве параметров, и значение, возвращаемое операцией. Эту триаду называют сигнатурой операции. Множество сигнатур всех определенных для объекта операций называется интерфейсом

боюсь, дизайн в твоем понимании ассоциируется пока только с html разметкой

после внимательного просмотра топика, глубокого проникнув идеей жиклера с тормозами, хотел бы резюмировать:
Screjet, у тебя небольшая ООП каша в голове, прочти еще раз все свои материалы, особенно рекомендую:
Приемы объектно-ориентированного проектирования, Э.Гамма, Р. Хелм -- Питер

 

[Screjet]

Автор оригинала: pacha
думаешь, ты всегда вот так просто знаешь, какие методы могут перекрываться,

если не знаешь, что делаешь, то лучше ничего не делать

иерархию родителей?

чтото новое?

интересно, а что ты будешь делать с одинаковыми по имени аттрибутами, несущими разную смысловую нагрузку?

Это можно легко обойти

пару слов про интерфейс:
при объявлении объектом любой операции должны быть заданы: имя операции, объекты, передаваемые в качестве параметров, и значение, возвращаемое операцией. Эту триаду называют сигнатурой операции. Множество сигнатур всех определенных для объекта операций называется интерфейсом

от определений уже голова болит, каждый их интерпретирует по своему

после внимательного просмотра топика, глубокого проникнув идеей жиклера с тормозами, хотел бы резюмировать:
Screjet, у тебя небольшая ООП каша в голове, прочти еще раз все свои материалы, особенно рекомендую:
Приемы объектно-ориентированного проектирования, Э.Гамма, Р. Хелм -- Питер

Спасибо.. хоть буду знать, что читать

 

[pachanga]

ты, знаешь, я удивлен, как тебя еще старожилы не "съели"
очевидно, ехидно посмеиваясь, не хотят втягиваться в этот пустой спор - однако тема красиво называется "наследование классов"

 

[pachanga]

...и как еще пока твой топик не переместили без предупреждения к чайникам?

 

[Screjet]

Ты в чем-то прав.. тема действительно не для профессионалов, но и не для чайников тем более.
Я, наверное, единственный чайник, разрабатывающий ПО в стиле ООП но никто для меня отдельно форум не будет открывать

 

[si]

Я, наверное, единственный чайник, разрабатывающий

пока вы только бредите в этом топике, причем чем дальше тем сильнее. то что вы тут несёте говорит только лишь о том , что вы под ООП понимаете что сильно отличающиеся от обычных общепринятых представлений об ООП.

 

[StUV]

можно выдергивая отдельные посты пополнить ФАК.....
(хотя может там и есть что-то об этом, сорри - не заглядывал)

2Moderators: не могу только понять, как тред вышел таким длинным..... можно было в начале дать х-реф и закрыть (как это делается обычно в случае обсуждения азов )

 

[Demiurg]

>можно выдергивая отдельные посты пополнить ФАК.....
не вижу ничего из разряда фак, да и вообще тред из разряда флейм ни о чем.

 

[StUV]

2Demiurg:
Crazy & (не помню уже...) определений накидали... - можно книгу написать по ООП .

ни о чем

тут ты не прав...

 

[Demiurg]

Определения нужны людям, которые разбираются в предметной области. Если человек с трудом представляет о чем идет реч, то жесткие определения его еще больше запутают.

 

[StUV]

имхо - разбираться в "теме" без определений - зря время убить - через 2-3 стр текста - в голове каша будет....

 

[StUV]

зы: мат.ан. без аксиом и теорем - убивает всякое стремление к знанию ... - здесь та же ... ситуация

 

[Demiurg]

Смотря, что за текст. Ты же в детстве говорил, и строил предложения не зная, что такое глагол, существительное и тд.

 

[StUV]

опять же мое мнение - в голове можно и не держать терминологию при проектировании, но необходимо строго представлять "чего я вообще хочу?"
в детстве - работает интуиция... она у всех разная...
если ФАК будет интуитивным - ..... - не могу слов подобрать