EGOP

У разных языков по разному. Например в Java можно реализовывать кучу интерфейсов, но нельзя реализовать множественное наследование не больше 3-ех наследников и с помощью интерфейсов решают это.

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

Абстрактный класс нужен, когда нужно семейство классов, у которых есть много общего. Конечно, можно применить и интерфейс, но тогда нужно будет писать много идентичного кода.

Пример: Абстрактный класс заведомо не будет запрошен как объект. К примеру абстрактный класс - Транспорт: Но все его наследники будут Автомобилем, краном, лодкой, самолет и т.д. Например вы заведомо знаете, что весь транспорт будет двигаться. И вы объявляете абстрактный метод(движение) в абстрактном классе, который нужен будет 100% всем наследникам т.е. без движения это уже не транспорт и новый наследник обязан будет реализовать это. В самом же абстрактном классе, есть другие поля и свойства, которые будут унаследованы. Ну например мощность двигателя(очень грубо), или то что их роднит.

Никогда, вы слышите, никогда не используйте регулярные выражения для того, чтобы распарсить HTML

Используйте соответствующие инструменты, например:
- https://github.com/Imangazaliev/DiDOM
- https://github.com/paquettg/php-html-parser
- simplehtmldom.sourceforge.net

Простите, не удержался :)
stackoverflow.com/questions/1732348/regex-match-op...

парсить HTML регурярками себе дороже. Лучше использовать xpath.

Если у Вас есть проблема, и вы хотите решить ее с помощью регулярных выражений - значит у Вас две проблемы (с).

1) #<li>(?P<mask>.*)</li>#
2) /src= "(?P<mask>.*)"/    обратите внимание - в файле пробел между = и "
3) а курсовую за Вас не написать?

Любую задачу (решаемую в принципе) можно реализовать как с ООП, так и без него (в процедурном стиле, например). «Прелести» ООП лучше всего чувствуются на больших проектах, где невозможно держать в голове все (глобальные) переменные и функции и способы их взаимодействия и приходишь к пониманию необходимости использовать более высокие уровни абстракции, чем отдельные значения и классические массивы из них. Начинаешь объединять семантически связанные данные в структуры (ассоциативные массивы в PHP), а функциям с ними работающим давать имена с префиксом (обычно) в виде названия (чисто семантическое) этих структур, чтобы хоть немного упорядочить глобальное пространство имён, получая функции вида user_login(array $user, $login, $password), user_logout(array $user) и user_is_logged(array $user). До простейшего ООП осталось сделать один шаг — перенести и функции (указатели на них в С, callback/имена в PHP) в эти структуры, но синтаксис вида call_user_func($user['user_login'], $user, $login, $password) мягко говоря неудобен и избыточен и тут в PHP4 вводят вместо него синтаксис $user->login($login, $password) и без него ты больше не можешь жить :)

Если же до семантических концепций ООП не дойти на своей шкуре, то разницы между user_login(array $user, $login, $password) и $user->login($login, $password) почти нет, но даже на таком простом примере видно, что запись банально короче и глобальное пространство имён меньше используется, что особенно заметно при использовании IDE с автодополнением.

Но это философское отступление было о некоторых прелестях ООП. Прямой ответ на вопрос «какую задачу?» — любую интересную хотя бы чуть-чуть. Желательно с развитой предметной областью, в которой ощущается интуитивно наличие нескольких абстракций разного уровня. Если для процедурного приложения вы создаёте несколько таблиц в БД или используете ассоциативные массивы для группировки семантически близких значений — то это, скорее всего, такая задача. Для большего wow-эффекта или просветления можно попробовать написать две версии одного приложения типа блога, одну в процедурном стиле, другую в ООП. Причём в первой желательно не использовать «промежуточные» решения типа ассоциативных массивов даже для mysql_fetch_assoc/array(), только бескомпромиссное mysql_fetch_row(). Если же без ассоциативных массивов вы уже разработки не представляете, то вы уже почти достигли ОО-просветления :)