Мне кажется это больше попытка использовать множественное наследование, то есть:
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, ты прав, это само придёт.. и даже пришло 

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