Стоит ли использовать ООП?

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

5

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

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

1

Сообщение от _Ivana Вы наверное имели в виду что-то из этой серии http://www.ray-tracing.ru/articles221.html ,

Совершенно верно, это одно из популярных приложений этой задачи

Сообщение от _Ivana но я просто реализовал билинейную интерполяцию на квадратной сетке, кустарно подобрав rgb-цвета для отображения значений функции

Это совсем не то о чем шла речь

Во-первых все происходит а пространстве (x, y, z для каждой точки). А главное - сетки-то никакой нет, мы можем хранить только обсчитанные точки, иначе никакой памяти не хватит. И надо что-то делать чтобы найти в какие радиусы попали (не забудьте - радиус у каждой точки свой).

Кстати - догадались почему такая постановка некорректна?

0

Сообщение от Нитонисе Я в целом согласен с основным посылом taancer, что ООП имеет существенные преимущества перед процедурным программированием, но преимущества предстают во всей красе при двух условиях: 1. Программист должен понимать ООП (действительно понимать, а не думать, что понимает). 2. ООП наиболее хорошо себя проявляет в больших программах.

Никто не доказал превосходство одного подхода перед другим. Bob Glass, Software Conflict 2.0.

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

ООП это так круто и здорово, что уже не осталось ни одного чистого ООП языка.

0

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

0

Сообщение от Igor3D Это совсем не то о чем шла речь

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

Сообщение от Igor3D Кстати - догадались почему такая постановка некорректна?

Нет, но и не думал особо над этим Можете написать, а можете оставить на подумать.

0

Сообщение от Нитонисе знатно затроллили taancer, а жаль. Его было интересно читать, в отличие от первых двух

Ты вернулся под новым ником? И повторяешь все одно и тоже, слова, слова, одни лишь пустые слова...

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

Сообщение от Black Fregat ООП, как и всякая парадигма, в первую очередь выстраивается в голове разработчика. И вот тут оказывается, что одним эта парадигма укладывается в стиль мышления, поэтому подходит и нравится, а другим - нет.

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

0

korvin_, позвольте таки не согласиться. Редкие практические задачи столь однозначны, что можно судить, какая парадигма для них наиболее естественна. Одну и ту же задачу разным людям сподручнее решать с использованием различных парадигм. И потом они очень долго с пеной у рта будут друг другу доказывать, насколько прекрасно решение в парадигме X и насколько ужасно решение в парадигме Y.
А ещё тут нужно помнить известную фраза о том, что "если у Вас в руках молоток, то всё вокруг представляется гвоздями". Человеку свойственно расширять пределы применимости привычной ему парадигмы.

1

Сообщение от Black Fregat Человеку свойственно расширять пределы применимости привычной ему парадигмы.

Угу, и молотком не только гвозди забивать.

0

Таки да. Я уже давно оставил попытки изменить мир.

0

Сообщение от _Ivana Моя идея была в том, что если Haskell сам кэширует значения функций, то можно было бы это использовать - но она провалилась, ибо он не кэширует

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

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

Отрадно видеть что человек сохранил объективность (в отличие от подавляющего большинства исписавших не один десяток листов про "парадигмы" )

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

Сообщение от _Ivana ...а можете оставить на подумать.

На подумать То я задачу обрезал почти до нуля, реально все намного сложнее

0

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

0

Сообщение от Igor3D Помнится в компиляторе gcc есть директива указывающая что рез-т ф-ции можно кешировать

Я так думаю, что речь идёт об __attribute__((pure)). Это есть свойство функции, которое означает, что она "чистая", т.е. работает исключительно с параметрами и не работает с глобальными переменными или указателями. Но это вовсе не означает, что результат можно "кэшировать". Если в пределах досягаемости оптимизатора внутри одной функции видны два вызова с одними и теми же параметрами, то для вместо построения второго вызова будет подставлен результат первого вызова. Однако если вызовы pure-функций находятся в разных функциях, то компилятор ничего не будет "кэшировать", а построит два вызова

0

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

Так с этим никто и не спорит

Сообщение от Igor3D Но речь идет об оптимизации небольшого, локального фрагмента кода - не более того.

0

Сообщение от Igor3D Так с этим никто и не спорит

Да, что-то я дальше невнимательно прочитал

0

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

1

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

Стратегия "никогда не использовать ООП" неоптимальна (так же как и стратегия "всегда использовать ООП"). В некоторых случаях ООП подходит намного лучше других парадигм. Например, при написании пользовательского интерфейса, содержащего много почти одинаковых элементов (типичный оконный интерфейс).

0

Shamil1,
1) Я немного скорректировал свои заблуждения и даже скачал Smalltalk, хотя пока так и не попробовал его, все откладываю
2)

Сообщение от Shamil1 много почти одинаковых

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

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

0

На холивар и контент бежит https://habrahabr.ru/company/mailru/blog/307168/

0

Сообщение от @KOT@ Чтобы получить переменную класса по правилам ооп нужно создавать метод для ее чтения?

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

Добавлено через 53 секунды

Сообщение от _Ivana что наследование - необязательный атрибут ООП

Там где нет наследования жди множественного наследования на каждом шагу.

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

Сообщение от _Ivana а переиспользование можно достичь и другими способами

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

0

На холивар и контент бежит

Дочитал до места с примером на java Где автор перегружает два метода add и addAll в наследнике. Я не знаю как там дела обстоят в Яве, но на делфях, да и в с++ достаточно было сделать метод add виртуальным и только его перегрузить в наследнике. Тогда бы и ошибки не было. Вообщем, компетентность автора под вопрсом, либо крайне неудачный пример. В любом случае читать далее перехотелось, перешёл к комментариям, а там ещё веселее - закидали какахами

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

1