Владимир Чернышев

Удобнее, безусловно, на каждый тип поля создать класс и инстанциировать при необходимости.

Удобнее, имхо, просто приводить SQL-типы в PHP-типы и обратно непосредственно при чтении/записи, если вы только в своём приложении не используете ООП обёртки для всех скалярных типов в PHP, типа if ($user->login.equal(new String($_POT['login']))

Любую задачу (решаемую в принципе) можно реализовать как с ООП, так и без него (в процедурном стиле, например). «Прелести» ООП лучше всего чувствуются на больших проектах, где невозможно держать в голове все (глобальные) переменные и функции и способы их взаимодействия и приходишь к пониманию необходимости использовать более высокие уровни абстракции, чем отдельные значения и классические массивы из них. Начинаешь объединять семантически связанные данные в структуры (ассоциативные массивы в 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(). Если же без ассоциативных массивов вы уже разработки не представляете, то вы уже почти достигли ОО-просветления :)

Кстати, не всегда это хорошая практика. Можно считать это преждевременной универсализацией и оопизацией во многих случаях, если вы точно не уверены, что понадобится несколько классов с разными реализациями, но одним интерфейсом (тестирование отдельный случай, во многом зависит от языка и инструментов, где-то мок/стаб легко создать без интерфейсов, где-то, наверное, невозможно). Вот когда понадобится, тогда и создадите, а достоверая оценка оценка вероятности понадобится или нет приходит только с опытом. Но лучше, имхо, для более быстрого его набирания лишний раз выделить интерфейс из уже реализованного класса, чем выделить сразу, а потом и не вспомнить, что зря его выделял и таскать по всему проекту без особой надобности. А когда интерфеейса не хватате, то это чувствуется, особенно в языках с сильной типизациейю.

Добавлю ещё symfony2 и Doctrine 2.