Преимущество ООП над продедурным

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

0

Сообщение от BozKurt Отсутствие инкапсуляции как таковой

при наличии в язык замыканий (а в луа они есть и еще много где) это оопшный баззворд не имеет никакого смысла

Отсутствие наследования

и? легко эмулируемтся. на раз.

Про полиморфизм я пожалуй ничего не скажу

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

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

я даже не знаю как это комментировать. т.е. оопшники даже не знают что интерфейсы объектов (тем более базовых) менять нельзя? "Превосходное сопровождение продукта!"

посмешил...

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

0

Сообщение от pycture и? легко эмулируемтся. на раз.

процедурщина легко эмулируется с помощью jmp, jne и add, так смысл во всех этих "высокоуровневых языках"?

Добавлено через 2 минуты

Сообщение от pycture я даже не знаю как это комментировать. т.е. оопшники даже не знают что интерфейсы объектов (тем более базовых) менять нельзя? "Превосходное сопровождение продукта!"

приходит заказчик, говорит, что протокол взаимодействия с внешним сервисом поменялся, и вы ему такой "пфф, а вы знаете, что интерфейсы объектов нельзя менять? Так что обойдетесь". Хотя при чем тут смена интерфейса, непонятно, меняется как раз реализация. Поэтому как-то не в тему получилось у вас.

Сообщение от pycture да смейтесь мне не жалко. вам оошникам банда 4-х зачем 10 заповедейй дала? затем что б лапша ложилась ровными рядами вместо как попало, но что лапшой было, ей и останется, как не положи. просто в одних случаях она выглядит красивее в других нет. ну в дополнении к лашичности старая цитата

ну да, старый-добрый Паскаль - лучший выбор ever.

0

Сообщение от Psilon смотрю. Все серьезное написано на джаве/asp.net/руби. Не даром php - Personal Home Page Tools.

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

Добавлено через 1 минуту

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

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

Добавлено через 2 минуты

Сообщение от Psilon приходит заказчик, говорит, что протокол взаимодействия с внешним сервисом поменялся, и вы ему такой "пфф, а вы знаете, что интерфейсы объектов нельзя менять? Так что обойдетесь". Хотя при чем тут смена интерфейса, непонятно, меняется как раз реализация

протокол поменялся, сделай новый объект и подключи его для этого заказчика, что б он был вместо старого, или построй новый на основе старого. но старый никтоо не меняет. в чем проблема то?

0

pycture, многие вещи реализовать на процедурном языке программирования труднее чем на объекто-ориентированном. К примеру, на процедурном языке будет довольно трудно написать ту же рпг - есть разные типы оружия брони и т.д.
В то же время вещей ,которые трудней реализовать на объекто-ориентированном языке - очень мало.

0

процедурщина легко эмулируется с помощью jmp, jne и add, так смысл во всех этих "высокоуровневых языках"

отвязаться от железа. угадал ?

0

процедурный круче

0

Сообщение от rutelun К примеру, на процедурном языке будет довольно трудно написать ту же рпг - есть разные типы оружия брони и т.д.

тото луа стандарт дефакто к куче игр как скрипт высокого уровня

0

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

бред

Сообщение от pycture причем тут эволюция. ооп это шаг в сторону от процедурщина. 2 рядом стоящие технологии называть эволюцией это перебор

нет.

Сообщение от pycture протокол поменялся, сделай новый объект и подключи его для этого заказчика, что б он был вместо старого, или построй новый на основе старого. но старый никтоо не меняет. в чем проблема то?

да, на ООП это нужно будет просто изменить один объект, в процедурщине - лазить по всему проекту и смотреть, не забыто ли что.

Хотите холиварить - холиварьте, смысл спорить с человеком, у которого во всем виноваты попилы и заговоры жидомассонов, а объективных причин он в упор не видит Вот и я не вижу.

0

высокоуровневый прибыльнее. в одного ни на чем все равно толком не напишешь какая разница.

Добавлено через 54 секунды
а на процедурном в одного много фичей можно забомбить если на форумах не трещать

0

pycture, я специально указал рпг - много однотипных объектов.

0

Сообщение от Psilon да, на ООП это нужно будет просто изменить один объект

не изменить а создать. в луа нужно будет создать одну функцию. никакой разницы нет.

Добавлено через 5 минут

Сообщение от Psilon во всем виноваты попилы

а вы вроде с шарепоинтом работаете. вот скажите честно неужто более дешевых аналогов этоого монстра нет? вроде как есть и в разы дешевле. так почему в крупные конторы пихают шарепоинты. (надеюсь ответа типа "потому как это качественный продукт" не будет)

0

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

0

Сообщение от pycture а вы вроде с шарепоинтом работаете. вот скажите честно неужто более дешевых аналогов этоого монстра нет? вроде как есть и в разы дешевле. так почему в крупные конторы пихают шарепоинты. (надеюсь ответа типа "потому как это качественный продукт" не будет)

для шарепоинта - наверное есть, хотя с другими CMS я не работал. То есть это из разряда "винда-мастдайка". Очень много функционала из коробки. Разработка с 0 подобной системы обычно и дороже, и содержит больше багов. И да, я не знаю популярных CMS подобного уровня, написанных на LUA.

Все зависит от потребностей. Если нужен сайт попроще - мы используем обычный Asp.Net, никто не сует шарик в проекты на "показать полторы странички". А вот ASP.Net/MVC вполне конкуретноспособны по отношению к тому же руби/рельсам, джависты тоже там сайтики пилят, на чем именно, правда, я не особо в курсе. Но выглядит нормально.

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

0

Сообщение от rutelun я специально указал рпг - много однотипных объектов

вот этот линк http://en.wikipedia.org/wiki/C... ideo_games говорит что Baldur's Gate к примеру RPG. считается?

0

Сообщение от pycture вот этот линк http://en.wikipedia.org/wiki/C... ideo_games говорит что Baldur's Gate к примеру RPG. считается?

https://www.google.ru/search?q... evelopment 366k
https://www.google.ru/search?q... evelopment 2480k

0

pycture, я не говорил, что это невозможно - просто без интерфейсов и классов это становится существенно сложней.

0

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

0

pycture, единственной альтернативой ООП на сегодня является ФП, кто бы что не говорил. Вот там действительно можно круто и без объектов жить. Только вот ФП все же не является процедурщиной

0

Сообщение от Psilon И да, я не знаю популярных CMS подобного уровня, написанных на LUA

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

но шарик действительно достаточно качественный продукт

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

А вот ASP.Net/MVC вполне конкуретноспособны по отношению к тому же руби/рельсам

а вот это уже интересно. и так что имеем. webforms все из себя ооп по сути не взлетели, шарик лучшее тому потверждение. ASP.Net/MVC последнее время зашевелилися. почему? потому как в 4-й нет ввели dynamic тип который в mvc стал активно использоваться (ViewBag и оные). и когда C# стал по сути руби тогда он стал конкурентно способен в вебе. так что по сути ооп даже в вебе провалилось

0

pycture, ага, поэтому typescript так бешенно обретает популярность, потому что dynamic и отсутствие типизации - это круто.

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

0