Для обсуждения: ООП или не ООП? Вот в чём вопрос!

[Troll]

Сообщение от АлЁша

Ошибаетесь А смысл поста был не в конкретных цифрах, а в доступности методов программирования для освоения широкими массами. И с появлением ООП эта доступность появилась: куда ни плюнь вокруг одни "программисты" Даже в Удомельском техникуме учат

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

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

[АлЁша]

Сообщение от Troll

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

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

[Troll]

Сообщение от АлЁша

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

Ответ: на функциональном на порядок быстрее. Аргументация: Ему не надо будет изучать и понимать достаточно абстрактные (для данного примера) темы классообразования, наследования, инкапсуляции, полиморфизма и пр. дебри ООП.

[АлЁша]

Сообщение от Troll

Ответ: на функциональном на порядок быстрее. Аргументация: Ему не надо будет изучать и понимать достаточно абстрактные (для данного примера) темы классообразования, наследования, инкапсуляции, полиморфизма и пр. дебри ООП.

А зачем ему их изучать? ведь они для данного примера абстрактные? Человек не собирается становиться программистом, у него задача разово написать тетрис, и изучать он будет только то, что для этого ему нужно, не вникая ни в какие теории программирования.
ЗЫ вопрос не снят.

[Troll]

Сообщение от АлЁша

А зачем ему их изучать? ведь они для данного примера абстрактные? Человек не собирается становиться программистом, у него задача разово написать тетрис, и изучать он будет только то, что для этого ему нужно, не вникая ни в какие теории программирования.
ЗЫ вопрос не снят.

Ответ: А как же данный индивидуум сможет создать грамотное приложение (читать Тетрис) согласно принципов ООП, не зная основ ООП?
Вопрос: А Вы сами то к программированию каким боком? Больно вопросы у Вас...

[Pitty]

Сообщение от Troll

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

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

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

[Pitty]

Сообщение от Troll

Ответ: А как же данный индивидуум сможет создать грамотное приложение (читать Тетрис) согласно принципов ООП, не зная основ ООП?
Вопрос: А Вы сами то к программированию каким боком? Больно вопросы у Вас...

Угу, у меня такое же мнение. Поддерживаю и ответ и вопрос.

[Pitty]

Сообщение от АлЁша

Ошибаетесь А смысл поста был не в конкретных цифрах, а в доступности методов программирования для освоения широкими массами. И с появлением ООП эта доступность появилась: куда ни плюнь вокруг одни "программисты" Даже в Удомельском техникуме учат

В какой из частей своего поста я ошибаюсь? В первой или во второй?
ИСпользуя принципы ООП, а точнее, используя огромное количество библиотек классов, написанных для того или иного языка, неопытный пользователь может взять какой-нибудь учебник и написать все примеры, которые там есть, но врядли сможет написать что-то более практичное, особенное если сложность проекта будет больше 1000 строк кода (кроме автогенерируемых). Хороший программист это в первую очередь - жесткие правила для себя, жесткая система, а этому врядли учат в каком-нибудь ПТУ.
И ещё, моё лично мнение, чтобы начать изучать ООП, надо сначала изучить структурный подход. Только владея несколькими методиками, можно эффективно писать программы, применяя в той или иной ситуации разные инструменты.
Вот простой пример. Перед программистами стояла задача написать программу (определенные аппаратные средства), которая бы собирала данные с термодатчиков (термосопротивления), и для фильтрации значений вычисляла многочлены 16-20 степени (для каждого отсчёта и каждого датчика). Так вот, никакие ухищрения, в том числе и напиание кода на ассемблере, не позволяло достичь приемлемого уровня производительности. Простым решением было заставить сами датчики обрабатывать данные и сообщать супервизору уже готовые отфильтрованные значения. При этом стоимость самих датчиков выросла не сильно, а их точность и удобство использования только увеличились.
Иногда, чтобы эффективно решить задачу, нужно выйти даже не за рамки языка, а за рамки компьютера... выйти в 4е измерение. В)

[АлЁша]

Сообщение от Troll

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

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

Сообщение от Troll

Вопрос: А Вы сами то к программированию каким боком? Больно вопросы у Вас...

Чаще левым, монитор слева стоит Скажем так: тетрис нарисую, и в ООП и в функциональном, но в большинстве приходится работать с микропроцессорными приборами на базе х86, остальное в основном приложения для их отладки и обработки результатов

[Troll]

Сообщение от АлЁша

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

1) Поьзователь и программист все же несколько разные люди и задачи стоящие перед ними несколько разные. Человек. который первый раз сел за компьютер и пробует двигать мышкой уже может называться пользователем, человека написавший первую букву на каком либо языке - программистом не назавешь... не правда ли? Но в каком то смысле я. кажется, начинаю понимать что Вы хотите сказать. Действительно, если какой либо индивидуум скачает все неообходимые для написания тетриса классы, реализация законченного приложения потребует очень малого времени, минимальнейших знаний как в ООП, так и вообще в программировании. Но, думаю, так же неообходимо понимать, что классы должны откуда то браться...т.е. должны присутствовать "настоящие" программисты, для которых и написана статья темы. Для которых ООП не превращает программирование в процесс доступный даже "кухарке". От ответа я не ухожу, мб я просто не до конца понимаю ход Ваших мыслей и Ваши вопросы.
2) По поводу функционального: Извените, но с моей точке зрения, вы опять не очень верно написали. Вы пишите. что с помощью функционального программирования не возможно использование сокрытия реализации.. но берем ту же Windows API или любую другую API, тысячи функций, о которых (очень часто) программист знает только название, параметры и выполняемое действие. То же самое сокрытие реализации не так ли? Другой вопрос. что реализовано не так надежно и удобно.
3) теперь по поводу "грамотного приложения". Программирование чрезвычайно коммерцианализированная наука (хотя программирование, вроде, еще не является наукой). И неграммотно написанное приложение проиграет конкуренцию. В книжке Станислава Жаркова Shareware: профессиональная разработка и продвижение программ описан очень хороший пример. Рассматривается два практически идентичных приложения, представляющих сервис Who is? только одно написано на Си и весит пару кило, другое на VB и весит почите полтора метра, какое по вашему приложение скачают большее количество пользователей? Даже если не зацикливаться на коммерции, то какую программу предпочтут конечные пользователи - маленькую, быстро и надежно работающию или же громадную, полную багов, отчайно тормазящию даже на мощных компьютерах? В свете вышеизложенного, по моему мнению, неграмотно написанное приложение. вполне можно не считать приложением. (Про неуловимого Джо, думаю, все анекдот помнят)

Чаще левым, монитор слева стоит Скажем так: тетрис нарисую, и в ООП и в функциональном, но в большинстве приходится работать с микропроцессорными приборами на базе х86, остальное в основном приложения для их отладки и обработки результатов

Вопрос снят. Приношу извенения за сомнения.