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

[Screjet]

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

Люди, по опыту в DELPHI знаю, что класс можен наследовать несколько классов, есть ли нечто подобное в ПХП?
типа
class big_gun extends (base,gun) {
...
}

?

но последовательное наследование не подходит, типа этого:
class base {
...
}

class gun extends base {
...
}

class big_gun extends gun {
...
}

 

[.des.]

множественного наследования в пхп нет.
заменяй аггрегированием.

а в Delphi оно разве есть?

 

[Screjet]

в делфах есть
type Form1 = class(base1_class,base2_class)
...
end

ладно.. придется обойтись.. хотя такое свойство не помешало бы

 

[Crazy]

Есть мнение, что гражданин Screjet заблуждается (разве что ситуация поменялась в Delphi7): множественного наследования классов в Delphi нет.

Гражданин, вероятно, спутал классы с интерфейсами. Такого множественного наследования в PHP нет, поскольку оно лишено смысла в языках без жесткой типизации.

 

[Screjet]

Почему же лишено смысла?
у меня есть три базовых класса А Б В
мне нужен класс Г, который будет наследовать свойства и методы классов А и Б
так же нужен класс Д, который будет наследовать св. и мет. классов Б и В

 

[Crazy]

Еще раз: с тремя базовыми классами Delphi выдаст тебе ошибку компиляции.

С одним классом и двумя интерфейсами ты получить совместимость по типу с этими двумя интерфейсами.

Поскольку в PHP вообще все классы совместимы по типы, проблемы данной нет и решать ее незачем.

Для контроля попробуй скомпилировать вот этот простой пример:

unit Foo;

interface

type
  TA = class end;
  TB = class end;
  TC = class (TA) end;
  TD = class (TA, TB) end;

implementation

end.

 

[Screjet]

Дело не в совместимости типов, а в наследовании...
Хорошо.. Пусть вопрос будет стоять так:
Возможно ли в ПХП создание интерфейсов?? (хотя не пойму, зачем такие извращения, если можно было бы все гораздо проще)
И еще.. прошелся по форумам, действительно, программисты пугаются множественного наследования.. и один аргумент, такая необходимость возникает редко.. Но вот она возникла, есть ее решение в ПХП? или аггрегировать классы и всегда один или более классов будут болтаться в объекте неиспользуемые?

 

[si]

Возможно ли в ПХП создание интерфейсов

www.php.net

если можно было бы все гораздо проще

Кто вам мешает включится в разработку нового движка для РНР (zendEngine2)

 

[Crazy]

Автор оригинала: Screjet
Дело не в совместимости типов, а в наследовании...

Именно в совместимости. Поскольку множественного наследования реализации в Delphi нет. А ты хочешь именно этого.

Пусть вопрос будет стоять так:
Возможно ли в ПХП создание интерфейсов??

Боюсь, что ты не понимаешь смысла, который в Delphi заложен в это понятие. В PHP они не нужны. Совсем. Абсолютно. Если же тебе очень хочется их иметь, то просто закрой глаза и представь, что каждый класс реализует сразу ВСЕ интерфейсы. Даже те, которые еще не придуманы. Все сразу. Так что "множественное наследования a la Delphi" у тебя в PHP уже есть -- можешь пользоваться.

(хотя не пойму, зачем такие извращения, если можно было бы все гораздо проще)

Разделение на интерфейсы, которые не содержат кода и могут множественно наследоваться с одной стороны, и на классы, которые содержат код, но не могут множественно наследоваться весьма распространено в жестко типизированных языках (Delphi, Java), поскольку как раз и является самым простым решением.

И еще.. прошелся по форумам, действительно, программисты пугаются множественного наследования..

А чего его бояться? В нем пользы особой нет. Такой, чтобы оправдать сопутствующий геморрой.

или аггрегировать классы

Именно. Это стандартное решение.

и всегда один или более классов будут болтаться в объекте неиспользуемые?

Что мсье имеет в виду?

 

[Screjet]

Именно то, что ПХП будет тратить процессорное время на парсинг ненужного кода, то, что этот самый код будет занимать память и т.д.
В таком случае можно еще проще сделать: написать один большущий .пхп файл в котором будут описаны все переменные, все функции, и исп. этот файл как библиотеку... Хорошо, когда какая-то малюсенькая задачка, этот вариант вполне подходит, а когда кода больше сотни кило? Тогда просто нужно будет раскошелиться на какую-то дорогущую машину, которая сможет обработать определенное число пользователей и нерентабельный код.. Или переезжать на устарелый Perl или дырявый ASP. А хотелось бы работать с ПХП.

 

[.des.]

Или переезжать на устарелый Perl

ты парень попал
придет Crazy объяснит тебе что к чему

А теперь :

Именно то, что ПХП будет тратить процессорное время на парсинг ненужного кода, то, что этот самый код будет занимать память и т.д.

ну дык а если бы ты его наследовал то код бы не парсился? о чем ты вообще?

 

[Screjet]

Всмысле наследовал выборочно (в коде, не в рантайме):
есть три базовых класса А Б В
нужен новый класс Г, который наследует А и Б, но совершенно не нужно наследовать класс В
также нужен класс Д который наследует Б и В, но совершенно не нужно наследовать класс А
Как этого достич?

 

[Screjet]

Прим. это весьма простой пример.. Ситуация обстоит так, что классов будет около сотни. Возможно я вообще выбрал не тот подход.. Люди добрые, подскажите !

 

[.des.]

class D extends A {
    function D() {
        A::A();
        $this->B=& new B();
    }
}//D

// или вообще без наследования.
class D {
    function D() {
        $this->A=& new A();
        $this->B=& new B();
    }
}//D

100 классов? ты может на ява пишешь и немножко ошибся ?
Мне сложно представить проект на PHP, где реализуется столько классов да еще возникает острая необходимость множественного наследования.
Хотя все таки наверное не Ява там тоже множественного наследования нет.

короче. Ты может быть попросишь совета в разумности проектирования.. расписав предварительно задачу поподробнее?

 

[Screjet]

Да, действительно, в простых задачах я применяю агрегирование, но крайне неприятно когда "в роду не без уродов", т.е. потомок содержит ненужных родителей...
Пологаюсь на Вашу мудрость..

 

[.des.]

Screjet пойми же.. как раз множественное наследование обеспечит тебе геморрой. Вот тогда ты точно с трудом будешь знать какой класс где кого наследует и сколько раз хотя спорить о том чего в пхп нет занятие довольно бесполезное.
При аггрегировании же все на порядок проще. Да может быть и не так красиво, но черт с ней с красотой то.
Не добавляй себе проблем. Объясняй свою задачу. Откуда столько классов?

 

[Screjet]

У меня идея просто расширять функциональность потомка его родителями. И смешивая родителей получать новых потомков, т.е мне не нужен суперпотомок, который будет наследовать ВСЕХ родителей. Возможно ли такое?

 

[Screjet]

.des.

Скажу так, предыдущая версия, была написана модульным способом, очень плохо поддается доработке/корректировке, я пришел к решению, что с этой проблемой поможет объектно-ориентированный способ, дабы разбить все методы и свойства задач на объекты, но вот столкнулся с такой проблемкой.. Да, создав такой суперкласс, можно былобы и работать.. Но как поведет себя ЗендМашина с таким суперклассом? Не будут ли протормозки из-за того, что ей придется постоянно парсить такое большое количество кода? Ведь код ПХП не запускается один раз навсегда(типа какогото приложения), а постоянно загружается - выгружается.

 

[Crazy]

Автор оригинала: Screjet
Именно то, что ПХП будет тратить процессорное время на парсинг ненужного кода, то, что этот самый код будет занимать память и т.д.

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

На самом деле все строго наоборот: используя агрегацию можно отложить парсинг исходников базовых классов до тех пор, пока не будут вызваны соответствующие методы. Общая идея:

class Descendant {
  var $ancestor1 = null;
  // ...
  var $ancestorN = null;

  function foo() {
    if ($this->ancestor1==null) {
      require_once "ancestor1.php";
      $this->ancestor1 = new Ancestor1();
    }
    return $this->ancestor1->foo();
  }

}

Или переезжать на устарелый Perl или дырявый ASP. А хотелось бы работать с ПХП.

Нас старевший Perl4 переезжать, разумеется, не стОит.

 

[Crazy]

Автор оригинала: Screjet
И смешивая родителей получать новых потомков, т.е мне не нужен суперпотомок, который будет наследовать ВСЕХ родителей.

При чем здесь "т.е." и что за навязчивая идея о наследовании всех родителей?

Я, кажется, догадываюсь, откуда ноги растут у этого утверждения, но хочется знать наверняка...