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

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

5

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

Нет. ООП — это SOLID.

1

Сообщение от TRam_ Первое можно приближённо представить в виде нарисовать(квадрат, способ_рисования_квадрата() ), стереть(круг, способ_стирания_круга()) и т.п. Причём функция "способа" объявляется не где-то там в массиве возможных способов (массиве указателей на функции), а непосредственно в блоке бывшей структуры, а ныне - класса. С возможностью автоматически перенаправлять на аналогичные по действию функции, написанные для подобных объектов.

Так это можно и без ооп сделать.

Сообщение от TRam_ В ООП реализация непосредственно встраивается в суть аргумента, в то время как без ООП аргумент и реализация существуют независимо.

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

Сообщение от korvin_ Обычной программирование, управляемое данными.

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

0

Сообщение от CoderHuligan А без этого программа становится "глупая" и соответственно "тормознутая"

Только в твоих влажных фантазиях.

0

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

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

1

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

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

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

Сообщение от CoderHuligan Короче - без их тормозов.

Каких тормозов? Инстанс все равно придется инициализировать и финализировать. Потратить на это тактов меньше чем нужно все равно не удастся. Ну а что касается сказок о тормознутости виртуальщины, то в общем случае виртуальщина быстрее свича. В лучшем для свича случае одинакова со свичем. При этом локальность данных при размере инстанса больше 32 байт до одного места, при размере более 64 байт вообще никакой рояли не играет, это даже если не брать во внимание вангователь предкеширования. А вот локальность машинного кота размер играет и еще какой. Если кот полностью в L2 влазит в следствие виртуальщины то мышей ловить будет. А жирный кот статического полиморфизма как раз и будет тормозить при переходах. Напомню любой long jump сбрасывает L1. Соответсвенно ожирение машинного кота путем комбинаторного взрыва к которому ведет статический полиморфизм и дает тормознутость.

0

Сообщение от Fulcrum_013 процедурное/функциональное программирование - это программирование с абсолютным отсутствием какой либо методики.

Есть автоматное программирование, например. Что касается функционального,, то есть методология, которая основана на алгорифмах Маркова(язык Рефал).

Сообщение от Fulcrum_013 Ну а что касается сказок о тормознутости виртуальщины, то в общем случае виртуальщина быстрее свича.

Можно(и нужно) обойтись и без свича. А если так то мой код улетит в космос...

0

Сообщение от CoderHuligan Можно(и нужно) обойтись и без свича. А если так то мой код улетит в космос...

Indirect call будет в любом случае. Тормознутым считается не сам Indirect Call а vmt lookup. Но какой либо lookup всер равно будет, без него indirect call не имеет смысла. При этом VMT достаточно компактны чтобы полностью жить в кеше. При инстансах же больше 32 байт локальность данных самих инстансов уже никакого значения не имеет.

Сообщение от CoderHuligan Есть автоматное программирование, например.

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

0

Сообщение от Fulcrum_013 Но какой либо lookup всер равно будет, без него indirect call не имеет смысла.

Вот от этого lookupа, можно(и нужно) избавляться. Никакого lookupа быть не должно. Нигде. Никогда.. Примем за цель.

Сообщение от Fulcrum_013 Ото точно тормоза без виртуальщины будут.

Ну, да, ну да...

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

Любая программа ЯВНО использует понятие СОСТОЯНИЕ? Как ПАРАМЕТР? Отнюдь нет, отвечу я за вас.
А автоматное использует этот параметр, как основу, на которой зиждется вся структура программы. И таковая абстрактная сущность, я вам скажу, гораздо ближе к реальному миру, чем мышление в терминах обьектов.

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

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

0

Сообщение от CoderHuligan реализующая конечный автомат есть ваше ооп?

Гради Буч "Object-Oriented Analysis and Design with Application". Объекты могут быть реализованы через конечные автоматы.

Сообщение от CoderHuligan как состояние

Объект состоит из состояния и поведения.

0

Сообщение от CoderHuligan Вот от этого lookupа, можно(и нужно) избавляться. Никакого lookupа быть не должно. Нигде. Никогда.. Примем за цель.

Будет жирный жирный невменяемо запутанный кот. Кстати так о птичках даже свич через lookup работает.

Сообщение от CoderHuligan Чушь, ибо, отсутствует явное определения такой абстрактной вещи, как состояние. А без этого любая таблица есть просто набор данных.

НАбор переходов это тоже набор данных. Кстати в соответствии со вторым принципом фон Неймана в общем то код и данные не имеют между собой никакой разницы.

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

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

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

Сообщение от CoderHuligan Любая программа ЯВНО использует понятие СОСТОЯНИЕ?

Любая. Хотя бы потому что CPU это конечный автомат с состояниями которого программа работает. Вообще CPU это фактически УМТ а программа это правила специализированной МТ.

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

Сообщение от Dmitriy_M Объект состоит из состояния и поведения.

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

0

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

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

0

Сообщение от Dmitriy_M Гради Буч "Object-Oriented Analysis and Design with Application". Объекты могут быть реализованы через конечные автоматы.

Да я в курсе, книжка имеецца.. Просто почти НИКТО их не реализует через КА.

Сообщение от Dmitriy_M Объект состоит из состояния и поведения.

Автомат состоит из состоянИЙ и переходов между ними. Поведение реализуется внешним интерфейсом автомата. Обьекты могут быть реализованы как автоматы, но это всё не то..

Сообщение от Fulcrum_013 Будет жирный жирный невменяемо запутанный кот. Кстати так о птичках даже свич через lookup работает.

Видимо мы о разном. Я о табличных методах. И о прямом доступе к ячейкам таблиц, вместо линейного поиска. См. книжку "С.Макконелл. Совершенный код", где логика реализуется путём прямого обращения к ячейкам таблиц. Так кстати, работают сами процесоры, микропрограммы которых зашиты в логическую матрицу. Вобоще, слово МАТРИЦА мне что-то навевает такое по настоящему виртуальное, компьютерное...

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

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

0

Сообщение от Dmitriy_M Гради Буч "Object-Oriented Analysis and Design with Application". Объекты могут быть реализованы через конечные автоматы.

он ошибся.

0

Сообщение от strategyquest Во первых, переходы не только в объекте, но и в среде, во вторых изменения могут быть недетерминированы(например -- время имеет значение)

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

0

Сообщение от Fulcrum_013 Любая. Хотя бы потому что CPU это конечный автомат с состояниями которого программа работает.

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

0

Сообщение от strategyquest он ошибся.

Нет, oн абсолютно прав. Потому что CPU это конечный автомат.

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

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

Программисту явно нужны только те состояния которые он обрабатывает явно. Иначе будет каша.

0

Fulcrum_013, в автомате вообще нет времени в обычном понимании, там за единицу времени берется шаг вычисления(такт), это "время" ортогонально внешнему. Там нет времени, а следовательно, нет и временного арбитража

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

Сообщение от Fulcrum_013 Нет, oн абсолютно прав

https://en.wikipedia.org/wiki/... omputation
https://en.wikipedia.org/wiki/... eterminism

0

Сообщение от CoderHuligan Но ведь, можно распределять функции не по классам, а по модулям, имеющим внутреннюю логическую связность.

ООП не только группировкой функций занимается но и группировкой данных. Если для реализации автомата нужно несколько копий какого либо подавтомата то без ООП становится тяжко.
Ну а вообще представте такую широко распространенную задачу. Имеется автомат умеющий обрабатывать данные в алфавите A. Но данные имеются в алфавитах B,C,D,E и т.д. Как их обработать исходным автоматом добавляя минимум состояний? Очевидно что для этого необходимо сделать набор автоматов для B,C,D,E с системой переходов между состояниями аналогичными A но выполняющими их для алфавитов B,C,D,E, и кждому набору данных добавить состояние каким именно автоматом-обработчиком их обрабатывать. Именно эту задачу и решает ООП

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

Сообщение от strategyquest в автомате вообще нет времени в обычном понимании,

Автомат в сферическом вакууме (без привязки к реальному времени) вообще штука бессмысленная.

Сообщение от strategyquest там за единицу времени берется шаг вычисления(такт),

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

0

Сообщение от Fulcrum_013 Автомат в сферическом вакууме (без привязки к реальному времени) вообще штука бессмысленная.

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

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

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

Это Вы уже про какую то изобретенную лично Вами систему автоматов, мне тут нечего возразить

0

Сообщение от Fulcrum_013 Ну а вообще представте такую широко распространенную задачу. Имеется автомат умеющий обрабатывать данные в алфавите A. Но данные имеются в алфавитах B,C,D,E и т.д. Как их обработать исходным автоматом добавляя минимум состояний?

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

0