несовместимость классов в php 5.2.10
- Автор темы tf
- Дата начала
pilot911
Новичок
надо, конечно
например, когда вьюверы наследуют один класс, причем, главный вьювер содержит более расширенную функцию инициализации
можно, конечно, использовать другой метод - но зачем плодить код, когда функциональность может быть определена для двух типов вьюверов в одном методе ?
dimagolov
Новичок
угу. и отлаживать на сях офигительно классно. смотря на вызов метода объекта ты нифига не можешь понять какой именно вызов происходит. потому что для того, чтобы это понять надо точно знать тип объекта на который ссылается переменная. а еще веселей становится при переопределении операторов. там мало догадаться, что он был переопределен, надо еще догадаться о том, какое приведение типов аргументов произойдет и в соответствии с этим какая из переопределенных ф-й будет вызвана.
Если ты про с++ то там все иначе, нашел с чем сравнить. Но там тебе тоже никто не даст положить МПХ на совместимость интерфейсов - ты обязан явно, в декларации конструктора, указать правильный вызов parent-конструктора. В php же нет конструкции, аналогичной
class TB: public TA {
public:
TB(int x, int y): TA(x)
а вообще это еще та жопа, этот ваш c++. Миллионы способов выстрелить себе в ногу. Одна перегрузка операторов чего стоит.
class TB: public TA {
public:
TB(int x, int y): TA(x)
а вообще это еще та жопа, этот ваш c++. Миллионы способов выстрелить себе в ногу. Одна перегрузка операторов чего стоит.
berkut
Новичок
мне вот при переходе c 5.1 на 5.3 либа морфиер фаталити стала делать
PHP:
abstract class phpMorphy_Morphier_Common extends phpMorphy_Morphier_Base {
protected function getAnnotSize() { return 15; }
protected function decodeAnnot($annotRaw) {
/* ... */
}
}
/* обрезанный ниже */
class phpMorphy_Morphier_DictBulk extends phpMorphy_Morphier_Common {
function phpMorphy_Morphier_DictBulk() {
parent::phpMorphy_Morphier_Common($fsa, $graminfo);
//parent::__construct($fsa, $graminfo); // mod
}
}
new phpMorphy_Morphier_DictBulk();Lightning
Трудоголик
pilot911
AmdY
В ООП потомок наследует ВЕСЬ интерфейс предка.
Если ты видишь, что нужно наследовать только кусок интерфейса, значит код спроектирован неправильно.
Исправить несложно:
Если необходимо наследовать часть интерфейса, делаешь выделение интерфейса.
Если необходимо наследовать часть реализации, делаешь выделение суперкласса, если не получается, то выделение класса и замену наследования агрегацией.
AmdY
В ООП потомок наследует ВЕСЬ интерфейс предка.
Если ты видишь, что нужно наследовать только кусок интерфейса, значит код спроектирован неправильно.
Исправить несложно:
Если необходимо наследовать часть интерфейса, делаешь выделение интерфейса.
Если необходимо наследовать часть реализации, делаешь выделение суперкласса, если не получается, то выделение класса и замену наследования агрегацией.
dimagolov
Новичок
pilot911, пойми, когда разрабатывали общие концепции ООП, то нифига не имели опыта ООП разработки, по крайней мере долгосрочного. А вот когда такой опыт появился, то оказалось, что не всякий полиморфизм одинаково полезен, часто он становится средством прострелить себе ногу.
Разработчики PHP на данном этапе считают, что язык должен не реализовывать парадигму ООП абстрактно, а делать это так, чтобы упрощать разработку, а значит по меньшей усложнять возможности выстрелить себе в ногу и помогать поддерживать хорошую архитектуру, а иногда прямо запрещать создавать плохую. Изменение интерфейсов при наследовании это плохая архитектура, попросту это говнокод.
Разработчики PHP на данном этапе считают, что язык должен не реализовывать парадигму ООП абстрактно, а делать это так, чтобы упрощать разработку, а значит по меньшей усложнять возможности выстрелить себе в ногу и помогать поддерживать хорошую архитектуру, а иногда прямо запрещать создавать плохую. Изменение интерфейсов при наследовании это плохая архитектура, попросту это говнокод.