[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Процедурный стиль vs Объектно ориентированное прог
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
Arh
twin
Цитата
Вот это ближе. Потому что один объект взаимодействует с другим. Это понятно. Не понятно другое. Если объекты не взаимодействуют друг с другом напрямую, а последовательно выполняют какие то вычисления, требуемые в контексте основной программы, это считается объектной ориентацией?

Если они не будут друг с другом взаимодействовать, тогда получается контроллер сам составит SQL запрос в базу, получит массив с новостями и как то их выведет. Ему не нужен News.
А в другом контроллере нужно составлять другой запрос.
Получается что ответственность за составления запроса (знать имя таблицы и всё такое) берут на себя уже два контроллера, нет единой ответственности.

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
Arh
Как то так наверное.

Контроллер ООП

return (new News($DB))->top();


Контроллер Проведурки
return $DB->query('SELECT ... ORDER BY `rating`')->fetchArray();


_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
twin
Вот что я надумал. :)

Использовать классы и объекты в процедурном программировании можно и должно. И это ни коем образом не нарушает концепци парадигмы. Объясю почему.

Нужно просто обратиться к истории. Когда по земле бродили диназавры еще ни сном ни духом не знали об ООП, разработчики ПО попытались улучшить дискретность программ путем объединения данных и процедур в одном отдельном блоке. Первым языком, реализовавшим эту идею, была Симула. Именно для неё и были придуманы понятия "класс" и "объект". Уже тогда эти классы поддерживали как инкапсуляцию, так и механизм наследования. Но Симула не была объектно-ориентированной, так как исполнение программы происходило как и раньше, последовательно, сверху вниз. Другими словами это та же банальная процедурка, только с использованием классов.

Концепцию ООП впервые предложил Алан Кей в своем языке SmallTalk, спустя почти 10 лет после того, как были изобретены классы и объекты. И заключалась она в том, чтобы разделить вычисления, заменив последовательно выполняющиеся инструкции на "параллельную" среду общения классов. Именно он ввел понятие "Объекто-ориентированное программирование".

Его концепция заключалась в том, чтобы не использовать результат выполнения инструкций класса немедленно, а иметь возможность "заморозить", отложить его на потом. Этим дстигается некоторая "многомерность" вычислений.

chee прав, отличие парадигм в использовании состояний объектов. Если объект призван хранить состояние (замораживать данные для использования в других частях программы), то это признак ООП. Если результат требуется немедленно, и только тут, это процедурное программирование. На примере. Вот ООП
    $obj1 = new Example1;
$obj2 = new Example2;
$obj3 = new Example3;

$data = $obj3->getData();
$obj2->setSomeData($data); // Заморозили состояние
$data = $obj1->getData();
$obj2->setOtherData($data); // изменили и опять заморозили
// тут куча кода

$total = $obj2->getTotal(); // Получаем результат в другой части программы.

А вот это как хотите называйте, но это полностью отвечает принципам процедурной парадигмы:
    $obj1 = new Example1;
$data = $obj1->getData();

$obj2 = new Example2;
$result = $obj2->someMethod($data);

$obj3 = new Example3;
$total = $obj3->getTotal($result);
Какими бы не были классы, содержащими свойства или просто набор процедур - не суть. Важно, что основная программа выполняется последовательно, состояния классов не важны, важен сиюминутный результат.

Так что отбирать у процедурщиков классы, это тоже самое, что отбирать у бабушки пенсию))). Приходит такой "благодарный" сынок-верзила и говорит. Тебе деньги не нужны. Кочумай на картохе. Деньги мне нужны. Для развития. :) И глубоко плевать, что это ты их заработала многолетним трудом.

И тут вот еще какой парадокс есть. В процедурке как раз удобнее и логичнее использовать именно объекты, нежели статическе классы. Так как статические классы хранят состояния априори. А объект можно каждый раз создавать чистый. Но это другая песня уже.

Так что вывод прост. Вернее их два.
1. Процедурное программирование, это не код в одну строку, в одном файле, в одной области видимости. А значит при умелом использовании ничего общего с говнокодом не имеет.
2. Далеко не все понимают, а значит правильно используют концепцию ООП. Но пару раз написав класс и создав объект, уже смело причисляют себя к тру-ООП программистам. Так что сей опрос не показателен.

Вернее наоборот. Он как раз и доказывает то, что ООП черезчур сильно распиарено. Хотя четкого и однозначного определения ему на сегодняшний день нет, все стараются "приобщиться". Со времен определения концепции Алана Кея прошло много лет, многое изменилось. Сейчас сложно опираться на его основополагающие принципы. А новых никто не сформулировал.
Вот парень классно описал проблему. Я уже приводил этот пример как то раньше.

И складывается такое ощущение, что ООП, раз не имеет четких границ, это большой, красивый, разрекламированный, но все же мыльный пузырь.

Нельзя использовать только одну парадигму, если хочешь писать красиво. По сути это невозможно. В ООП так или иначе нарушишь концепцию, так как нет её четкого определения. По этому ответ "Только ООП" не корректен. И все, кто поставили на нем галочку либо не понимают предмета, либо врут сами себе, либо сами себя загнали в золотую клетку из наспех придуманных правил и ограничений.

А те, кто поставил галочку "только процедуры", еще просто не доросли до мультипарадигмы. И даже если используют в коде классы и объекты, то неэффективно. Не полностью используют возможности языка (PHP имею ввду естественно).

И главное - в опросе нет самого правильного ответа. "Использую мультипарадигму". Куда и должен был поставить галочку честный перед собой программист. :)



_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.