|
|
|
| Я прочитал книгу, несколько статей по ООП. Но так и не понял, зачем?
Допустим, у нас есть потребность в реализации новостного модуля на сайте. Для погашения потребности мы пишем класс, в котором реализуем все необходимые методы. Все работает, все довольны. Зачем мне дополнительный код в виде абстрактных классов или интерфейсов? | |
|
|
|
|
|
|
|
для: G-Style
(15.11.2012 в 11:53)
| | Немного не в том ключе размышляете: от реализации идете к архитектуре, а нужно от архитектуры к реализации.
Допустим у вас 20 сайтов, на 20 сайтах по 15 программных блоках вроде новостного модуля (набор модулей разный), на ряде сайтов используется выборка из MySQL, на ряде из PostreeSQL, где-то нужно выводить постранично содержимое XML-файлов, где-то постраничная навигация в формате 1 2 3 далее, где-то [1-10][11-20][21-30]...[5110-1120], понятно, что везде разный дизайн, требующий разных тэгов-оберток.
Итак 20 * 15 = 300 программных блоков. Сколько классов вам потребуется? | |
|
|
|
|
|
|
|
для: cheops
(17.11.2012 в 07:38)
| | Класс можно использовать один – базовый. А в производных переустановить необходимые методы... | |
|
|
|
|
|
|
|
для: G-Style
(19.11.2012 в 11:58)
| | Т.е. у вас в классе, обслуживающем каталог будут методы от новостей и форума? Потеряете в гибкости интерфейса. Если нет, тогда столкнетесь с проблемой, что в ветке новостей у вас используется один класс постраничной навигации, а в каталоге - другой и они чертовски друг на друга похожи. В общем как не крути, вам базовые классы потребуются и не один... ну и кроме того, не следует так сходу отметать полиморфизм, который без абстрактных классов не реализовать - ведь это один из краеугольных камней ООП (и не только в PHP).
Кроме того, есть у вас скажем класс-контейнер, обслуживающий модули, унаследовали вы его от базового супер-класса, а теперь хотите, чтобы контейнер вел себя как массив... в обычно жизни, вы реализуете интерфейс ArrayAccess и можете использовать квадратные скобки для доступа к модулям в контейнере. Тут как поступите, засунете реализацию ArrayAccess в базовый класс? И каждый объект в системе у вас будет массивом? Включая те объекты, которые в принципе должны быть в единственном экземпляре?
PS Если вы что-то видите, лучше попытаться конструктивно понять, зачем это было введено. Как правило, сказать свое веское слово удается один раз из 100 и отказ от абстрактных классов и интерфейсов (в то время, как миллионы программистов их используют, пишут книги, тщательно через лупу разглядывают) идея плохая, если бы эта была рабочая идея - она бы прозвучала несколько лет назад. На самом деле можно обойтись без интерфейсов, но потребуется множественное наследование, которого в PHP нет. Можно обойтись и без абстрактных классов, но вы все-равно будете использовать классы без объектов, от которых будете наследовать классы, в которых должны быть реализованы одинаковые методы (банально вы в методе базового класса можете перебирать наследников в цикле). | |
|
|
|