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

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

5

Сообщение от Newest В этом примере ваши данные, что подаются на вход функции, может менять ещё кто-то кроме этой функции.

С чего ты это взял? Ты даже не знаешь, что за язык.

Сообщение от Newest тут попытка объяснить одно из явлений некоторых языков.

Неудачная причем, т.к. толком ничего не объяснено.

Сообщение от Newest Ага, сборщик мусора ваще не занимает ресурсы. Речь ведь здесь идёт о том, чтобы код был побыстрее, а вы про сборщик мусора … Ну-ну …

Зачастую не больше, чем ручное высвобождение памяти, ты просто не в теме.

Сообщение от Newest Не ну конечно, раз есть RAII и куча всего ещё, то надо было в статье изобразить все варианты выделения памяти.

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

Сообщение от Newest Про два потока – туда же. Мы можем ещё кучу прекрасных вещей упомянуть никак не связанных с этим примером.

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

Сообщение от Newest Вам про то, что не надо внутри функции каждый раз выделять и чистить память при её запуске, что память занимается до запуска функции, а вы про то, что указатели занимают в памяти место. Так, что опять мимо темы.

То есть про необходимость переинициализации ты пропустил мимо ушей?

Сообщение от Newest Ну, наконец-то! А не про это ли в данной статье, а не там ли говорится о private

private ничего не скрывает, учи матчасть.

Сообщение от Newest Мы создаём класс, где функция и данные для её работы отдельно.

Кстати ни одного примера с классом в статье так и не было предоставлено.

Сообщение от Newest Следующее понятие ООП – это полиморфизм. Здесь всё достаточно просто и это понятие есть, по сути, развитие такого явления, как перегрузка функций.

Нет и еще раз нет. Полиморфизм появился до ООП, следовательно не является «понятием ООП». Полиморфизм не развивался из «перегрузки функций». Про универсальный полиморфизм что-нибудь слышал? Он к перегрузке вообще никаким боком и появился до нее.

Сообщение от Newest Хочешь, не хочешь, а без неё ООП не считается ООП

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

Сообщение от Newest Ну дык, сразу было сказано, что статья для введения в курс дела, чтобы показать, что принципы ООП не падают с неба и чтобы начинающих в связи с этим чувствовали бы себя посвободнее.

Для введения в курс дела лучше статью в вике прочитать, там намного меньше глупостей.

0

Сообщение от Newest Пользуясь инкапсуляцией можно оказаться от резервирования и уничтожения памяти внутри функции.

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

Кстати, передавать в качестве параметров переменные, которые должны были создаваться на стеке (float vix), — это действительно глупая затея. И она отлично показывает, как хорошо автор разбирается в вопросе.

Сообщение от Newest Блин, подписи и авторитеты – это ведь так важно!

Ну да, важно. Ведь обычно «авторитеты» не зря заработали свой авторитет, они действительно разбираются в том, о чём пишут.

0

Вот есть простенькая структурка

Вопрос: нужно ли делать x, y, z private и геттеры/сеттеры для них?

0

Сообщение от Evg Т.е. если я напишу статью про автомагнитолы или про автомобильные освежители воздуха, то я смело могу назвать статью "Устройство автомобиля"?

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

Сообщение от korvin_ Зачастую не больше, чем ручное высвобождение памяти, ты просто не в теме.

Зачастую да, но часто и нет. Ага, ну ваще не в теме.

Сообщение от korvin_ То есть про необходимость переинициализации ты пропустил мимо ушей?

Про “про необходимость переинициализации”? Ты о чём вообще? Читаем отрывок, что ты дал:
"В итоге внутри нашей функции не создаются никакие промежуточные переменные, а сама функция ничего не возвращает. Всё необходимое для её работы здесь передаётся функции в качестве её аргументов. В итоге при каждом запуске функции нет нужды каждый раз выделять и чистить память."

а потом ты прокомментировал:
"А указатели ничего в памяти не занимают, да?"

И чё? И где про необходимость переинициализации, которую я упустил?

Сообщение от korvin_ private ничего не скрывает, учи матчасть.

Да ну, он вообще к доступу никаким боком?

Сообщение от korvin_ Да ну? С чего бы вдруг? В некоторых ООП-языках нет строгой инкапсуляции, т.е. можно считать, что ее нет вообще.

В языках с ООП нет инкапсуляции? А как же тогда классическое определение ООП?

Сообщение от Nameless One ...можно отказаться от лишнего резервирования и уничтожения памяти внутри функций (потому что в конечном счёте от него уйти невозможно).

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

Сообщение от Nameless One Ну да, важно. Ведь обычно «авторитеты» не зря заработали свой авторитет, они действительно разбираются в том, о чём пишут.

Вы наверное удивитесь, но часто "кукушка хвалит петуха за то, что хвалит он кукушку". А отсюда и кажущийся авторитет.

0

Сообщение от Newest Шилдта

Нашел на кого ссылаться.

Вот тут: https://www.cyberforum.ru/post4927670.html

Таким образом, внутри функции F11() теперь не будут каждый раз создаваться и удаляться эти самые переменные. Таким образом, резервировать память для данной функции мы будем до её запуска единожды создав соответствующие переменные. Не забывая при этом каждый раз их инициализировать?

Сообщение от Newest Да ну, он вообще к доступу никаким боком?

Разделение доступа и сокрытие — не одно и то же. К.О.

Сообщение от Newest А как же тогда классическое определение ООП?

Процитируй «классическое определение ООП».

0

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

От лишнего (я специально это слово выделил) резервирования уйти можно, полностью от резервирования уйти нельзя. Это очевидные вещи. Где ты видишь противоречие?

Сообщение от Newest Вы наверное удивитесь, но часто "кукушка хвалит петуха за то, что хвалит он кукушку". А отсюда и кажущийся авторитет.

А я то думал, что авторитет зарабатывается знаниями, опытом и достижениями в области CS, а тут вон как получается. Тут выше по треду было названо несколько громких фамилий, может, ты развенчаешь их «кажущийся авторитет»?

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

Если воспользоваться твоей аналогией, то основная посылка такова: если делаешь поверхностный обзор освежителей воздуха и автомобильной акустики, нельзя называть такой обзор «Устройство автомобиля». Просто потому, что такое название не соответствует содержанию статьи.

0

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

Не я хочу сказать, а именно так оно и есть

0

Сообщение от Nameless One От лишнего (я специально это слово выделил) резервирования уйти можно, полностью от резервирования уйти нельзя. Это очевидные вещи. Где ты видишь противоречие?

Рассмотри с точки зрения грамматики русского языка своё вот это:

...можно отказаться от лишнего резервирования (потому что в конечном счёте от него уйти невозможно).

А то, что ты имел в виду другое ну дык люди обычно не экстрасенсы, чтобы угадывать твои мысли.

Сообщение от Nameless One Тут выше по треду было названо несколько громких фамилий, может, ты развенчаешь их «кажущийся авторитет»?

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

Сообщение от Evg Не я хочу сказать, а именно так оно и есть

Сообщение от korvin_ Процитируй «классическое определение ООП».

Цитировать никого не буду, но есть стойкое мнение, что ООП не мыслимо без инкапсуляции, полиморфизма, наследования. Можете посмотреть у Шилдта, не нравится Шилдт, есть википедия, которую тут хвалили. В общем, стандартно вроде как считается, что ООП включает-таки инкапсуляцию. Более того, автор этой темы тоже, как я понял, их не разделяет. У вас же инкапсуляция и ООП – вещи так же далёкие, как устройство автомобиля и ёлочка, что там освежает воздух в салоне. Если вы хотите доказать, какое-то своё понимание ООП, что ООП это нечто без инкапсуляции, то, конечно, можете попытаться, но это уже уход от темы и от общепринятых стереотипов.

0

Сообщение от Newest В общем, стандартно вроде как считается, что ООП включает-таки инкапсуляцию

Сообщение от Newest У вас же инкапсуляция и ООП – вещи так же далёкие, как устройство автомобиля и ёлочка, что там освежает воздух в салоне

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

0

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

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

Сообщение от Newest Цитировать никого не буду, но есть стойкое мнение, что ООП не мыслимо без инкапсуляции, полиморфизма, наследования.

Так и скажи, что не знаешь. Это нормально, потому что нет никакого определения ООП, тем более «классического», иначе не было бы столько разнообразных реализаций ООП (я могу назвать шесть довольно заметно отличающихся друг от друга).

0

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

Как правило люди пытаются понять ооп читая книги и мучая среды разработки, от силы дней 10-12. А потом
устав, бросают это дело с кашей в голове. Тут главное делать перерывы. Вся фишка, что бы понять ооп, нужно читать, мучать мозг, и экспериментировать в среде разработки обязательно с ПЕРЕРЫВАМИ!
И подходить по нескольку раз к одному и тому же...
Когда человек дает отдохнуть мозгу, после таких, казалось бы (а это обманчиво в начале) абстракций, то со временем укладывается в голове все довольно неплохо.

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

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

0

Сообщение от MolodoyCoder Поскольку все они действуют в итоге на глобальные данные (куча ваших глобальных переменных). А глобальные данные не имеют разделов

Полный бред. Ты сам-то программировать умеешь?

0

Сообщение от Evg Полный бред. Ты сам-то программировать умеешь?

Нет. Я скромный.

http://www.java-study.ru/java-uchebnik/103-razloop

0

Сообщение от MolodoyCoder http://www.java-study.ru/java-uchebnik/103-razloop

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

0

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

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

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

0

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

0

Сообщение от Vourhey Не по теме: :cry: это жесть, сделайте мне расчитать обратно...

без трудностей не можу....

0

Сообщение от MolodoyCoder Напишите тогда кратко в чем глобальная и основная разница между ооп и процедурным программированием (одним, двумя предложениями)

Одним: наследование и динамическая диспетчеризация методов.

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

Сообщение от MolodoyCoder И еще непонятно, почему многие вначале так рьяно хватаются за это самое, процедурное программирование

Потому что оно простое как пробка, мало сущностей: процедуры и структуры данных в основном.

0

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

Принципиальная разница только в том, в какой форме писать программу: по другому выглядит пространство имён, по другому выглядят записи вызова функций/методов, по другому выглядит запись наследования. Непринципиальная разница заключается в том, что в языках, реализующих ООП, записи выглядят проще (потому что часть кода неявно генерируется компилятором). Другими словами, на языке, реализующем ООП процесс писанины становится проще (при этом, зачастую, процесс чтения программы усложняется). Другой разницы нет.

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

В реальности выбор языка программирования, выбор подхода (императивный, объектный, функциональный, что-то ещё) как правило только немного упрощает задачу, поскольку позволяет выбрать наиболее удобный инструмент для реализации конкретной цели. А решающую роль играет грамотное проектирование программы. Если программа спроектирована плохо, то никакой ООП, никакой хаскель, никакой opengl тебе не поможет в написании качественного программного продукта. Если программа спроектирована плохо, то рано или поздно проект сдохнет под грузом соплей, костылей и заплаток, привинченных к программе. Если руки прямые, ты на чистом Си напишешь сложную программу, которая легко адаптируется под новые задачи, перед ней возникающие. И такое качество программы будет только сниться криворуким гавнокодерам, которые "выучили" ООП

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

Сообщение от MolodoyCoder И еще непонятно, почему многие вначале так рьяно хватаются за это самое, процедурное программирование ? Ведь не удобно же, если честно

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

5

Сообщение от Evg что те, кто начал изучать программирование через Си++ и ООП, в основной своей массе вырастают гавнокодерами

Подтверждаю. Иногда знает столько что аж говорить с ним неудобно, а дойдет до дела - ноль

0