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

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

5

Сообщение от CoderHuligan А как насчёт ООП-лапши?

Ну а насчет лучших/стандартизированных/мэйнстреймовых высеров разных парадигм - возьмем несколько общеизвестных порождений ООП/КОП.
MFC - Все четко и логично, хотя концепция устарела даже на момент ее появления.
VCL/FireMonkey - тоже все четко и логично хотя на паскакале.
DirectX - тоже все четко и логично.
теперя без ООП :
OpenGL - полный бардак 4,5 версий, хотя функционал аналогичен Direct3D. Причем настолько бардак что 5-я версия кроме перехода на ООП еще и название сменила дабы не ассоциироваться с предыдущей бредядитной.
STL - юселесс говнокод который превращает в говнокод любой использующий его кот. Именно по той причине что там использовалась ФП а не ООП парадигма.
WinAPI - без ООП обертки этот лисапед разве что в хеллоувердах реально пользовать. При этом обернуть этот лисапет так чтобы его квадратневые колеса не стучали гораздо сложнее чем сделать толковый аналог с тем же функционалом с нуля.

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

Сообщение от CoderHuligan Просто это показатель сложности(запутанности) кода. Как с kiss-принципом? Забыли.

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

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

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

ООП/КОП позволяет собирать эти амебы в колонии. Напомню человеческий моск это тоже часть колонии одноклеточных.

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

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

Дураку парадигма не писана.

Сообщение от CoderHuligan И когда пытаются заставить их выполнять чуждую их природе работу,

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

Сообщение от CoderHuligan а вопросы контроля не входят в область их компетенции

Контроля чего? Корректности входных/выходных данных и их логической целостности при изменении? Так именно это есть одно из главных предназначений инкапсуляции.

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

Сообщение от CoderHuligan А простое поведение обьектов реализуется сложными средствами комилятора.

Никаких сложных средств нет. Есть список методов/полей и больше ничего.

0

Сообщение от Fulcrum_013 теперя без ООП

Забыли TCL и его библиотеку TK. Прекрасно всё реализовано без обьектов.
А ваши COM обьекты вносят только неоправданную сложность.

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

Создали же TK. Например редактор AkelPad полностью выполнен на чистых Win API, а по функционалу не остаёт от notepad++, который реализован в ООП, отличаясь от последнего большей стабильностью и меньшем количеством багов(я вообще не знаю какие-то баги акелы, а вот в ноутпаде их пруд пруди).

Сообщение от Fulcrum_013 И вот как раз для работы с высокоуровневыми абстракциями ООП и нужен.

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

Сообщение от Fulcrum_013 ООП/КОП позволяет собирать эти амебы в колонии. Напомню человеческий моск это тоже часть колонии одноклеточных.

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

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

Сообщение от Fulcrum_013 Контроля чего? Корректности входных/выходных данных и их логической целостности при изменении? Так именно это есть одно из главных предназначений инкапсуляции.

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

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

Сообщение от Fulcrum_013 Никаких сложных средств нет.

Угу. Что же тогда компиляторы ++ так разбухли, что их не могут до конца протестить даже сами их разрабы?

0

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

Что подразумевается под контролем самих объектов? Контроль корректности/логической целостности данных они осуществляют сами.

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

Бываю обычные. И это обычно полный бардак типа WinAPI. Бывают ООП библиотеки. И там все четко и разложено по полочкам.

Сообщение от CoderHuligan Угу. Что же тогда компиляторы ++ так разбухли, что их не могут до конца протестить даже сами их разрабы?

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

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

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

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

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

Сообщение от CoderHuligan в отличие от никем невиданного повторного кода ООП

MFC, VCL, FireMonkey, QtWidgets, DirectX, SolidAPI и ParaSolid, CompassAPI - эти ООП/КОП библиотеки наверное вообще никем не используются?

0

Сообщение от Fulcrum_013 Что подразумевается под контролем самих объектов? Контроль корректности/логической целостности данных они осуществляют сами.

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

0

Сообщение от CoderHuligan Например редактор AkelPad полностью выполнен на чистых Win API, а по функционалу не остаёт от notepad++, который реализован в ООП, отличаясь от последнего большей стабильностью и меньшем количеством багов(я вообще не знаю какие-то баги акелы, а вот в ноутпаде их пруд пруди)

Ага. Вы бы сравнили для примеру IDE Turbo Pascal 5.5 (крайняя без ООП) и Turbo Pascal 6.0 (первая с ООП). Функционал что самое интересное вроде бы похожий. А про всякие нотепады - ну пользовать один мемо можно и напрямую через апи. Но даже это очень неудобно. А баги не парадигма делает а программисты.

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

Сообщение от CoderHuligan Обьект это структура данных, которая должна подлежать контролю со стороны.

Объект это экземпляр класса. Т.е. совокупность данных и обрабатывающих оные данные методов(поведения).

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

Сообщение от CoderHuligan Обьект это структура данных, которая должна подлежать контролю со стороны.

Объект это экземпляр класса. Т.е. совокупность данных и обрабатывающих оные данные методов(поведения).

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

Сообщение от CoderHuligan Экскаватор может работать в разных карьерах, добывая песок разных расцветок. Он не может быть привязан к одному карьеру и одному типу песка. Он не может быть одно целое с ними. Он - действие. Они - материал, с которым работают, который изменяют.

В данном случае песок никоим образом не должен являться частью экскаватора. Тот кто будет эскаватор с песком смешивать недопонимает задачу. Цвет песка это поле карьера а не эскаватора. И тогда все просто и логично. Но при этом ни карьеру ни песку не надо заморачиваться по поводу скока у эскаватора шестерен в каком редухторе и какой именно котел - паравой или урановый его приводит в действие. Это ужо проблемы эскаватора и его взаимоотношений с оным котлом.

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

Сообщение от CoderHuligan Вещество и энергия, которая воздействует на это вещество, не могут быть одним обьектом.

Энергия не может знать какое воздействие на каждое конкретно вещество она произведет. Это может знать только само конкретное вещество.

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

Сообщение от CoderHuligan А контролировать саму себя она может лишь в ограниченном диапазоне компетенции

В отличии от к примеру контейнера в котором он находится объект хотя бы точно знает какого он типа. Поэтому контролировать себя в его компетенции обычно гораздо более чем в компетенции кого либо еще. Вообще четкое разделение зон ответственности код - одна из киллер-фич ООП.

0

Сообщение от Fulcrum_013 А баги не парадигма делает а программисты.

Парадигма может любезно предоставить саму возможность этого в виду своей сложности.

Сообщение от Fulcrum_013 Энергия не может знать какое воздействие на каждое конкретно вещество она произведет. Это может знать только само конкретное вещество.

Вещество ничего не может знать, как и энергия. "Знать" может лишь то, что стоит за пределом обоих, то есть общая повелительная концепция программы, то бишь САМА ПРОГРАММА.
Энергия - её инструмент для обработки вещества данных.

0

Сообщение от CoderHuligan то бишь САМА ПРОГРАММА

Кот это такие же данные. Фактически знание о том как произвести ту или иную обработку других данных.

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

Сообщение от CoderHuligan Парадигма может любезно предоставить саму возможность этого в виду своей сложности

Все гениальное просто. Но для понимания простоты тоже потребуется гениальность. Гениями считаются люди с IQ от 150 и выше. Внимание вопрос: сколько кодеров майкрософта/эппла/гугла/свой вариант имеют IQ выше 150 если у Гейтса около 160?

Добавлено через 3 минуты
Следствие из ответа: 20% разрабов которые простоту осилили получают 80% з/п в индустрии, остальные 80% разрабов 20% з/п. А те кто з/п вообще не получают пишут всякие акелпады и т.п и заливают их на файлопомойки типа гитхаба. Отсюда и баги.

Добавлено через 1 минуту
А вообще ООП это такой фоку-покус который позволяет делать очень сложные дела очень простыми методами. Именно за счет того что каждый метод имеет свою четко ограниченную зону ответственности а сами методы четко сгруппированы и разложены по полочкам за кого именно они отвечают.

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

Сообщение от CoderHuligan Создали же TK.

То что там нет ключевого слова class еще не значит что она не по ООП парадигме сделана. Так же как и наличие оного не значит что использовалась ООП парадигма (к примеру как в STL). ООП еще на фортране в 70-х во всю пользовали. А скорее всего и до фортрана. Индирект колл не для мебели появился в 40-х а для реализации возможности хранить указатель на кота вместе с данными которые этот кот облизывает. Ну линуха она вообще в 70-х застряла, так что нет ничего удивительного что и ООП там в ручную городят вместо поддержки компилятором.

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

Сообщение от CoderHuligan Забыли TCL и его библиотеку TK. Прекрасно всё реализовано без обьектов.

Только вот есть одна ньюанса. То что при пользовании ТК котом делают все нормальные люди уже более 20 лет грызуном расставляют благодаря ООП/КОП . Оно грызуном быстрее раз этак в 20 а то и 50.

0

Сообщение от Fulcrum_013 То что там нет ключевого слова class еще не значит что она не по ООП парадигме сделана.

Оустерхаут был против ООП как таковой, а именно он занимался ТК.

Сообщение от Fulcrum_013 Оно грызуном быстрее раз этак в 20 а то и 50.

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


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

Сообщение от Fulcrum_013 А вообще ООП это такой фоку-покус который позволяет делать очень сложные дела очень простыми методами. Именно за счет того что каждый метод имеет свою четко ограниченную зону ответственности а сами методы четко сгруппированы и разложены по полочкам за кого именно они отвечают.

Это делает модульность

0

Сообщение от CoderHuligan Быстро не значит качественно. На скриптовых языках скорость разработки не меньше благодаря автоматизации рутинных процессов (динамическая память, сборка мусора) причём это возможно без всякого привлечения ооп, а что ещё нужно автоматизировать?

В данном случае значит. Расстановка грызуном позволяет сразу видеть как выглядит форма а не ловить координаты после компиляции и запуска.

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

Сообщение от CoderHuligan Быстро не значит качественно. На скриптовых языках скорость разработки не меньше благодаря автоматизации рутинных процессов (динамическая память, сборка мусора) причём это возможно без всякого привлечения ооп, а что ещё нужно автоматизировать?

В данном случае значит. Расстановка грызуном позволяет сразу видеть как выглядит форма а не ловить координаты после компиляции и запуска.

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

Сообщение от CoderHuligan Это делает модульность

Модульность это первый шаг на пути к ООП. Модуль не может иметь инстансов в отличии от класса.

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

Сообщение от CoderHuligan Оустерхаут был против ООП как таковой, а именно он занимался ТК.

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

0

Сообщение от Fulcrum_013 А вот качественно и толково спроектировать большю систему с ООП гораздо проще чем без него.

Тут необходимо уточнить: Вам проще. А кому-то другому, возможно, проще без ООП.

0

Сообщение от Shamil1 А кому-то другому, возможно, проще без ООП.

но не большую и сложную

0

Сообщение от strategyquest но не большую и сложную

Обоснуйте.

0

Сообщение от Shamil1 Обоснуйте.

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

0

Сообщение от Fulcrum_013 ООП это не какие то фичи компилятора, а в первую очередь методика проектирования

Согласен.

Сообщение от Fulcrum_013 Это уже ООП, только с реализацией без нативной поддержки компилятором.

Не согласен.
Фактически Вы утверждаете, что использование любого пользовательского типа данных - это ООП.

0

Сообщение от Shamil1 Фактически Вы утверждаете, что использование любого пользовательского типа данных - это ООП.

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

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

Добавлено через 13 часов 10 минут

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

Вы верите в эти сказки? Нет там никакой автоматизации работы с динамической памятью. Там есть попытка лечения проблемы висячих указателей путем перевода ее в утечки памяти в наивной надежде что эти утечки небольшие и временные. А реальная автоматизация работы с памятью доступна только в С++.

Добавлено через 11 часов 16 минут

Сообщение от CoderHuligan Видимо мы о разном. Я о табличных методах. И о прямом доступе к ячейкам таблиц, вместо линейного поиска.

Дык вот и я об этом. У VMT доступ прямой. у свича прямой в лучшем случае, в общем логарифмический поиск. А где и зачем там линейный поиск вообще непонятно.

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

Сообщение от CoderHuligan ибо ООП по определению не может создавать код со сложным поведением

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

0

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

Да неужели? В смысле: не нужен больше обьект, но он остаётся в памяти? Но он просто будет занимать память, на которую никто-не будет покушаться, а значит большой проблемы в этом нет.

Сообщение от Fulcrum_013 А реальная автоматизация работы с памятью доступна только в С++.

Да и простой си позволяет управлять динамической памятью достаточно эффективно.

Сообщение от Fulcrum_013 создал объекты, настроил, добавил в модель и забыл.

А то, что типы переплетены как спагетти, ничего?
Например определяем типы:
Благодаря ООП можно не писать:
теперь можно:
Зато типы переплелись.
А если не использовать наследование:
Теперь можно тоже самое:
Вопрос: если всё то же самое, зачем городить огород?

Добавлено через 7 минут
Если без наследования, то тип одного обьекта собран в ОДНОМ месте.

0

Бертран Мейер:
ОО-системы даже в большей степени, чем традиционные системы, за исключением, быть может, Lisp, имеют тенденцию создания большого числа объектов, иногда со сложными взаимозависимостями. Политика, возлагающая на разработчиков ответственность за управление памятью, вредит и эффективности процесса разработки, и безопасности полученной системы. Трудно утилизировать память, занятую более не нужными объектами, усложняются программы, все это требует времени разработчиков, увеличивается риск некорректной обработки областей памяти. В хорошей ОО-среде управление памятью будет автоматическим, под контролем сборщика мусора (garbage collector) - компонента системы периода выполнения (runtime system).

(Бертран Мейер считается ведущим экспертом по ООП)

0

Сообщение от CoderHuligan Да неужели? В смысле: не нужен больше обьект, но он остаётся в памяти? Но он просто будет занимать память, на которую никто-не будет покушаться, а значит большой проблемы в этом нет.

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

Сообщение от CoderHuligan А то, что типы переплетены как спагетти, ничего? Например определяем типы:

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

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

Сообщение от Shamil1 В хорошей ОО-среде управление памятью будет автоматическим, под контролем сборщика мусора (garbage collector)

Идея разумная.

Сообщение от Shamil1 компонента системы периода выполнения (runtime system).

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

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

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

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

0

Сообщение от Fulcrum_013 Это не наследование а композиция.

Один класс наследует поля другого.

Сообщение от Fulcrum_013 Что кстати гораздо лучше чем их отсутствие.

Меньше строчек кода приходится писать? Так в вашем коде этих строчек настолько много из-за ключевых слов, которые никакого отношения к алгоритму не имеют, что выигрыш получается не столь очевидным. Это многочисленные указания компилятору, которые находятся прямо в коде решения задачи, а не в препроцессоре, как по уму положено.
И да, - я против ЛЮБОГО наследования, и ЛЮБОЙ композиции типов.

0

Сообщение от CoderHuligan Один класс наследует поля другого.

В данном случае не наследует а содержит объект типа другого класса.
А наследование выглядит вот так:
Добавлено через 1 минуту

Сообщение от CoderHuligan И да, - я против ЛЮБОГО наследования, и ЛЮБОЙ композиции типов.

НУ в общем вы против программирования вообще. Вы только за быдлокодинг. Необходимость композиции вытекает из необходимости декомпозиции.

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

Сообщение от CoderHuligan Это многочисленные указания компилятору, которые находятся прямо в коде решения задачи, а не в препроцессоре, как по уму положено.

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

0