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

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

5

Сообщение от Metal_666_ Вот кстати сейчас читаю "совершенный код"

Для тех кто не скачал:

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

0

Зачем читать книги в которых трактуются "принципы"(полезность) ООП? ты попробуй сам, и оценишь, есть ли польза...

0

Сообщение от snake32 Для тех кто не скачал

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

0

ООП (в частности та самая инкапсуляция) - это именно для увеличения скорости работы программ, ну и программиста. Сама концепция ООП – это просто развитие концепции функций. Часто ООП даётся как упавшая с неба данность в отрыве от того, что к этому привело, вот и кажется, что процедурное программирование и ООП противоречат друг другу. На самом же деле ООП – это всего лишь развитие понятия функции и более того, плотно поработав с функциями, вы в итоге сами изобретёте ООП. Более подробно и развёрнуто, как инкапсуляция возникает из работы с функциями описано здесь:

http://www.prointellekt.ru/ProgrOOP1.php

Рекомендую – сразу отпадут вопросы про private и public, а так же о том, когда имеет смысл применять ООП, а когда нет.

0

Сообщение от Newest ООП (в частности та самая инкапсуляция) - это именно для увеличения скорости работы программ

Приведи, пожалуйста, пример, когда ООП (в частности инкапсуляция) даёт ускорение по отношению к программе без ООП

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

Сообщение от Newest http://www.prointellekt.ru/ProgrOOP1.php

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

1

Сообщение от Newest это именно для увеличения скорости работы программ

http://lucacardelli.name/Paper... sOfOO.html

... Let us now consider object-oriented languages, and see how they compare on these metrics. Economy of execution. Object-oriented style is intrinsically less efficient that procedural style. In pure object-oriented style, every routine is supposed to be a (virtual) method. This introduces additional indirections through method tables and prevents optimizations such as inlining. The traditional solution to this problem (analyzing and compiling whole programs) violates modularity and is not applicable to libraries. ...

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

Лол, почему не ФП?

0

Сообщение от Evg Приведи, пожалуйста, пример, когда ООП (в частности инкапсуляция) даёт ускорение по отношению к программе без ООП

Пример в указанной статье. Отказ от резервирования и уничтожения памяти внутри функции каждый раз при её вызове разве не увеличивает скорость программы? В этом и есть одна из фишек и целей инкапсуляции.

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

Поконкретнее, пожалуйста, где в этой статье демонстрируется, что автор не разобрался в ООП?

0

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

Казалось бы, при чём здесь ООП?

Сообщение от Newest В этом и есть одна из фишек и целей инкапсуляции.

Инкапсуляция к этому не имеет никакого отношения.

А автор все-таки школоло, если приводит такие аргументы.

0

Сообщение от Newest Пример в указанной статье

В указанной статье поток сознания и огрызки кода. Приведи ПОЛНЫЕ примеры кодов с ООП и без ООП, из которых бы явно вытекало, что код с ООП работает быстрее.

Сообщение от Newest Поконкретнее, пожалуйста, где в этой статье демонстрируется, что автор не разобрался в ООП?

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

0

Сообщение от Newest Поконкретнее, пожалуйста, где в этой статье демонстрируется, что автор не разобрался в ООП?

Вообще во всей статье. От начала до конца.

0

Сообщение от Nameless One Казалось бы, при чём здесь ООП? Инкапсуляция к этому не имеет никакого отношения.

Ну так инкапсуляция даёт удобный инструмент, чтобы делать это проще – разве нет?

Сообщение от Evg Приведи ПОЛНЫЕ примеры кодов с ООП и без ООП, из которых бы явно вытекало, что код с ООП работает быстрее.

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

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

Термин инкапсуляция ничего не говорит? В статье показано, когда инкапсуляция удобна – позволяет уйти от функции с огромным количеством аргументов.

Сообщение от korvin_ Вообще во всей статье. От начала до конца.

Надо же, как конкретно и аргументировано! Прямо всё по полочкам.


Про школоло скажу одну вещь – дружеский совет тем, кто это слово так любит. Ребята, вы палитесь этой фразой.

0

Сообщение от Newest Ну так инкапсуляция даёт удобный инструмент, чтобы делать это проще – разве нет?

Чтобы делать проще что? «Отказ от резервирования и уничтожения памяти внутри функции»? Ты хоть определение инкапсуляции читал?

Кстати, статья написана так, как будто инкапсуляция возможна только в ООП-языках.

Сообщение от Newest Про школоло скажу одну вещь – дружеский совет тем, кто это слово так любит. Ребята, вы палитесь этой фразой.

Ок, ты меня устыдил. *Сел делать уроки*

0

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

[sarcasm]О да, именно в этом и суть инкапсуляции.[/sarcasm]
ущел от функции с огромным количеством параметров без всякой инкапсуляции.

0

korvin_, но ведь если заменить Gee на gee и использовать структуру в другом пакете, то это будет уже ИНКАПСУЛЯЦИЯ!!!11 И да, ты же нигде вручную память не выделяешь!

Шах и мат!

0

Сообщение от Newest Надо же, как конкретно и аргументировано! Прямо всё по полочкам.

Ты и так уже слишком толст. Ну да ладно, вот еще немного корма:

Часто это из-за того, что у авторов нет чёткого понимания о том, что же такое ООП

Ну да, какой-то анонимус, не потрудившийся даже подписаться в своей "статейке" определенно знает ООП лучше, чем

доктор компьютерных наук Стэнфорда, старший архитектор по разработке ПО сначала Sun, а потом и IBM, Ричард Гэбриел

или лучше

Гая Стила, отца-разработчика языка Scheme, крупнейшего специалиста-теоретика по ООП, авторитет которого в американской академической среде непререкаем.

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

Как будто кроме проблемы Си -- это проблемы всех не-ООП языков.

Вот мы уже и подошли к первой идее ООП – к идее структуры.

Лол, структуры были до ООП, в том же Си.

Как известно структура является, по сути, предтечей класса и объединяет в себе данные разного типа.

Вообще нет.

В примере с изображением мы объединили данные типа массива и данные типа переменных – размеры массива.

Что вообще такое "данные типа переменных"?
Я объединил массив и его размеры без всякого ООП.

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

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

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

Выделение памяти на стеке? Не, не слышал. Автоматическая сборка мусора? Не, не слышал.

То есть, например, пусть каждый раз в функции написанной на c++ выделяется память следующим образом:

Ну и зачем там указатели? А про RAII автор тоже не слышал?

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

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

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

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

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

Т.е. возвращаемся к началу -- создавать данные перед вызовом функции. Только вот на стеке они создаются значительно быстрее, чем в куче. Это просто

Ведь часто функция – это достаточно большая подпрограмма.

Декомпозируй на более мелкие. К.О.

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

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

И опять взаимоисключающие абзацы:

Класс – это такая форма организации кода, где под одним именем (идентификатором) находятся и данные и функции для их обработки.

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

Объект, к слову, – это конкретная реализация класса.

Объект -- это экземпляр класса, а не реализация.

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

Перегрузка функций -- это и есть один из подвидов полиморфизма. И полиморфизм появился до ООП.

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

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

Что-то многовато получилось, смотри не лопни.

P.S. У автора оказывается есть еще статья про типы: http://www.prointellekt.ru/Progrint.php , слава богу короткая, но наверное поржать тоже можно.

0

Сообщение от Newest Термин инкапсуляция ничего не говорит?

Говорит. Но на всякий случай тебя уведомлю, "инкапсуляция" и "ООП" - это вовсе не одно и то же

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

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

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

Сообщение от korvin_ P.S. У автора оказывается есть еще статья про типы: http://www.prointellekt.ru/Progrint.php , слава богу короткая, но наверное поржать тоже можно

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

0

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

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

Сообщение от korvin_ [sarcasm]О да, именно в этом и суть инкапсуляции.[/sarcasm] Code 1 2 3 4 5 6 7 8 9 10 type Params struct {     Foo int     Bar string     Gee []float64 }   func MyCoolProc(p *Params) {     p.Foo = len(p.Gee)     p.Bar = fmt.Sprint(p.Gee) } ущел от функции с огромным количеством параметров без всякой инкапсуляции.

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

Сообщение от korvin_ Ну да, какой-то анонимус, не потрудившийся даже подписаться в своей "статейке" определенно знает ООП лучше, чем или лучше

Блин, подписи и авторитеты – это ведь так важно! Вы прямо, как тот эстет, который заявляет типа того, что: как можно судить о музыке, если вы не знаете биографию композитора и то насколько этот композитор авторитетен.

Сообщение от korvin_ Как будто кроме проблемы Си -- это проблемы всех не-ООП языков.

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

Сообщение от korvin_ Автоматическая сборка мусора? Не, не слышал.

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

Сообщение от korvin_ Ну и зачем там указатели? А про RAII автор тоже не слышал?

Не ну конечно, раз есть RAII и куча всего ещё, то надо было в статье изобразить все варианты выделения памяти. А может там чего ещё, кроме RAII не описано? Ну так вы не стесняйтесь, ведь есть ещё куча прекрасных вещей, которые вы можете упомянуть, там, например, ну ваще ничего несказанно об ассемблере, о том, как устроен компьютер. Эх, вот ведь недоработка!

Сообщение от korvin_ Не забывая при этом каждый раз их инициализировать? Еще наводящий вопрос: что будет, если теперь запустить эту функцию дважды в два потока?

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

Сообщение от korvin_ А указатели ничего в памяти не занимают, да?

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

Сообщение от korvin_ Нет, суть инкапсуляции в сокрытии внутренней реализации объекта или модуля.

Ну, наконец-то! А не про это ли в данной статье, а не там ли говорится о private, который нужен для того, чтобы функция работала с данными так, как если бы они были созданы внутри функции. Ведь сокрытие есть и для переменных созданных внутри функции. Так нет, нам этого сокрытия недостаточно. Мы создаём класс, где функция и данные для её работы отдельно. Так, что суть инкапсуляции далеко не только в сокрытии, а и в разделении данных и того, что с этими данными работает.

Сообщение от korvin_ Перегрузка функций -- это и есть один из подвидов полиморфизма. И полиморфизм появился до ООП.

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

Сообщение от Evg Говорит. Но на всякий случай тебя уведомлю, "инкапсуляция" и "ООП" - это вовсе не одно и то же ... Но где же тут ООП?

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

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

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

0

Сообщение от Newest В примере из статьи, описав в классе данные, как private вы получите доступ к этим данным только из функции класса

Детская наивность и вера во всё светлое...

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

Т.е. ты уже перестаёшь утверждать, что статья была про ООП?

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

Вообще-то я писал про другую статью (о базовых типах)

0

Сообщение от Evg Детская наивность и вера во всё светлое...

Ну дык и данные образованные внутри функций не такие уж и закрытые, так ведь речь не об этом.

Сообщение от Evg Т.е. ты уже перестаёшь утверждать, что статья была про ООП?

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

К тому же сама тема этой ветки форума - вопрос, где лучше применять ООП, а где можно и без него. Статья в принципе отвечает на этот вопрос.

0

Сообщение от Newest Ну дык и данные образованные внутри функций не такие уж и закрытые, так ведь речь не об этом.

А о чём?

Сообщение от Newest А разве когда я описываю то из чего состоит некое явление, то я не описываю это самое явление хотя бы частично

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

Сообщение от Newest Поэтому нет - не перестаю.

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

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

Статья вообще не про ООП.

0