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

Так в чём преимущества? На сколько это вообще помогает в работе? Помогите понять ;) Никогда этим не пользовался, но хочется научится или хотя бы понять...

ps
конечно всё применительно с PHP5.3+

http://ru.wikipedia.org/wiki/%D0%90%D0%B1%...%D0%B8%D1%8F%29

раздел РНР

в том то и дело что видел это и пытался понять, но никак не могу понять зачем такие сложности.. Не хватает понимая какой-то маленькой вещи... и головоломка сложится 

Gold Dragon, Это такая-же, по сути, дисциплинарная фенечка как и implements. Только контроль не на стадии компиляции, а в run-time. Впрочем, для PHP разница не сильно принципиальна. Все абстрактные методы обязаны быть перекрыты,  иначе случится карачун. Примеров разумного применения этих фенечек довольно много в документации и просто в ООП примерах.

просто мне все примеры кажутся очень сложными, т.е. очень много кода, а по сути можно (мне так кажется) сделать и пару строчками. Вот я и не могу уловить суть.. Мне сейчас это представляется как на самолёте перевозить 1 килограмм груза на расстояние 1 километр... 

Толи примеры слишком буквальные и я не вижу всей глубины

Не совсем.
В отличии от интерфейсов абстрактные классы могут нести реализацию общих методов.

Вообще абстракцию нужно рассматривать в совокупности с другими важнейшими понятиями в ООП - инкапсуляция и полиморфизм.

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

Но при таком подходе представь что будет если нужно будет внести изменения в метод сидеть? Придется его изменять в двух местах. А если таких классов больше двух?   

Логичнее написать что-то вроде


Выигрыш - меньше кода, меньше зависимостей, легко редактировать, более гибкая структура.

Добавлено через 1 минуту и 11 секунд
Хм, наверное я больше привел пример из понятия "наследование", но в общем-то интерфейсы и абстрактные классы помогают организовывать работу этого самого наследования.

уже где-то на грани полного понимания, но тут же опять я понимаю простое наследование класса.. И что если "сидеть" разные, например, "сидеть на.." и "сидеть за..."?

Добавлено через 2 минуты и 17 секунд
ps
вот и я пока не осознаю чем абстракция "полезнее"

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

Что даёт абстрактный класс:
1. Реализация обще-функциональных действий (методов) (в сравнении с интерфейсами);
2. Ещё важнее, здесь стоит понять, общие интерфейсы. Как их реализация, так и только их декларация (то есть дочерние объекты будут иметь общий контракт для клиентов, что это даёт смотрим ниже)
3. Абстрактный класс не инстанцируется, что само по себе говорит что он задаёт тип и только задаёт тип, который "стандартизирует" какой то набор интерфейсов (опять же "контракт") 
4. В абстрактных классах можно задавать и общие свойства, интерфейсы этого не имеют.

А теперь из примера  Aliance, использование покажет как абстрактный класс поможет в части "безопасного программирования":


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

Добавлено через 6 минут и 49 секунд
Gold Dragon, 


В обычном классе если сказал "А" (создал метод) то и скажи "Б" (реализовать его).
В абстрактном можно только задекларировать метод, указывая тем что дочернии будут обязаны его реализовать, и тем самым задаёт контракт интерфейсов, не реализовывая их.

Это сообщение отредактировал(а) Sentox - 14.5.2012, 21:11

на мой взгляд абстрактный класс == трейтам 

Вот именно это меня и смущает, именно по этому и не могу осознать целесообразность.

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


PS
??

Gold Dragon, это из PHP 5.4 - trait

Не самая тривиальная мысль   Нельзя ли пояснить, чем "инкулуд внутри описания класса" похож на абстрактные методы?

ksnk, ==, а не ===   

Это сообщение отредактировал(а) MoLeX - 15.5.2012, 08:44

MoLeX, я только начал разбираться, а ты нехороший человек добавил мне ещё "каши" 

Мне кажется это больше попытка использовать множественное наследование, то есть:
extends Class1, Class2 == trait (use)

Да, так и есть это своего рода множественное наследование действий 

Добавлено @ 09:16

Правильно, скелет задаёт инфраструктуру. Что это даёт:
1. Стандартизацию лучший приём программирования, то есть паттерны. При достаточной квалификации разработчик может легко включаться в процесс работы, зная шаблоны проектирования. Почему это включил в тему абстрактных классов, так как они являются основным контрактом интерфейсом и связующим звеном в инфраструктуре, и в большинстве случаев проверяется объект на этот тип, а не тип реализующего класса.
2. Опять же "безопасное программирование", что само по себе уже является большим благом 
3. Чистый код и переиспользуемость дублирующихся участков кода (это если сравнивать с интерфейсами(implements))

Да и ещё, наверное самое главное , если мы задекларируем метод но не реализуем, при инстанцировании его (если допустим сделать такую возможность), клиент вызовет метод не реализованный в нём: вопрос, что произойдёт? Да, логичнее его закрыть как абстрактный (механизм запрета создания объекта, если хотите) и не давать инстанцировать, так как противоречит логическому применению экземпляра класса, в случае вызова не реализованного метода. 

Это сообщение отредактировал(а) Sentox - 15.5.2012, 09:34

К множественному наследованию это не имеет прямого отношения. Это протез множественного наследования   Впрочем даже в качестве протеза это может быть удобно...

Если бы traits'ы были обычными классами, с наследованием и блекждеком - это было бы нормальным множественным наследованием. А так - трейты - это просто заготовки, которые вставляют в описание класса общие для пучка объектов методы. 

Gold Dragon, кратко - абстрактный класс это такой, который может только выступать в качестве базового, создать объект такого типа нельзя. Не бывает просто птиц и самолетов, в программе должен быть конкретный зяблик и ту134. однако все птицы (и самолеты) имеют нечто общее, что нужно
1. задекларировать. если этого достаточно, то нам подходит интерфейс
2. реализовать. т.е. есть некоторое общее поведение, реализация. здесь нужен абстрактный класс.

понятия абстрактного класса и метода нужны для уточнения семантики, что бы программист
1. видя описание понимал установленные в данной иерархии наследования правила
2. получил ошибку (времени компиляции, времени исполнения) в случае неправильного использования.

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

Добавлено через 6 минут и 21 секунду
имхо полезно поизучать в целом объектно-ориентированные и аспектно-ориентированные анализ и проектирование, т.к. конкретные языки обычно реализуют только отдельные аспекты, и каждый по-своему

Ну более менее стало понятно. Единственное - пока не понимаю необходимость применения этого в том или ином случае. Если брать к примеру CMS, то это достаточно большие проекты. Но изучая и анализируя их я понимаю что существует практически два разных подхода...



PS

самый бесполезный совет   Без обид, но что я сейчас делаю?   

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

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

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

Да, только абстрактный класс позволяет ещё архитектору задавать начальную функциональность и состояние, в отличии от самого Interface.

Как это да же в голову не пришло . Наглядный пример SPL

Это сообщение отредактировал(а) Sentox - 15.5.2012, 12:19

форум место обмена опытом и общения, но на университет не потянет. книжки надо.
если бы тема была создана в разделе философии программирования, а не конкретного языка, ответ возможно был бы другим 

это как совет маститого писателя начинающему: если можешь не писать, не пиши.
строгих правил нет, это надо прочувствовать, необходимость сама придет.
есть ООП методология, но она слишком объемна, что бы её здесь описывать. хотя сводится она к простому - объектно-ориентированной декомпозиции: сначала в задаче выделяются объекты и способы их взаимодействия, потом они обобщаются в классы, полученные классы снова обобщаются, и так пока будет нечего обобщать. если какие-то из полученных классов являются абстрактными типа птиц и самолетов, их следует сделать абстрактными. сильный признак абстрактного класса - наличие абстрактного (без реализации) виртуального метода.
так, в системе графических объектов базовый класс Shape является абстрактным, т.к. содержит метод draw() который можо реализовать только в конкретных подклассах.

для php есть такой пример: допустим нам требуется работа с деревьями, а именно - обход дерева в глубину. задача часто возникает при создании меню, при обработке иерархических данных в бд.
если полностью абстрагироваться от представления данных и конкретных решаемых задач, получим такой класс:

сам класс бесполезен, его обязательно нужно конкретизировать для конкретного представления (get_data, get_children) и конкретной задачи (node_begin,  node_end). при этом класс реализует обход дерева - walk_tree(), которую уже не нужно изменять

Это сообщение отредактировал(а) baldina - 15.5.2012, 14:52

ну в принципе всё понял и разобрался... По ходу изучения ещё и в интерфейсы залез..  На данном этапе пока нахожу для себя их реальное применение только в плагинах (расширениях) к проекту, например к той же CMS (ну или к какому-либо компоненту).

Вот именно для такого случая абстрактный класс будет подходить практически идеально.. 

baldina, ты прав, это само придёт.. и даже пришло 

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