Что даёт использование классов (и шире - ООП) в языке программирования С++? - Священные войны - Страница 7

@Avazart · 19.08.2016, 14:34

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

Я хз что вы имеете ввиду и при чем тут ООП.
Очевидно что Bullet.draw() будет вызываться "не изнутри себя самого" а в каком-то OnPaint с остальными объектами причем внутри beginPaint/endPaint

Я уже не говорю что drawCircle может как-то оптимизировать прорисовку.

@Voivoid · 19.08.2016, 14:36

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

И вот это и есть волшебная инкапсуляция и победа?

Я вообще без понятия что ты тут имеешь в виду. Даже не буду гадать. Но вот в твоем коде на haskell'е нет никакой инкапсуляции, поэтому textstate можно изменить таким образом, что текст изменится, а команда на undo добавлена не будет. Как решить эту проблему в haskell'е ?

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

А если каждая пуля будет рисовать сама себя, у нас графика не будет тормозить?

А с чего бы она должна начать тормозить?

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

х, надо выносить рисование в контроллер и делать MVP-архитектуру, говорите?

Не в контроллер, а во view. Можно выносить, а можно в общем-то и не выносить. Надо смотреть по обстоятельствам, снизит ли это сложность систем

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

И критику ООП от того же Степанова мы считаем глупостью?

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

@_stanislav · 19.08.2016, 14:40

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

А если каждая пуля будет рисовать сама себя, у нас графика не будет тормозить?

Она только логически сама себя рисует, физически все совсем по другому происходит.

@_Ivana · 19.08.2016, 14:45

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

Как решить эту проблему в haskell'е ?

В haskell можно вынести отдельный функционал в отдельный модуль, в котором определять что будет экспортироваться, а что не будет - если стоит параноидальная задача обезопасить состояние структур от некорректного изменения глупым программистом. Много стандартных библиотечных пакетов так и делают. Data.Map, к примеру, именно так и скрывает реализацию, вынося только публичное АПИ.

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

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

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

@Avazart · 19.08.2016, 14:48

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

можно вынести отдельный функционал в отдельный модуль

Думаю этого недостаточно при больших объемах.

@_Ivana · 19.08.2016, 14:51

Почему? Насколько я знаю, в той же джаве (не знаю как в плюсах) принята традиция (и сама ИДЕ это навязывает) писать каждый класс в отдельном файле, и также задавать имя файла именем класса. То есть полностью то же самое.

@Voivoid · 19.08.2016, 14:51

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

а где, в каких областях ООП то и нужен особо?

Там, где нужна и инкапсюлация и полиморфизм и наследование. Степанову для своих задач хватало инкапсуляции и полиморфизама, поэтому ему ООП был не нужен

@_stanislav · 19.08.2016, 14:54

Сообщение от Mr.X

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

По сути если проект не большой все просто - максимальная декомпозиция но не нарушая GRASP.

@_Ivana · 19.08.2016, 14:55

У меня такое ощущение, что мне для моих задач тоже не нужно наследование. К тому же, 4 бандита тоже рекомендуют его не использовать. А инкапсуляция с полиморфизмом в каждой аптеке уже есть (в том же haskell). Так получается, что по теме - ООП дает только наследование, которое по возможности нужно избегать, и которое требуется в 1% задач?

(trollface)

@avgoor · 19.08.2016, 14:56

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

а где, в каких областях ООП то и нужен особо?

Не так вопрос ставите. Один и тот же результат можно получить разными подходами (вплоть до hex-редактора). Поэтому вопрос должен звучать так: "В каких задачах ООП подход замедлит разработку, и что, в таком случае, ее ускорит?"

@_stanislav · 19.08.2016, 14:59

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

Степанову для своих задач хватало инкапсуляции и полиморфизама, поэтому ему ООП был не нужен

А если бы понадобилось наследование то без ООП не обойтись? Если Степанов справлялся без ООП при нужде инкапсуляции и полиморфизма, неужели он бы и наследование не синтезировал?

@Avazart · 19.08.2016, 15:05

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

К тому же, 4 бандита тоже рекомендуют его не использовать.

Ссылку можно?

@_stanislav · 19.08.2016, 15:05

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

У меня такое ощущение, что мне для моих задач тоже не нужно наследование. К тому же, 4 бандита тоже рекомендуют его не использовать. А инкапсуляция с полиморфизмом в каждой аптеке уже есть (в том же haskell). Так получается, что по теме - ООП дает только наследование, которое по возможности нужно избегать, и которое требуется в 1% задач? (trollface)

Функциональный язык не может быть объектно ориентированным тоже?

@avgoor · 19.08.2016, 15:05

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

А если бы понадобилось наследование то без ООП не обойтись? Если Степанов справлялся без ООП при нужде инкапсуляции и полиморфизма, неужели он бы и наследование не синтезировал?

...

@Voivoid · 19.08.2016, 15:06

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

А если бы понадобилось наследование то без ООП не обойтись?

Ну, можешь посмотреть как на сишечке ООП эмулируют. Получается что-то близкое по духу к Франкенштейну

@_Ivana · 19.08.2016, 15:06

И это еще если не вспоминать про основной вопрос философии - "что такое ООП"

А то почитав Алана Кея, можно прийти к выводу, что тот же Лисп или Эрланг на порядок оопее того же С++, а ООП - это не 3 известных ~~кита~~ слова, а совсем другое.

@Voivoid · 19.08.2016, 15:11

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

А то почитав Алана Кея, можно прийти к выводу, что тот же Лисп или Эрланг на порядок оопее того же С++

Ну и в чем принципиальные отличия? Ну, кроме того, что everything is an object

@_stanislav · 19.08.2016, 15:12

У меня все же мнение, что первопричина ООП парадигмы это структурировать код более высоким уровнем нежели функции. Упаковать данные и функции в объект. Наследование полиморфизм инкапсуляция это уже все потом.

@_Ivana · 19.08.2016, 15:18

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

Функциональный язык не может быть объектно ориентированным тоже?

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

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

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

Ну и в чем принципиальные отличия?

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

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

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

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

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

@Avazart · 19.08.2016, 15:26

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

Добро пожаловать в модули

Модули это высокоуровневое средство?

Новые блоги и статьи Все статьи Все блоги /
Сегодня суббота, 22.08.2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. zorxor 22.08.2026 Сегодня суббота, 22. 08. 2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. Кто Я, откуда Я пришел и куда Я иду? Эти вопросы не оставляют меня ни на секунду. Жизнь на планете Земля. . .	Жизня: рисунок укладки багажа, сделанный клодом anaschu 21.08.2026 Сделал 15 снимков, он по снимкам сделал схему.	Был там один разговор по поводу свободы в материальном мире. kumehtar 19.08.2026 Суть: рассматривается живое существо, оказавшееся внутри довольно странной системы (этого мира) и пытающееся обустроить в ней свой кусок пространства. Жизнь действительно предъявляет каждому. . .	Когда логика программы не спасает от человеческих ошибок Maks 18.08.2026 В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .
Лето уходит kumehtar 17.08.2026	Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .	Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .

@Avazart 8489 / 6156 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	19.08.2016, 14:34
	Я хз что вы имеете ввиду и при чем тут ООП. Очевидно что Bullet.draw() будет вызываться "не изнутри себя самого" а в каком-то OnPaint с остальными объектами причем внутри beginPaint/endPaint Я уже не говорю что drawCircle может как-то оптимизировать прорисовку. 0

@_Ivana 4949 / 2289 / 287 Регистрация: 01.03.2013 Сообщений: 5,991 Записей в блоге: 32
	19.08.2016, 14:51
	Почему? Насколько я знаю, в той же джаве (не знаю как в плюсах) принята традиция (и сама ИДЕ это навязывает) писать каждый класс в отдельном файле, и также задавать имя файла именем класса. То есть полностью то же самое. 0

@_Ivana 4949 / 2289 / 287 Регистрация: 01.03.2013 Сообщений: 5,991 Записей в блоге: 32
	19.08.2016, 14:55
	У меня такое ощущение, что мне для моих задач тоже не нужно наследование. К тому же, 4 бандита тоже рекомендуют его не использовать. А инкапсуляция с полиморфизмом в каждой аптеке уже есть (в том же haskell). Так получается, что по теме - ООП дает только наследование, которое по возможности нужно избегать, и которое требуется в 1% задач? (trollface) 0

@_Ivana 4949 / 2289 / 287 Регистрация: 01.03.2013 Сообщений: 5,991 Записей в блоге: 32
	19.08.2016, 15:06
	И это еще если не вспоминать про основной вопрос философии - "что такое ООП" А то почитав Алана Кея, можно прийти к выводу, что тот же Лисп или Эрланг на порядок оопее того же С++, а ООП - это не 3 известных ~~кита~~ слова, а совсем другое. 0

@_stanislav "C with Classes" 2022 / 1404 / 523 Регистрация: 16.08.2014 Сообщений: 5,885 Записей в блоге: 1
	19.08.2016, 15:12
	У меня все же мнение, что первопричина ООП парадигмы это структурировать код более высоким уровнем нежели функции. Упаковать данные и функции в объект. Наследование полиморфизм инкапсуляция это уже все потом. 0