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

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

5

WH, ООП оправдано всегда.

0

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

0

Сообщение от Fulcrum_013 ООП оправдано всегда.

Только если считать оправданием "я по-другому не умею".

0

CoderHuligan, Ну дак именно ООП и позволяет наращивать абстракции. При этом при правильном проектировании более общая абстракция имеет свойство давать меньшее количество слоев оберток. Вообще ключ к пониманию - ООП это методология проектирования основанная именно на выделении абстрактных сущностей и взаимодействий из предметной области а не ключевое слово class. Кстати так о птичках языков которые реально поддерживают ООП парадигму раз два и обчелся. Без множественного наследования классов возможности построения высокоуровневых абстракций урезаются процентов на 95. При всем при этом, из всех языков поддерживающих множественное наследование классов, универсальным и высокоуровневым является только один - С++.

0

Сообщение от Fulcrum_013 Вообще ключ к пониманию - ООП это методология проектирования основанная именно на выделении абстрактных сущностей и взаимодействий из предметной области а не ключевое слово class.

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

0

CoderHuligan, Абстракции в росте не нуждаются по определению абстракции.

Сообщение от CoderHuligan А вот методы-действия

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

Сообщение от CoderHuligan Вы сами себя посадили за решётку

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

Сообщение от CoderHuligan Наоборот: разработка усложнилась в разы.

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

0

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

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

Сообщение от Fulcrum_013 Для классического же - научного способа проектирования, основанного на математической постановке задачи

Такой способ не работает в реальной жизни. Постановка задачи изменится обязательно. Очень редко бывает так, чтобы программа активно использовалась 10 лет и за эти 10 лет не поменялась (исправление багов не считаем за изменение).

0

Сообщение от Shamil1 Очень редко бывает так, чтобы программа активно использовалась 10 лет и за эти 10 лет не поменялась

Большинство софта не изменялось. И не изменится. Потому что задачи которые они решают не изменяются. Они не могут изменится в следствии неизменности матаппарата описания предметной области задачи.

Сообщение от Shamil1 Все сторонние реализации абстракции (наследники этого абстрактного класса, написанные кем-то другим) стали невалидными.

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

0

Сообщение от WH И напротив, есть ли большие задачи, когда ООП не нужно?

Работа с данными (выгрузка, изменение, загрузка).
Деревья выражений и связанные задачи.

0

Сообщение от Shamil1 Деревья выражений и связанные задачи.

вот где где а здесь ООП рулит на всю катушку.

Сообщение от Shamil1 Работа с данными (выгрузка, изменение, загрузка).

А здесь тем более.

0

Сообщение от Fulcrum_013 С каких делов может понадобится добавлять абстрактный метод?

Доработка функциональности. Новая фича.

Сообщение от Fulcrum_013 Большинство софта не изменялось.

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

0

Сообщение от Shamil1 Доработка функциональности. Новая фича.

При чем тут уже существующие самодостаточные абстракции?

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

Сообщение от Shamil1 Составьте список популярных библиотек для решения различных задач

Какой процент из этих библиотек разработан с использованием ООП парадигмы?

0

Сообщение от Fulcrum_013 самодостаточные абстракции

Где водится такой зверь? Абстракция создаётся под конкретную задачу.

Сообщение от Fulcrum_013 Какой процент из этих библиотек ООП?

Даже если они не ООП, от этого они не перестают быть софтом.

0

Сообщение от Shamil1 Где водится такой зверь? Абстракция создаётся под конкретную задачу.

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

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

Сообщение от Shamil1 от этого они не перестают быть софтом

Но если этот горе-софт не является ООП-софтом, то не надо его головняки приписывать ООП.

0

Сообщение от Fulcrum_013 Но если этот горе-софт не является ООП-софтом, то не надо его головняки приписывать ООП.

Программы меняются. Раньше они делали одно, потом начинают делать другое. Реализация тут не причём. Изменяются требования к программе.

Сообщение от Fulcrum_013 Все операции по добавлению/изменению позиции/удалению/получению информации о позиции и соседях узла не зависят от того что этот узел делает еще.

Как это не зависит? В зависимости от задачи в узле может храниться:
- только список ссылок на детей
- список ссылок на детей и ссылка на родителя
- ссылка на первого ребёнка и ссылка на правого соседа ("брата")
- левый и правый индексы (и никаких ссылок)
- ничего (позиции "родственников" вычисляются по формулам)
Список вариантов можно продолжить.

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

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

0

Сообщение от Shamil1 Предположим, моя программа использует различные геометрические фигуры.

С геометрическими фигурами все немного хитрее. Но в результате все гораздо универсальней. Начинать нужно с построения непротиворечивого языка описания фигур и операции их преобразования. В следствии непротеворечивости языка и набора получится фиксированный набор методов взаимодействия. Ну тут все немного запутано в следствие того что для осуществления операций коллизий и т.д. потребуется двойная диспетчеризация для операций коллизии пересечения и т.д. Но в результате получится набор на века, потому что ограничения выдвигаются самой предметной областью, а не реализацией.
Те же движки твердотельного моделирования живут на своих наборах функционала с середины 90-х и менять его не собираются. Они правда почти поголовно гибриды - аналитически заданные в частных случаях (которое едет с первого поколения САПР - с 60-х) + нурбсы. Некоторые вообще на 100% на нурбсах живут, эти вообще вечные.

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

Сообщение от Shamil1 Список вариантов можно продолжить.

Только во первых это разные типы деревьев.

Сообщение от Shamil1 Как это не зависит? В зависимости от задачи в узле может храниться:

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

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

Сообщение от Shamil1 Изменяются требования к программе.

Требования к программе изменяются только при крутых изменениях в предметной области.

Сообщение от Shamil1 Программы меняются. Раньше они делали одно, потом начинают делать другое. Реализация тут не причём.

Меняются реалии. Раньше IT было уделом исключительно мозговых элит занимающихся серьезными и очень серьезными задачами. Сейчас это на 90% это удел школоты разравнивающей кнопочки в никому не нужных социалочках. Ну естественно у этих 90% знаний не хватает чтобы абстракции выделить. Отсюда и кидания в крайности и вечные изменения.
Но как бы основные 90% работы как делали эти 10% мозговых элит так и делают. Вспомните хотя бы недавний балаган про 300 тыс строк говнокода на ява-скрипте и 5+ человеко-лет на неработающий набор частных псевдорешений, когда универсальное в около 10 тыс строк и человеко-год уложилось на заре эволюции когда оно только эксперементальным все было. А для его набора примитивов там все гораздо проще обойдется.
Кстати шутка что тим-лид это такой человек который за 4 часа может сделать месячную работу всей команды родилась именно в вебдеве. И имеет в своем корне именно то что тим-лид обычно спец с ВО, который в результате глубокого владения ООП может увидеть абстракцию которая в десятки а то и сотни раз сократит потребный код, там где вся команда со школьным образованием и кучей сертификатов, даже не подумает ее искать.

0

Сообщение от Fulcrum_013 С геометрическими фигурами все немного хитрее.

Ничего хитрого. Вы не можете сказать, нужен ли в базовом абстрактном классе метод get_square(), не зная, что делает моя программа с этими фигурами.

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

Если Вам в задаче понадобится какое-нибудь дерево, Вы не будете создавать базовый абстрактный класс Дерево и наследоваться от него. Вы создадите конкретный тип данных. Да, это будет class... но не потому, что Вам требуется ООП для решения этой задачи, а потому, что в С++ нет других способов создать пользовательский тип данных. Это будет конкретный класс, который ни кого не наследует и от которого не планируется ничего наследовать.

Поясню на более простом примере.

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

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

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

Если мы хотим закодировать некий общий алгоритм, например, сортировку, то у нас есть два варианта:

1. Использовать неудобный ООП подход.
То есть, для каждого используемого варианта сортировки написать отдельный класс, инкапсулирующий сравнение элементов (шаблон Стратегия).
Интерфейс метода будет выглядеть примерно так:
public void Sort( IComparer<T> comparer)
Вызов метода будет выглядеть примерно так:
dinosaurs.Sort(new DinoComparer());
Главное неудобство этого подхода не в том, что это несколько лишних строк кода (обычно, в отдельном файле), а в том, что каждый раз, встречая в коде вызов этого метода, придётся отвлекаться на прочтение кода этого класса, чтобы понять/вспомнить, как именно он сравнивает.

2. Использовать удобный ФП подход.
Алгоритм принимает функцию сравнения в качестве параметра.
Интерфейс метода будет выглядеть примерно так:
public void Sort( Comparison<T> comparison)
Вызов метода будет выглядеть примерно так:
dinosaurs.Sort((x,y) => x.Weight < y.Weight);
Во-первых, сразу понятно, как мы сравниваем. Во-вторых, не нужно писать лишние классы.

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

Вот, например, GCC за последний год вышло 5 новых релизных версий. 3 из них 7.х. Язык С++, вроде, за последний год не изменился.
Программы типа 1С постоянно приходится дорабатывать. Причём, некоторые изменения "ломают" основы. Например, введение НДС (для каждой позиции в счёте кроме цены/количества теперь нужно хранить сумму НДС - без добавления нового поля в таблицу не обойтись).
А как изменились со времён Wolf3D требования к 3D движкам?
С узкоспециализированными программами ещё сложнее. Сначала Заказчик говорит "хочу так". Когда это написано и можно попробовать, он говорит "нет, так неудобно, нужно сделать вот так". Через полгода использования он говорит "а давайте добавим ещё вот такую фичу". Причём, эта новая фича может потребовать перестройку ядра системы, потому что изначально в систему не была заложена принципиальная возможность подобных изменений.

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

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

0

Сообщение от Shamil1 Программы типа 1С постоянно приходится дорабатывать. Причём, некоторые изменения "ломают" основы. Например, введение НДС (для каждой позиции в счёте кроме цены/количества теперь нужно хранить сумму НДС - без добавления нового поля в таблицу не обойтись).

Ваши познания в 1С меня пугают

Сообщение от Shamil1 Сначала Заказчик говорит "хочу так". Когда это написано и можно попробовать, он говорит "нет, так неудобно, нужно сделать вот так". Через полгода использования он говорит "а давайте добавим ещё вот такую фичу". Причём, эта новая фича может потребовать перестройку ядра системы, потому что изначально в систему не была заложена принципиальная возможность подобных изменений.

Да, примерно так, или, если хотите, "именно так". И что? Существует ли какая-то "волшебная палочка" для быстрого рефакторинга и/или добавления новых фич? Думаю что нет. Изменение базовой "сущности" неминуемо влечет за собой серьезные переделки, вопрос лишь в том насколько они болезненны. Всегда можно сказать типа "ах, козлы, не подумали о расширении системы!", но человек способный предугадать все на свете еще не родился. Более того, писать имея ввиду возможные изменения - палка о двух концах.

1

Сообщение от Igor3D Да, примерно так, или, если хотите, "именно так". И что? Существует ли какая-то "волшебная палочка" для быстрого рефакторинга и/или добавления новых фич? Думаю что нет. Изменение базовой "сущности" неминуемо влечет за собой серьезные переделки, вопрос лишь в том насколько они болезненны.

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

Сообщение от Igor3D Более того, писать имея ввиду возможные изменения - палка о двух концах.

Согласен. Излишняя (невостребованная) гибкость ИМХО даже хуже, чем преждевременная оптимизация.
Любую проблему можно решить добавлением ещё одного уровня абстракции... кроме проблемы слишком большого количества уровней абстракции .

Сообщение от Igor3D Ваши познания в 1С меня пугают

Довелось принимать участие в написании систем управления предприятием... один раз даже в роли аналитика. Так что пришлось получить диплом бухгалтера . 1С - это ещё цветочки по сравнению с Equation, которая для IBM iSeries AS/400.

0

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

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

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

Сообщение от Shamil1 Вы не будете создавать базовый абстрактный класс Дерево и наследоваться от него

Буду. Причины очевидны.

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

Сообщение от Shamil1 А как изменились со времён Wolf3D требования к 3D движкам?

Качественно - чуть менее чем никак. Только количественно. Вообще архитектура современных движков полностью присутствует даже в первой компутерной игре. Весь тот же набор подсистем.

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

Сообщение от Shamil1 С узкоспециализированными программами ещё сложнее

Ускоспециализированные программы - нонсенс. Либо программа предназначена для универсального решения набора задач своего класса либо, это сапоги в смятку.

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

Сообщение от Shamil1 Во-первых, сразу понятно, как мы сравниваем.

В главных если используем сравнение в нескольких местах ФП подход неизбежно превращается в говнокод.

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

Сообщение от Shamil1 Есть абстракции неуниверсальные

С каких дел они неуниверсальные? Просто смотреть глубже надо. Они разбираются на набор состовляющих примитивов, а сам документ/фигура и т.п. в результате сразу же превращается в универсальную абстрактную сущность, которая пригодна к декларативному конструированию и параметризации. Если воззьмем область документов то результат такого подхода - DOM.

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

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

Исключительно при наличии подходящей структуры данных у этого взятого типа. Но и в С++ так никто не запрещал.

Сообщение от Shamil1 А, например, в Haskell можно определить класс типов (здесь "класс" — термин, употребляемый в теории множеств для обозначения произвольных совокупностей множеств, обладающих каким-либо определенным свойством или признаком). А затем закодировать произвольный алгоритм для этого класса типов.

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

0