Всем нужно ООП, все пишут на ООП, а я вот задумался - а в чем собственно преимущества объектов? Вроде бы говорят, что это удобно. Но на текущем уровне, и в текущих домашних поделках (только на домашних поделках можно экспериментировать - на работе приходится "работать в тренде") мой опыт показал, что с фулл статикой мне работать в разы удобнее. Второй довод - защищенность кода. Казалось бы да... но практика показывает, что: 1. При желании можно сломать любой код 2. То, что код "защищенный" не значит, что приложение нормально работает. Я наблюдал забавную ситуацию, когда один крупный проект начал падать от того, что слишком много пользователей начали обращаться на несуществующие запросы, а проект спроектирован так, что ему нужно выполнить кучу логики, чтобы показать ошибку 404. А вот чем хуже - быстродействием. Ради интереса посчитал, во сколько арифметические операции с объектами: PHP: <?php class Number { private $number; public function setNumber($value) { $this->number = $value; } public function getNubmer() { return $this->number; } } class Arithmetic { public function sum($a, $b) { return $a + $b; } } $a = microtime(true); $i = 0; while ($i < 1000000) { $nubmerOne = new Number(); $nubmerOne->setNumber(25); $numberTwo = new Number(); $numberTwo->setNumber(10); $arithmetic = new Arithmetic(); $arithmetic->sum($nubmerOne->getNubmer(), $numberTwo->getNubmer()); $i++; } $b = microtime(true); $o = $b - $a; echo '<p>Арифметические операции объектами: '.$o.'</p>'; $h = microtime(true); $i = 0; while ($i < 1000000) { $a = 25; $b = 10; $c = $a + $b; $i++; } $j = microtime(true); $p = $j - $h; echo '<p>Арифметические операции без объектов: '.$p.'<br />'; echo '<p>Арифметические операции без объектов выполняется в '.($o/$p).' раз быстрее.</p>'; Скрипт выдает, что операции без объектов выполняются в среднем в 25 раз быстрее. Конечно, раз ООП стало в вебе стандартом - в чем-то оно лучше. Но, чем, мне откровенно непонятно.
Для чистоты эксперимента надо было, как минимум, простое сложение также делать через функцию... Вы же, по сути, хотите сопоставить процедурное и ОО программирование. Естественно лапша будет работать всегда быстрее.... Но вот работать с ней.....
только в том случае если там лапши на 100-200 строчек кода если лапша начинает повторять сама себя, нарастающий функционал лапши будет излишни великим, где на ооп придётся написать всего лишь единожды описать режим работы и потом заниматься созданием просто экземпляра объекта... То я бы поспорил о быстроте функционала.
В любом случае, конечно же и функциональное здесь будет быстрее. Т.к. вы выполняете больше операций в цикле. Тут больше вопрос в удобстве работы с кодом. Точно так же, например, и принцип MVC замедляет работу кода.
а ты попробуй поставь себе задачу, опиши колесо машины. И создай его 4 экземпляра. Ведь на каждую машину приходится по 4 колеса. А потом опиши тоже самое на функциях. И посмотри разницу удобства. Но если ты не шаришь в ООП, то ты будешь ООП лепить как процедурку и естественно тебе покажется что процедурка будет лучше.
А тут и спорить не чего. Тут просто надо понимать как это работает. В лапше нет накладных расходов на, утрировано, создание в памяти области для работы функций и методов, нет накладных расходов для создание экзмпляра класса. Тупо идет последовательная обработка кода с минимумом джампов.
Помнишь недавно в скайпе писал "у меня беда с ооп, как собака - понимать поинмаю с сам сделать сложно" короче, с горем пополам сделал класс и объектами его объектами!!!! показал работу старшему программисту, он говорит "что тут наворотил? какие объекты ))) и все переделал процедурным стилем, мало того что код стал в три раза короче, так и быстрей в два раза... Видимо главное преимущество ООП это гибкость
вы просто не умеете его готовить. --- Добавлено --- ну тут я чутка не так написал. (За что извеняюсь, написал масло масленное). Я имел ввиду излишество кода будет.
Ну, а как не замедляет? Она добаляет дополнительные сущности в код, которые нужны лишь разработчику. Утрировано ты в одном случае видишь GET запрос. Сразу заправшиваешь 100 строк в БД, и в том же цикле их выводишь на страницу. В MVC роутер решает кому отдать запрос, идет инклуд, далее все 100 строк получаются из базы, потом отдается в отображение, где еще один цикл выводит их на страницу
только вот роутер и добавляет. Но роутер, работает быстренько. Вон я пользуюсь слимом, да там прилично кода, но работает он очень быстро. Разница на глаз абсолютно не заметна даже при больших нагрузках. --- Добавлено --- согалсен
Модель получила 100 строк и занесла их в массив. Вернула контролеру. Контроллер передал массив в представление. Где в цикле (второй цикл по тем же данным) осуществляется вывод
не у всех всё так работает. Как я и писал MVC это идеология Я работаю с ед. точкой входа, где я маршрутизирую ссылку соглассно определённому контроллеру где я уже сам решаю какую модель мне подключить и нужно ли её подключить, а может я прямо из контроллера, всё сделаю и отправлю во view, зачем нагружать излишним дёрганьем классов каких либо. --- Добавлено --- Всё зависит от сложности задачи обработчика. Если задача тривиальная проверить юзера... То нахрен мне вообще лезть в модель, я в контроллере опишу логику работа там 5 строчек всего и верну, результат обратно allow или disallow и всё. --- Добавлено --- вот пример: Контроллер просто влезает в расстояние между моим большим и указательным пальцем. Всё зачем мне создавать под это ещё модель. PHP: public function authLogin(Request $request, Response $response) { $result = []; $tokenName = $request->getAttribute($this->nameKey); $tokenValue = $request->getAttribute($this->valueKey); $csrf = $this->arrayCsrf($tokenName, $tokenValue); // Get Post Request; $post_data = $request->getParsedBody(); // Users verify // create @var $error $error = false; $user = Users::getUserByEmail($post_data['login_email']); if ($user === Null) { $error = true; } else { if (password_verify($post_data['password_login'], $user['password'])) { $_SESSION['user_id'] = $user['id']; $result['success'] = true; } else { $error = true; } } // check @var $error if($error === true) { $result['error'] = ['login' => false]; $result['csrf'] = $csrf; } // end check // return Response $newResponse = $response->withJson($result); return $newResponse; }
Вообще, кстати, в свое время, когда я уже во всю программировал с использованием ООП. Мне в поезде в руки досталась книга C++ для чайников.... В ней была часть объясняющая работу ООП и как то так было все тупо и просто расписано, что у меня кое что даже по полочкам более правильно разложилось (до этого, если утрировать, относился к ООП "ну так надо").... Объяснений не помню, но может в интрнете найдете почитайте (хотя там уж редакций много наверное сменилось) --- Добавлено --- Т.е. контроллер лезет на прямую в бд?
Да если бы задача стояла не только в проверке юзера, но и в написании после этого какого то результата, то я скорее всего вынес бы всю эту хрень в отдельный статический класс, с запоминанием что узер проверен, или нет. И писал бы логику дальше --- Добавлено --- не совсем для этого существуют библиотеки для работы с бд, у меян даже модель не работает напрямую с бд, для этого есть библиотеки получения данных, у меня не сколько другое понимание mvc, но оно работает изумительно. И мне очень удобно.
Контроллер работающий с данными это уже нарушение MVC. Для командной работы над проектом это уже грубая ошибка, --- Добавлено --- Пользователь (мыло, пароли и т.п.) это же тоже данные.
но иногда бывает и так, тока через query builder пример: PHP: public function getCommentByVendorCode (facadeRouter $router) { $post = $router->getPost(); if (empty($post['vendor_code'])) { return $router->withJson(['type' => 'error']); } $vendor_code = (int)$post['vendor_code']; $res = Query::connect('my_comment')->where(['vendor_code' => $vendor_code])->order('id DESC')->getAll(); if (empty($res)) { return $router->withJson(['type' => 'error', 'text' => 'Нет комментариев. Будьте первым кто их оставит!']); } return $router->withJson(['type' => 'allow', 'comments' => $res]); } --- Добавлено --- @voral вот и скажи мне что мне тут в модель выносить
Конечно, хреначить все в одну простыню удобно(удобно не переключая вкладки кодить), но это не то, что должен делать программист.
Вот в приведенном вами коде. Вы в контроллере проверяете пароль при помощи определенного алгоритма, придет другой разработчик и прочитав что у вас MVC по какимто объективным причинам изменит логику шифроания пароля там где он сохраняется.. И все... Трындец вашему проекту. --- Добавлено --- @askanim, PHP: $res = Query::connect('my_comment')->where(['vendor_code' => $vendor_code])->order('id DESC')->getAll(); Т.к. если вам потребуется в дальгнейшем обработка данных полученных в БД выысделаете ее в одном месте.. Если делать как вы - придется искать везде... Это у вас точно НЕ MVC --- Добавлено --- Подход MVC четок в этом отношении.. .Тут не должно быть "да тут не зачем разделять", просто разделяете и все. Точка. Просто вы либо реализуете MVC либо нет. Т.е. если я возьмус за ваш код, зная что он MVC я должен быть уверен, что не должен собирать везде запрос списка комментариев.
@voral вот и скажи мне что мне тут в модель выносить то есть вы хотите сказать что строчку кода нужно размножить на ориентировачно 10-15 строчек создавая отдельный класс с проверкой на поступления переменной в метод, передавая его потом в query builder и проверкой на пустоту возрврата данных и вернуть либо false либо массив данных... Не хило. нет просто вы не понимаете что такое MVC --- Добавлено --- Подход MVC это капля в море. Каждый понимает по своему. --- Добавлено --- ну значит разраб индус! Раз он будет менять шифрование пароля. --- Добавлено --- Потому что каждый норм пыхер знает что надо использовать DEFAULT от пыха. Ибо оно может взять и измениться (Например шифрование возьмёт и станет бесполезным). А по дефолту стоит то что нужно, и при обновлении его в пыхе соответственно код изменений не понесёт. ИМХО моё мнение: Программист должен писать код чисто и оптимально. Если он это делает, другой прогер тоже сядет и разберётся в нём. А если сидеть и работать красота ради красоты, это волк в овечьей шкуре, значит чувак не понимает что он делает. --- Добавлено --- как и с ООП, когда ты услышал тут фразу теперь её понимаю: Писать ООП ради ООП не надо.