а так все просто. Когда ты переходишь от терминологии «данные» и «функция» к терминологии «некоторая сущность, которая отвечает за..» ты сделаешь 1/3 работы.
На примере. Допустим у нас на сайте везде есть доступ к какой-то информации (условно назовем тексты), ты можешь написать функции которые будут работать с этими текстами, а можешь сделать объект, который будет проводить работу с ними, назовем его условно class ContentManaget что это тебе дает?
во первых, ты получаешь что все функции по работе у тебя собраны в одном месте (это инкапсуляция)
class ContentManaget
public function getText($id)
public function getTextList()
во вторых ты можешь включить в свой класс функции, которые нужны для работы объекта (экземпляра класса)
class ContentManaget
public function getText($id){
return $this->preOut($this->loadText());
}
protected function loadText($id)
protected function preOut($txt)
public function getTextList()
таким образом ты лишил себя и других разработчиков пользоваться внутрненними служебными функциями своего объекта
но объект — это сущность а не только функции. Тоесть это не только обработка данных, это еще и сами данные. Теперь зная это просто сделать кеширование:
class ContentManaget
protected $cache=array()
public function getText($id){
if (!isset ($this->cache['id']))
$this->cache['id'] = $this->preOut($this->loadText());
return $this->cache['id']
}
protected function loadText($id)
protected function preOut($txt)
public function getTextList()
так ты можешь понять что такое инкапсуляция и зачем нужно ооп и где оно упрощает жизнь на пальцах.
Второе наследование: допустим у тебя есть критерий по которому твоим ContentManaget ром могут пользоваться админы и пользователи, пользователи тока читают, а админы допустим еще и пишут, как сделать эти разграничения? просто.
class EditorContentManaget extends ContentManaget
function add($title, $txt)
function delete($id)
function edit($id)
теперь собственно место выбора того или иного класса при создании экземпляра:
if (isAdmin())
$cm = new EditorContentManaget;
else
$cm = new ContentManaget;
это наследование. ну полиморфизм ты понял из статьи.
короче то что я сказал — это малая часть притом не верная, она нужна только чтоб заинтересовать, чтоб понять как нада нужно читать хорошие книги, список тебе тут накидают в коменты
но вы правы потолок настает в N раз быстрее, где N — среднее число параметров у сущности, но если у вас не милионы таких сущностей, а сотни тысяч, то можно не париться
вот о сравнении не скажу, потому что мне нужно было именно это решение, потому как я плохо заранее представлял хранимые сущности, а не из за выигрыша в скорости. Но думаю что если вы заранее знаете поля, которые используются в поиске, то на широкой таблице и суммарном индексе можно получить существенный выигрыш, но я не знал ни популярных полей для поиска, ни собственно изначально полного их списка.
тесты конечно скриптами внешними. Ну как я описал генератор SQL был, но время генерации SQL ничтожно. 0.2 сек это при обширных запросах, когда в реззультате слишком много записей получается + какой-нибудь group by.
если же у вас ограничения по поиску выделяют всего 1/100 или даже 1/20 таблицы, то все летает ибо используется праймари индекс
На МуSQL я тестировал на таблице в 200 000 сущностей, по 40 параметров у каждой случайным образом заданных. поиск по любой комбинации параметров производится в пределах 0.0001-0.2 сек
На примере. Допустим у нас на сайте везде есть доступ к какой-то информации (условно назовем тексты), ты можешь написать функции которые будут работать с этими текстами, а можешь сделать объект, который будет проводить работу с ними, назовем его условно class ContentManaget что это тебе дает?
во первых, ты получаешь что все функции по работе у тебя собраны в одном месте (это инкапсуляция)
class ContentManaget
public function getText($id)
public function getTextList()
во вторых ты можешь включить в свой класс функции, которые нужны для работы объекта (экземпляра класса)
class ContentManaget
public function getText($id){
return $this->preOut($this->loadText());
}
protected function loadText($id)
protected function preOut($txt)
public function getTextList()
таким образом ты лишил себя и других разработчиков пользоваться внутрненними служебными функциями своего объекта
но объект — это сущность а не только функции. Тоесть это не только обработка данных, это еще и сами данные. Теперь зная это просто сделать кеширование:
class ContentManaget
protected $cache=array()
public function getText($id){
if (!isset ($this->cache['id']))
$this->cache['id'] = $this->preOut($this->loadText());
return $this->cache['id']
}
protected function loadText($id)
protected function preOut($txt)
public function getTextList()
так ты можешь понять что такое инкапсуляция и зачем нужно ооп и где оно упрощает жизнь на пальцах.
Второе наследование: допустим у тебя есть критерий по которому твоим ContentManaget ром могут пользоваться админы и пользователи, пользователи тока читают, а админы допустим еще и пишут, как сделать эти разграничения? просто.
class EditorContentManaget extends ContentManaget
function add($title, $txt)
function delete($id)
function edit($id)
теперь собственно место выбора того или иного класса при создании экземпляра:
if (isAdmin())
$cm = new EditorContentManaget;
else
$cm = new ContentManaget;
это наследование. ну полиморфизм ты понял из статьи.
короче то что я сказал — это малая часть притом не верная, она нужна только чтоб заинтересовать, чтоб понять как нада нужно читать хорошие книги, список тебе тут накидают в коменты
habrahabr.ru/blogs/php/39739/
Entity-Attribute-Value, Сущность-атрибут-значение (EAV)
если же у вас ограничения по поиску выделяют всего 1/100 или даже 1/20 таблицы, то все летает ибо используется праймари индекс