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

@@KOT@ · Регистрация: 29.01.2010

Студворк — интернет-сервис помощи студентам

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

@Shamil1 · 07.08.2016, 18:56

Очень часто иерархия данных отличается от иерархии действий над ними. Поэтому классическое ООП в виде "поместим в один класс данные и действия над ними" плохо подходит. Но можно всё-равно использовать ООП, если разнести данные и действия по разным классам.
Данные без методов - это структуры. Есть и почти во всех ЯП. А действия - это тоже данные, только другого типа. Поэтому часто нет большой разницы использовать ООП или нет.

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

Сообщение от snake32

Я не знаю как там дела обстоят в Яве, но на делфях, да и в с++ достаточно было сделать метод add виртуальным и только его перегрузить в наследнике. Тогда бы и ошибки не было.

Нет.
Это зависит от того, как написаны методы add и addAll. Например, можно написать метод addInternal и вызывать его в обоих методах add и addAll. Тогда перегрузка add не будет влиять на работу addAll.

@snake32 · 07.08.2016, 20:21

Сообщение от Shamil1

Нет.
Это зависит от того, как написаны методы add и addAll.

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

@Shamil1 · 10.08.2016, 09:50

Сообщение от _Ivana

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

ООП без наследования - это КОП (компонент-ориентированное программирование). И классы при таком подходе ничем не отличаются от модулей.

@Fulcrum_013 · 14.08.2016, 11:15

Сообщение от Shamil1

ООП без наследования - это КОП (компонент-ориентированное программирование).

Щаз без наследования. Если оно там реализовано не совсем так то это не значит что его там нет. Просто агрегация классов динамическая а не статическая.

@Shamil1 · 14.08.2016, 17:24

Сообщение от Fulcrum_013

Щаз без наследования. Если оно там реализовано не совсем так то это не значит что его там нет. Просто агрегация классов динамическая а не статическая.

Агрегация - это не наследование.

@Fulcrum_013 · 14.08.2016, 17:36

Сообщение от Shamil1

Агрегация - это не наследование

имеется в виду агрегация виртуальных методов. В реализации ООП в С++ агрегация VMT статическая. В КОП динамическая. Эти два подхода кстати можно прекрасно сочетать

Сообщение от Shamil1

Агрегация - это не наследование.

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

@Shamil1 · 14.08.2016, 18:17

Сообщение от Fulcrum_013

имеется в виду агрегация виртуальных методов. В реализации ООП в С++ агрегация VMT статическая. В КОП динамическая.

Вы говорите на каком-то другом языке, поэтому я не понимаю Вашей терминологии. И судя по Вашему ответу, Вы не понимаете, о чём говорю я.

В частности, как мне сообщил Гугл, Вы - единственный человек в интернете, который использует термин "агрегация виртуальных методов". Откуда мне знать, что это такое?
Что такое "агрегация таблиц виртуальных методов в с++" я даже представить себе не могу. И я уверен на 90%, что под термином "компонент-ориентированное программирование" Вы тоже понимаете что-нибудь своё.

Сообщение от Fulcrum_013

А если подразумеваете под агрегацией оборачивание методов приватных полей типов функциональность которых расширяется

Под "агрегацией" я подразумеваю "агрегацию" и ничего другого (один компонент/класс включается в другой компонент/класс). В КОП нет ни полей, ни типов.

Сообщение от Fulcrum_013

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

Какое отношение Всё это имеет к моему утверждению "агрегация - это не наследование"?

Сообщение от Fulcrum_013

Просто абстракции надо уметь выделять и по полочкам раскладывать правильно.

Согласен, это нужно уметь.

@Fulcrum_013 · 14.08.2016, 18:43

Сообщение от Shamil1

Под "агрегацией" я подразумеваю "агрегацию" и ничего другого (один компонент/класс включается в другой компонент/класс).

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

Сообщение от Shamil1

"агрегация - это не наследование"

Наследование это не только

C++
1
class Derived:public Base

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

Сообщение от Shamil1

В КОП нет ни полей, ни типов.

Есть интерфейсы и свойства. но это всего лишь детали реализации динамического связывания и не более.

@Shamil1 · 14.08.2016, 19:19

Сообщение от Fulcrum_013

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

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

@Fulcrum_013 · 14.08.2016, 19:24

Сообщение от Shamil1

я в использовал термин "наследование" в общепринятом в информатике смысле

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

@asmquest · 08.02.2017, 19:23

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

@Shamil1 · 08.02.2017, 21:47

Сообщение от asmquest

Можете привести пример, когда это не так, и когда это обоснованно?

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

@asmquest · 08.02.2017, 21:53

Shamil1,

Сообщение от Shamil1

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

Нет, мне реально интересно, может ли такое дать реальный профит хоть в чем нибудь. Я не настаиваю на своем утверждении, возможно ошибаюсь.

Сообщение от Shamil1

Вот и сейчас Вы написали "специализация", и бесполезно пытаться угадывать, что Вы под этим подразумеваете.

Этот термин не может трактоваться по-разному, он однозначен.

@Shamil1 · 08.02.2017, 22:24

Сообщение от asmquest

мне реально интересно, может ли такое

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

Сообщение от asmquest

Этот термин не может трактоваться по-разному, он однозначен.

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

@asmquest · 08.02.2017, 22:37

Shamil1, как обычно, Вы не отвечаете за свои слова, ясно.

@Shamil1 · 08.02.2017, 22:48

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

@asmquest · 08.02.2017, 23:01

Shamil1, да, если кто-то заявляет что-то вроде: "цианистый калий полезен для здоровья", тут трудно найти контраргумент

@Shamil1 · 08.02.2017, 23:09

Сообщение от asmquest

тут трудно найти контраргумент

Очевидные вещи называются очевидными именно потому, что они очень легко доказываются.

@asmquest · 08.02.2017, 23:13

Сообщение от Shamil1

Очевидные вещи называются очевидными именно потому, что они очень легко доказываются.

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

Evg · 09.02.2017, 12:50

Не по теме:

asmquest, а ты попробуй создай отдельную тему с каким-нибудь вопросом по Си++ (или ООП), в котором бы фигурировал термин "специализация класса". А далее по количеству вопросов вида "что ты имел в виду под специализацией класса" оценивай свою правоту

Результаты опроса: используете ли вы ооп
да	238	86.55%
нет	37	13.45%
Голосовавшие: 275. Вы ещё не голосовали в этом опросе

Новые блоги и статьи Все статьи Все блоги /
Был праздник вчера, а я и не знал. kumehtar 28.07.2026 27. 07. 2026г. Intel Core 2 Duo исполнилось 20 лет Новости компьютерного мира и их обсуждение (4) Салют, шампанское, овации! :drink:	Нейтральные знания, чистый код - бла-бла-бла-бла, на самом деле кликбейт и самореклама, плагиат, и вот почему Hrethgir 27.07.2026 То-есть отклонение такой публикации говорит само за себя, и пусть только возьмут на вооружение после отклонения публикации - это будет чистейшим актом плагиата. Отклонял Хабр. Дословно, отклонённая. . .	тв 16 бой ии anaschu 27.07.2026 Великий Перелом ИИ: Как уравнения ОДУ Radau дожали цензурные фильтры Алисы Фиксируем в мемофонде Теории Всего беспрецедентный факт в истории ИИ-зондирования. В затяжном многораундовом. . .	мв 15. непроверенное, возможно, глюк anaschu 27.07.2026 НАУЧНО-АНАЛИТИЧЕСКИЙ ОТЧЕТ. РАЗДЕЛ 1. 1: «НАУКА» (РАСШИРЕННАЯ СТЕХИОМЕТРИЧЕСКАЯ И ГЕНЕТИЧЕСКАЯ ВЕРСИЯ)Тема: Теоретическое обоснование инвариантности 19-мерного тензорного ядра непрерывных ОДУ и. . .
Очистка реквизитов и табличных частей документа при копировании (вариант 2) Maks 26.07.2026 Алгоритм из решения ниже разработан на примере нетипового документа "ЗаявкаНаРаботу", разработанного в КА2. Задача: Заменить алгоритм запрета копирования документов для сотрудников с ролью "Стажер",. . .	Доктрина интенционального знания - Доктрина для портала "Срез". Hrethgir 25.07.2026 Может найдётся кто захочет оценить доктрину. . . Написания правил участия для меня роскошь, требующая лимита времени, поэтому все сообщения не прошедшие модерацию будут видны только участникам портала,. . .	сукцессия 44. Решил подать на припринт в межународные сервисы препринтов. Но нужно одобрение от ученых anaschu 25.07.2026 Английский вариант. Пока кто то не одобрит мою личность, мне не получиться это опубликовать на препринте. Но заявку на публикацию статьи я сегодня подам.	сукцессия 43. Вторая научная статья за месяц- прайминг и гатгил anaschu 25.07.2026 две стороны одной монеты

@@KOT@ 81 / 39 / 3 Регистрация: 29.01.2010 Сообщений: 386

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

@asmquest Заблокирован
	08.02.2017, 19:23
	Shamil1, Вам все верно указали. Это не терминологические разногласия, что-то Вы чуть что сразу за эту мантру прячетесь. Подкласс -- специализация надкласса, иначе у Вас не классы, а говнокод. Например, женщина -- специализация класса человек. Иерархия выстраивается от общего к частному. Можете привести пример, когда это не так, и когда это обоснованно? 0

@asmquest Заблокирован
	08.02.2017, 22:37
	Shamil1, как обычно, Вы не отвечаете за свои слова, ясно. 0

@Shamil1 Модератор 3140 / 2288 / 469 Регистрация: 26.03.2015 Сообщений: 8,898
	08.02.2017, 22:48
	asmquest, Вы не привели ни одного аргумента против того, что я написал. А если Вам просто не с кем поговорить, то решайте эту проблему без моего участия. 0

@asmquest Заблокирован
	08.02.2017, 23:01
	Shamil1, да, если кто-то заявляет что-то вроде: "цианистый калий полезен для здоровья", тут трудно найти контраргумент 0

Evg
	09.02.2017, 12:50
	Не по теме: asmquest, а ты попробуй создай отдельную тему с каким-нибудь вопросом по Си++ (или ООП), в котором бы фигурировал термин "специализация класса". А далее по количеству вопросов вида "что ты имел в виду под специализацией класса" оценивай свою правоту 0