Войти
ФлеймФорумПрограммирование

Вопрос по ООП (2 стр)

Страницы: 1 2 3 417 Следующая »
#15
9:52, 16 дек. 2019

Dmitry_Milk

Не понял к чему вы клоните.
В noname Bar.field1 == undefined


#16
(Правка: 9:59) 9:59, 16 дек. 2019

NetSpider
> триггер
По логике выше получается, что "триггер" ООП - это virtual override; тогда как "триггер" процедурки - это switch (objectType).

#17
9:59, 16 дек. 2019

NetSpider
> В noname Bar.field1 == undefined

Тогда какое же он может быть ООП, если в нем нет вообще никаких объектов/структур, хоть ООП-ных, хоть не ООП-ных?

#18
10:08, 16 дек. 2019

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

+ Показать

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

Обрати внимание, что способ применения извне тут ни при чём - для обоих вариантов внешний код будет одинаковым:
+ Показать

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

#19
(Правка: 10:19) 10:14, 16 дек. 2019

Dmitry_Milk

Тогда какое же он может быть ООП, если в нем нет вообще никаких объектов/структур, хоть ООП-ных, хоть не ООП-ных?

Абсолютно так, приведенный в стартовом сообщение пример не является ООП, и изначально noname и не был ООП языком.
Из этого можно сделать вывод, что если код визуально обладает признаками ООП, то это не значит что он является ООП. Но в этом утверждении есть одна заложенная мина: является ли ООП настоящей парадигмой или это просто метод процедурного программирования.

Delfigamer

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

Вы меня наверное специально троллите. Вики:

Мо́дульное программи́рование — это организация программы как совокупности небольших независимых блоков, называемых модулями, структура и поведение которых подчиняются определённым правилам
#20
(Правка: 10:56) 10:54, 16 дек. 2019

NetSpider
>> Один объект может быть ООП если от клиентского кода всё-таки спрятано чем он
>> конкретно является и выбор возможен в рантайме (динамическая диспетчеризация).

> Функция тоже прячет внутренний код, имеет недоступные локальные переменные

Нет нет нет. Аналогия неверна.
Здесь речь вот о чём: то что внутри функции "спрятано" от клиентского кода чем именно она занимается и как внутри устроена - это одно (это больше кивок в сторону инкапсуляции).
Но вот когда от клиентского кода спрятано какую именно функцию он вызывает - это вот правильная аналогия того о чём говорю я.

> Вики:
> Полиморфизм в языках программирования и теории типов
Ну и дальше, дальше читаем же:

Полноценная поддержка объектно-ориентированного программирования предполагает включение в число полей записей также функций, обрабатывающих значения типов записей, которым они принадлежат[29][35]. Такие функции традиционно называются «методами».

И что?

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

#21
11:02, 16 дек. 2019

NetSpider
> является ли ООП настоящей парадигмой или это просто метод процедурного
> программирования.

Это развитие идей процедурного программирования когда внутрь структуры положили УКАЗАТЕЛЬ на функцию с ней работающий - т.е. создали динамический полиморфизм.
Да, это ответ.

#22
(Правка: 11:10) 11:05, 16 дек. 2019
Код в котором есть структуры с процедурами не превращается магически в ООП только от того если имена процедур упрятать в нейспейсы структур. Это всего лишь синтаксический сахар, а синтаксический сахар не создаёт новых идиом.

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

Пока писал ответ, =A=L=X= опередил. Вот и мысли и сошлись

=A=L=X=

внутрь структуры положили УКАЗАТЕЛЬ на функцию с ней работающий - т.е. создали динамический полиморфизм

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

#23
(Правка: 11:20) 11:19, 16 дек. 2019

NetSpider
> Структура с указателем - это парадигма.

Ну парадигма тут не сама структура с указателем, а то что мы создали изоляцию которая позволяет писать код с чем то работающий и заранее не знающий с чем конкретно он работает - есть только некий "шлюз" или по привычному - интерфейс, через который происходит взаимодействие с чем то, а с чем именно мы заранее не знаем. Знаем только, что таким объектам можно приказать "нарисуй себя" - и квадрат нарисуется как квадрат, а круг нарисуется как круг, но клиентский код ничего об этом не знает.
В функцию работающую с FILE * можно передать только FILE * - это процедурщина.
Но в функцию работающую со AbstractStream можно передать как FileStream так и SocketStream или даже MemoryStream - это и есть ООП.
Это и есть суть ООП и единственная важная его разница с процедурным программированием.
А всё остальное - досужие рассуждения вокруг да около которые только замыливают этот факт.

#24
(Правка: 11:32) 11:32, 16 дек. 2019

Причём, что немаловажно - то как осуществляется динамическая диспетчеризация по сути тоже неважно.
В JavaScript это просто тупо ссылки на функции в объекте-мапе и в каждом объекте они могут дублироваться или быть иными (намеренно избегаю тут обсуждения __prototype__).
В С++ это таблица виртуальных функций.
Но есть и примеры поинтереснее.
Например в WinAPI работа с сообщениями - это ООП as is.
Есть интерфейс PostMessage( окно, номер_сообщения, два параметра ) и пошло-поехало - шлём WM_REPAINT всем кому угодно - кто умеет обрабатывать - обрабатывает. Чистый и незамутнённый ООП.
Я уже давно для себя открыл закон имени... не знаю кого - если пишешь GUI, то на чём ни пиши, но получится ООП. Потому что там иначе ну просто никак. Ну или получится полное гумно.
И из таких задач и их осмысления ООП в принципе и выросло как таковое.

#25
11:43, 16 дек. 2019

NetSpider
процедурное программирование тоже нифига не парадигма.
Берем бейсик или машинные коды, явно никакой не процедурный язык, добавляем стек вызовов и вуаля, у нас новая парадигма? От одной структуры данных?

#26
11:46, 16 дек. 2019

=A=L=X=

у тебя много свободного на букогвы

#27
12:15, 16 дек. 2019

NetSpider
> Это относится к ООП программированию, или нет?
  Да, это ведь создание обьекта

#28
12:33, 16 дек. 2019

NetSpider
> Вы меня наверное специально троллите. Вики:
>
> Мо́дульное программи́рование — это организация программы как совокупности
> небольших независимых блоков, называемых модулями, структура и поведение
> которых подчиняются определённым правилам
"Небольших" не значит "микроскопических".
В том же ООП, например, практически всегда модуль=класс.

=A=L=X=
> что немаловажно - то как осуществляется динамическая диспетчеризация по сути
> тоже неважно.
Нет. switch (objectType) - это тоже динамический диспатч, но это не ооп.
Надо тогда наложить ещё один критерий - внешний код должен иметь возможность свободно добавлять новые типы, реализующее то же поведение.

#29
12:34, 16 дек. 2019

innuendo
> у тебя много свободного на букогвы

Так я в отпуске до конца года.

kipar
> Берем бейсик или машинные коды, явно никакой не процедурный язык, добавляем стек вызовов и вуаля, у нас новая парадигма?

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

Страницы: 1 2 3 417 Следующая »
ФлеймФорумПрограммирование