Приведу пример, с которым сегодня столкнулся. Я писал на основе фреймворка Yii небольшой аналитический модуль, которому на вход подаются одни данные, он их анализирует, и выдает другие. Все было хорошо, когда анализировать нужно было только одного типа данные, Я просто все в одном контроллере написал, и оно отлично работало.
Сегодня шеф сказал, что нужно к этой аналитике прикрутить возможность анализировать данные, для которых входящий набор параметров будет отличаться, т.к. анализировать данные нужно из другого региона.
Решается это весьма просто. Создается класс Analyzer, либо интерфейс IAnalyzer, от которого унаследуем класс MyAnalyzer, в котором реализуем логику анализа первого набора данных, и RegionAnalyzer, в котором реализуем логику анализа второго набора данных. Контроллер соответственно, чистится от мусора, бизнес-логика выносится в отдельные бизнес-единицы - классы MyAnalyzer, RegionAnalyzer. Таким образом, контроллеру нужно теперь просто сказать, какой анализатор вызывать, и контроллер вызовет его, передав входящий набор данных. Этим самым у нас получилась в каком то роде модульность, думаю, это можно назвать инкапсуляцией данных, т.к. мы скрыли всю логику аналитики). Теперь другому разработчику достаточно реализовать какой-нибудь третий класс, и не вникать в логику контроллера, чтобы этот его класс работал так-же, как и первые два.
А для манипуляции данными, ООП тоже удобно очень тоже.
Например, у нас есть класс стол (Table), у него есть набор параметров - длина, высота. Если бы вы использовали массивы, оно бы у вас было описано примерно так:
$table = array(
'width' => 10,
'height' => 10,
'length' => 10,
);
Теперь вам нужно сделать складной стол. Вам приходится копировать представленный выше массив, и добавлять в него новые параметры и методы:
$foldingTable = array(
'width' => 10,
'height' => 10,
'length' => 10,
'widthFold' => 5,
'heightFold' => 5,
'lengthFold' => 5,
);
т.е., вы напоролись на первые грабли - избыточность данных. Да, это не всегда плохо, но в данном случае это действительно плохо.
Кроме того, до появления замыканий нельзя было элегантно было использовать анонимные функции в качестве значений ключей в ассоциативных массивах.
Теперь представьте, вам необходимо создать 5 экземпляров столов. Да, используя массивы это решается обычным присваиванием:
$tables = array();
for($i=0; $i<5; $i++)
{
$tables[] = $table;
}
Ясно и просто, но не очень красиво. Давайте теперь добавим метод складывания стола в массив:
$foldingTable = array(
'width' => 10,
'height' => 10,
'length' => 10,
'widthFold' => 5,
'heightFold' => 5,
'lengthFold' => 5,
'isFold' => false,
'fold' => function($table){/* some logic here */},
);
Вызовим его теперь:
$foldingTable['fold']($foldingTable );
некрасиво как-то. А еще мы не можем указать явно, какой аргумент передается в функцию. Можно использовать array, но в таком случае будут пропущены в обработку все структуры, являющиеся массивами. Нет контроля типов данных.
Давайте теперь сделаем все это, используя ООП:
class Table{
public $width = 10;
public $height = 10;
public $length = 10;
}
Создаем складной стол:
class FoldingTable extends Table{
public $widthFold = 5;
public $heightFold = 5;
public $lengthFold = 5;
public $isFold = false;
public function fold()
{
if($this->isFold) return false;
$this->fold = true;
return true;
}
}
Теперь сложим стол:
$table = new FoldingTable();
$table->fold();
По сравнению с массивами очень симпатично получилось и вполне читаемо. Мы теперь можем создавать столько столов, сколько нам потребуется, поскольку метод fold является методом класса, нам не нужно в нем контроллировать входящие данные, потому что этот метод гарантированно вызывается из объекта $table типа FoldingTable
Таким образом, можно вполне просто инкапсулировать в объектах доступ К БД. Например, хранить состояние переменной $isFold в БД, а в методе $fold делать запрос к БД, и по результатам запроса уже производить, или не производить какие-то манипуляции.
Вообще, ООП - весьма обширная тема, которую одним постом и не объяснить. Главное, постарайтесь понять принцип, и в дальнейшем вы автоматически будете принимать решение, где использовать объекты, а где нет.
Простите за сумбурность.