Правила     Закладки     Карма    Календарь    Журналы    Помощь    Поиск    PDA    Чат   
        СМС-ки
   
Пейджер выключен!
Страницы: (13) « Первая ... 7 8 [9] 10 11 ... Последняя » ( Перейти к первому непрочитанному сообщению )  
Фильтр авторов:    показать 
  скрыть
  Закрытая темаСоздание новой темыСоздание опроса

> Процедурный стиль vs Объектно ориентированное прог
 
Опрос: Какой стиль програмирования вы используетете
Только Процедурный [ 5 ]  [19,23%]
Только ООП [ 14 ]  [53,85%]
ООП когда требует клиент, так процелурный [ 0 ]  [0,00%]
претваряюсь что пишу ООП (создаю классы, методы), а использую процедурный [ 3 ]  [11,54%]
ООП когда большой проект, а сам использую процедурный [ 4 ]  [15,38%]
Всего голосов: 26
  
twin  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15559
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 1 день
Карма: 299

Трезвый :
5 лет, 11 месяцев, 10 дней


Цитата (redreem @ 27.01.2016 - 15:24)
неужели участие в этих бреднях вам доставляет удовольствие?  это ж демагогия и софистика в одном флаконе

Форум вообще то площадка для общения в первую очередь. Если есть дебаты, значит кому то они нравятся)

Кому нет - нафиг с пляжа. Есть куча тем, где можно потешить ЧСВ, отвечая на вопросы новичков. smile.gif


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

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

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Arh  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



146%
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 2102
Пользователь №: 27172
На форуме: 5 лет, 8 месяцев, 2 дня
Карма: 70




Наверное надо говорить не про сущности, а про ответственность.
То есть в ООП мы делаем какой то класс например ответственным за работу с новостями, которые лежат в базе данных.
Что бы классу News получить новости из базы, он использует другой класс, который ответственный за работу с базой данных (PDO).
У одного контроллера ответственность выдать топ новостей, для этого ему нужен News, который ответственный за работу с новостями.
У другого ответственность выдать последние новости, для этого ему нужен News, который ответственный за работу с новостями, которому нужно PDO, которое ответственно за работу с базой данных, где лежат новости.

А в процедурке тогда наверное всё безответственно =)
Есть только контроллер, который сам отвечает за запрос новостей из базы, их формирование и вывод.
То есть запуская контроллер, мы запускаем процедуру получения новостей.
Запуская другой, запускаем другую процедуру опять от и до.


--------------------
:)
PMСайт пользователя
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Gram  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Абориген
*****

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 246
Пользователь №: 18471
На форуме: 7 лет, 4 месяца, 10 дней
Карма: 1




Летающий макаронный монстр действительно существует, но не потому что есть такой термин. Его в любом случае описывает некоторый алгоритм. Если станет задача реализовать этого летающего макаронного монстра, самый популярный ответ будет а какой бюджет? Как можно утверждать что его не существует, заплати и будет тебе монстр, летающий, макаронный.

Всегда был на стороне функционального/процедурного программирования, и против фреймворков, только у меня аргументы другие. Я за свободу действий. За алгоритмы, а не за стили или способы написания кода. За безграничность мысли. За идею попробовать что-то новое. Рефакторинг кода всегда можно сделать, ввести рамки, запреты и ограничения, абстракции, вообще язык сменить или новый написать. Инженер создавая что-то располагает информацией о том что есть зарекомендовавшие себя узлы, которые можно использовать, но его это НЕ загоняет в рамки. Если изделие требует разработки новых модулей - будут разрабатываться новые модули. Мы же не в мире лего живем, где все виды деталек уже есть, осталось добыть инструкцию. Фреймворки и есть что-то похожее на запчасти лего. Готовый конструктор, бери и собирай, вот тебе 200 образцов что может получиться. А фантазия и отсутствие рамок делают программиста лучше, мозг качают. Вот именно прокачку мозга я и советую, думать своей головой, а не взять готовый фвеймворк, который сказали "Лучшее решение 2015 гг", и считать что ты самый передовой чувак. А как же эволюция? Кто будет толкать прогресс дальше? Нельзя же утверждать что это пик развития IT.
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15559
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 1 день
Карма: 299

Трезвый :
5 лет, 11 месяцев, 10 дней


Цитата (Arh @ 27.01.2016 - 16:39)
Наверное надо говорить не про сущности, а про ответственность.

А почему ты считаешь, что на процедуру (подпрограмму) нельзя возложить ответственность? Не, не то. Не этим определяется ООП код.

Цитата (Arh @ 27.01.2016 - 16:39)
Что бы классу News получить новости из базы, он использует другой класс, который ответственный за работу с базой данных (PDO).
Вот это ближе. Потому что один объект взаимодействует с другим. Это понятно. Не понятно другое. Если объекты не взаимодействуют друг с другом напрямую, а последовательно выполняют какие то вычисления, требуемые в контексте основной программы, это считается объектной ориентацией?

Цитата (Gram @ 27.01.2016 - 17:55)
Летающий макаронный монстр действительно существует, но не потому что есть такой термин. Его в любом случае описывает некоторый алгоритм.
Это понятно. Само собой, можно сочинить любую программу, монстров полно в играх. Пусть не макаронных, но тоже не имеющих отношения к реалиям.

Я по другому думал. Что ООП накладывает некоторые обязательства при использовании объектов. Оказывается нет. Не совсем понятно тогда, где те рамки, которые призваны дисциплинировать программиста... Но это другая история. Это уже из области best practics. Отдельная тема, тоже к ООП не имеющая особого отношения.

А что касается
Цитата (Gram @ 27.01.2016 - 17:55)
Я за свободу действий. За алгоритмы, а не за стили или способы написания кода. За безграничность мысли. За идею попробовать что-то новое.
тут я на твоей стороне. Потому и практикую мультипарадигму. Собственно мне нет разницы, где границы между парадигмами, но для расширения кругозора и прокачки скилов любопытно выяснить.

Иначе так можно всю жизнь прожить и не узнать, как писька по настоящему называется. smile.gif


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

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

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
YVSIK  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



★___★mvccmv.ru★___★
******

Профиль
Журнал
Группа: Форумчанин
Завсегдатай форума
Сообщений: 3935
Пользователь №: 25563
На форуме: 5 лет, 11 месяцев, 5 дней
Карма: 63

Трезвый :
45 лет, 9 месяцев, 3 дня


Цитата (twin @ 27.01.2016 - 22:32)
Я за свободу действий. За алгоритмы, а не за стили или способы написания кода.

ну не могу я промолчать так))
свобода))))
мысли))
эко!,!, это не совсем верно.
однажды мне работае ночным понтилой-таксистом, один пассажир выдал
все что не запрещено----РАЗРЕШЕНО,
и я попал в ступор (запомнилось, и долго над этим мусирова в голове)
как же так, оказывается все остальное РАЗРЕШЕНО, но позвольте, а как все остальные, если они начнут творить, ЧиТО ИМ не запрещено?
однако и каша выйдет,
Каждый творец будет насождать или не насождать, что выйдет , каков будет результат?
по моему ИМХО будет не совсем тот продукт, который устроит большинство. желающих получить этот продукт.
а МЫ или вы создатели не для себя, мы или вы создаете для людей, чтоб им было проще жить,
и проще использовать, а тут такой поток продуктов, и каждый индивидум? blink.gif

а нахрена мне такая каша продуктов? они очень для меня неудобные, и разобрать что и как каждый работает, будет разобрать трудно, после десятого продукта, все превратятся в головную боль, останется одно желание, снести на помойку эти продукты хором, и таких творцов вместе туда-же,


любой продукт программирования имеет рамки дозволенного. не иначе, он имеет свои возможности,
нельзя заставить петь, ну скажем слона петь соловьем.
стремиться, сколько угодно, пожалуйста, а вот петь, кто будет слушать этого слона,
это будет неприятное, громкое, промозглое вытьё , достаточно представить эту музыку huh.gif

любой продукт строиться по правилам , необходимым для использования и удобства, общества, каждого человека

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

и программирование имеет рамки Возможного. Только то на что оно настроено,
посему ИМХО, где-то тут есть ошибочка


--------------------
«Гнусное свойство карликовых умов приписывать
________________!свое духовное убожество другим!»
___
О) как-же он прав=>__________________ © Оноре де Бальзак.

отличный хост(рекомендую !! )
My MVC-CMV
PMПисьмо на e-mail пользователюСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Arh  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



146%
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 2102
Пользователь №: 27172
На форуме: 5 лет, 8 месяцев, 2 дня
Карма: 70




twin
Цитата
Вот это ближе. Потому что один объект взаимодействует с другим. Это понятно. Не понятно другое. Если объекты не взаимодействуют друг с другом напрямую, а последовательно выполняют какие то вычисления, требуемые в контексте основной программы, это считается объектной ориентацией?

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


--------------------
:)
PMСайт пользователя
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Arh  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



146%
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 2102
Пользователь №: 27172
На форуме: 5 лет, 8 месяцев, 2 дня
Карма: 70




Как то так наверное.

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

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


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


--------------------
:)
PMСайт пользователя
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
[x] Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15559
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 1 день
Карма: 299

Трезвый :
5 лет, 11 месяцев, 10 дней


Вот что я надумал. :)

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

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

Концепцию ООП впервые предложил Алан Кей в своем языке 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
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
bestxp  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



орангутанг
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 2004
Пользователь №: 36605
На форуме: 3 года, 9 месяцев, 16 дней
Карма: 111




Twin только комменты еще почитай, статья там кривоватая - смотри те же комменты


--------------------
PMПисьмо на e-mail пользователюСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15559
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 1 день
Карма: 299

Трезвый :
5 лет, 11 месяцев, 10 дней


Цитата (bestxp @ 28.01.2016 - 05:00)
Twin только комменты еще почитай, статья там кривоватая - смотри те же комменты

Я естественно читал. Но там нет четкого определения ООП. Кто во что горазд. Это сродни фреймворку (хотя лочично, что одно вытекает из другого). Какую программист (или команда) выберут концепцию, ту и будут называть tru-ООП. Кто-то наследование не приемлит, кто-то публичные свойства, кто-то не представляет ООП без dependency injection, кто в лес, кто по дрова.

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

Вот автор в комментах написал, я с ним полностью согласен
Цитата
Так, например, до сих пор нет чёткого определения того, что такое ООП. Сколько книг я читал, со сколькими людьми говорил, но никто не может дать точное определение этой парадигмы.


У Кея были четкие определения, но современное ООП не совсем им отвечает. Не так сейчас строятся взаимодействия объектов. А новых постулатов как небыло, так и нет.

Объединяющий и эксклюзивный признак ООП я пока только один нашел. Многомерность вычислений путем сохранения состояния объектов. Остальное либо не является прерогативой, либо используется выборочно (не являясь обязательным условием).

Что-то еще есть?


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

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

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
chee  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Сын полка
Сообщений: 1780
Пользователь №: 38654
На форуме: 2 года, 11 месяцев, 1 день
Карма: 40




Короче, ответ на пример twinа

Оба случая будут объектно-ориентированы, но с точки зрения клиентского кода. То есть, мы же видим интерфейс объекта(из клиентского кода), но не его реализацию, а поэтому мы не можем предположить, есть там контекст или нету. Потому с позиции клиентского кода, данные примеру будут полностью каноничными объектами вписываемые в парадигму ООП.

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


Цитата (twin @ 28.01.2016 - 07:34)
Далеко не все понимают, а значит правильно используют концепцию ООП. Но пару раз написав класс и создав объект, уже смело причисляют себя к тру-ООП программистам.

С этим ни кто не спорит, к сожалению это факт. Пример fansoro от Awilum, бессмысленное использование объектов, когда можно обойтись статическими классами.

Цитата (twin @ 28.01.2016 - 09:30)
Многомерность вычислений путем сохранения состояния объектов. Остальное либо не является прерогативой, либо используется выборочно (не являясь обязательным условием).

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

ИМХО


--------------------
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Мой блог
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
[x] Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15559
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 1 день
Карма: 299

Трезвый :
5 лет, 11 месяцев, 10 дней


Цитата (chee @ 28.01.2016 - 08:57)
Оба случая будут объектно-ориентированы, но с точки зрения клиентского кода. То есть, мы же видим интерфейс объекта(из клиентского кода), но не его реализацию, а поэтому мы не можем предположить, есть там контекст или нету. Потому с позиции клиентского кода, данные примеру будут полностью каноничными объектами вписываемые в парадигму ООП.

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

Цитата (chee @ 28.01.2016 - 08:57)
Но, если взглянуть с точки зрения создателя объекта, то есть если ты знаешь реализацию, можно точно сказать является ли объект замаскированным процедурным кодом, либо объектно-ориентированным.

Тут опять же вопрос про курицу или яйцо. Логично предположить обратное. Если посчитать этот код Объектно-ориентированным, то это не процедура, замаскированная под ООП, а все с точностью до наоборот.

Цитата (chee @ 28.01.2016 - 08:57)
Но при этом у объектно-ориентировано кода всегда присутствую такие признаки как полиморфизм, инкапсуляция (наследование опционально), абстракция, совмещение данных и действий с данными в одной области видимости.
Вот тут не соглашусь. Всё это так, но любой из перечисленных признаков возможен как в отрыве от ООП парадигмы, так и "правильный" ООП код возможен без этих признаков.

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

Мне были интересны именно те признаки, по которым можно классифицировать любой код, как канонический ООП или напротив - не ООП.

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

Так же и с другими "столпами". Если я ни разу не использовал полиморфизм, но код усеян наследованиями и заперт инкапсуляцией - что это? В приведенной мной статье это очень подробно описано. Не буду повторяться.

У процедурной парадигмы такие признаки есть и они четко классифицированы. Есть они и у функционального программирования. А вот у ООП пока только один. Все остальное - на совести разработчика.

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

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

Впрочем это весьма неплохо, если бы постоянно не возникали разнотолки, которые тормозят развитие программирования и приводят к стогнации.

Допустим извечный холивар про сеттеры/геттеры. Или про те же интерфейсы. Или про различные оценки (анти)паттернов. Да и вот такие опросы/холивары, чьё кунг-фу лучше, постянно возникают, что приводит только к разобщенности сообщества программистов.

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

Про функциональное программирование нельзя сказать, что оно - дальнейшее развитие. Хотя появилось несколько позже, чем ООП. В PHP по крайней мере точно. Это отдельное направление. И ни кому в голову не приходит их сравнивать и объявлять ООП устаревшим.

Нужно брать лучшее отовсюду. А не застревать в рамках, которые по большому счету каждый ООПэшник устанавливает для себя сам. Мультипарадигма рулит! biggrin.gif


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

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

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
chee  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Сын полка
Сообщений: 1780
Пользователь №: 38654
На форуме: 2 года, 11 месяцев, 1 день
Карма: 40




twin, столько слов, при этом выводы унылы


--------------------
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Мой блог
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15559
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 1 день
Карма: 299

Трезвый :
5 лет, 11 месяцев, 10 дней


Цитата (chee @ 28.01.2016 - 10:10)
twin, столько слов, при этом выводы унылы

Наверное... Но ты не унывай и не разочаровывайся. Я же не говорю, что ООП это плохо. Я говорю, что это не совсем парадигма. Вот из вики:
Цитата
Паради́гма (от греч. παράδειγμα, «пример, модель, образец») — совокупность фундаментальных научных установок, представлений и терминов, принимаемая и разделяемая научным сообществом и объединяющая большинство его членов.


А какие у ООП фундаментальные установки? Всё, начиная от классов и объектов, заканчивая тремя столпами - сборная солянка, не обязательная для присутствия и не являющаяся прерогативой. А значит не может являться фундаментом.

Не расстраивайся, нужно просто принять как должное. Ну или не принять, я же не настаиваю. smile.gif


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

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

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Oyeme  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Reality is wrong. Dreams are for real
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 1672
Пользователь №: 16955
На форуме: 7 лет, 9 месяцев, 8 дней
Карма: 94




Цитата
ООП, это развите процедурного кода, бесспорно.


Конечно когда php позволяет миксовать куча разного говна то так и выходит что "является ли это процедурный код ,который использует обьекты" ?

Ответ: не совем.

Цитата
   $obj1 = new Example1;
    $data = $obj1->getData();   


Внутри метода getData() возмжна супер сложная бизнес логика котрая связанна между собой различными логическими цепочками..

Уже не попадает под форматы процедурного кода,если только не испозовать методы как функции.Что принципе и большинство новичков и делают и не видят разници и примммущества в ООП.

Что аппликация написанно с миксами и со всеми нарушениями. По стути и не процедурный и не ООП.

Явный ответ это чистый С,который не позволяет миксовать.

Что впринципе и новейшие framework пытаются удержать программиста от анархии и спасти его душу в будущем от критических ситуаций в будещем.

Wordpress и drupal это доказывают насколько ущербны могут быть cms.

https://www.drupal.org/node/77487


--------------------
Programming: Private lessons via skype £45/h

Частные уроки в Лондоне / удаленно по skype.
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:

Опции темыСтраницы: (13) « Первая ... 7 8 [9] 10 11 ... Последняя » Закрытая темаСоздание новой темыСоздание опроса