ООП наоборот?

Запись от CoderHuligan размещена 04.07.2024 в 09:23

Показов 4707 Комментарии 89

Метки oop, ооп

Я бы не стал писать этот пост в своем блоге, если бы не нуждался в некой обратной связи.
Постараюсь быть краток.
Я не против ООП. Вернее: я согласен что объектная парадигма внесла новый уровень в искусство программирования. Согласен, что мыслить в категориях объектов это более естественно, чем в категориях действий. Ведь действия (функции) всегда функции какого-либо объекта, который первичен. Не может быть действия без объекта, который это действие выполняет или над которым выполняется действие каким либо объектом. То есть объекты выполняют действия над такими же объектами.
И в языках человеческих подлежащее первичнее сказуемого, существительное первичнее глагола:
Мама мыла раму, естественнее чем: мыла мама раму. Для человеческого ума.
Вот почему конструкция: имя_объекта.действие - гораздо естественнее, чем конструкция: действие(имя_объекта). Это действительно так, согласен.
Преимущество еще и в том, что вместо:
мыла_раму(мама) мы пишем мама.мыла_раму, соответственно вместо имени мыла_раму, мы имеем более короткое мама, и так для всех действий (методов). А это намного сокращает опасность конфликта имен.
А теперь о недостатках традиционной реализации объектной парадигмы.
1. вместо того, чтобы эволюционно развивать процедурную парадигму в процедурных языках, пошли по пути революционному: путем по сути ломки процедурной парадигмы. То есть, взяли данные в виде структур и функции и запихали всё в одну коробку, назвав этого получившегося монстра "классом".
И вот здесь я считаю, что данные должны быть просто данными, а функции просто функциями, и их нельзя было пихать в одну коробку. Так как в си-подобных языках не было четкого понятия "модуля", класс подменил собой модуль, но не полностью. Так как класс по сути не может являться модулем - это совершенно разные понятия. К чему это привело? К невозможности манипулировать данными как простыми данными. Надо всегда помнить, что данные могут передаваться по сети, могут сохраняться на диск и т.д., но объекты вы на не сможете сохранить на диск, без дополнительных выкрутасов. То есть объект в ООП это НЕ ДАННЫЕ. Это надо запомнить. Не правда ли - парадоксальный вывод? Но это так. Я даже не знаю как назвать этого получившегося монстра, а вернее генетического урода, по сути химеру. То есть взяли и скрестили две совершенно разные сущности: данные и функции. Логика была такая: почему бы не скрестить вместе функции, и данные, которые по типам связанны с друг другом? Ведь функции у нас типизированные, заточены на определенный тип данных. Но, однако, забыли, что для этого существует понятия модуля, где эти разные сущности и должны обитать.
Создали проблему, потом начали разгребать и как то с этим существовать. То есть чтобы общаться с генетическими уродами нужен особый подход или язык. Такой язык был создан. Так возникла объектная терминология, а вокруг неё свой особый круг посвященных жрецов..
Я считаю, что процедурные языки имеют потенциал для расширения в объектном направлении не ломая структуру процедурного кода. То есть предлагается не революционный подход, а эволюционный. Это похоже на Процедурно-Параметрическую парадигму, продвигаемую профессором Легаловым, которую он осуществил в языках O2M и Пифагор. Это прямой конкурент ООП. Я предлагаю нечто другое, но также параметрическое. И вот о этом то и хотелось поговорить.
Если в O2M функции реализуют действия, а аргументы функций параметризуют возможные варианты обработки разных типов, то я предлагаю исходить не из действия, что вторично, а первичным сделать имя объекта, которое является именем некой объектной функции.
Эта функция не простая. Во первых она не называется процедурой или функцией, она определяется как объект:

Code
1
2
3
object name(listOfParams)
// body
end object

Но по сути это тоже функция. Просто мы подчеркиваем, что она обладает иными возможностями. Внутри этой конструкции мы определяем действительные функции, которые и реализуют методы. Тип данных определяется именем name, и этот тип определяется вне этой конструкции, но в одном модуле с ней. Конкретный экземпляр данных передается первым параметром. Второй параметр определяет метод. Третий опциональный параметр определяет список параметров конкретного метода. Все методы имеют доступ к экземпляру данных в первом параметре.
Переключение методов осуществляется как и в ООП через внутреннюю таблицу методов через указатели на функции. Конструкция object может возвращать то возвращаемое значение, которое возвращает конкретный метод. То есть может возвращать значения разных типов. Конструкторы/деструкторы осуществляются также через методы.
Например создаем объект "мама":

C++
1
мама a = мама();//если у конструктора есть параметры передаем их в скобках.

при этом мама() возвращает экземпляр, а конструктор вызовется автоматически.
Далее:

Code
1
2
3
мама(а, мыть, раму);
мама(а, стирать, брюки);
мама(а, готовить, обед);

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

Метки oop, ооп

Размещено в Без категории

« Как запомнить знаковые и беззнаковые диапазоны максимальных значений Главная страница Не возвращайте мне ваши ошибки! »

Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.

Всего комментариев 89

Комментарии

5 из 5

Вообще говоря выбор ООП не ООП это вообще разговор другого рода. Например я пишу свой проект на PHP. Ну там применение ООП как бы грубо говоря "меньше профитов дает", хотя бы потому, что в общем случае php скрипт это 30 секунд работы и все долой из памяти

Главное у другом: лично мне так понятнее. И это важно - это снижает стоимость разработки. Для вас вполне возможно понятнее функциональное.

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

Т.е. важно понимание, умение пользоваться и проектировать.

Запись от voral размещена 08.07.2024 в 15:23 voral вне форума

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

Главное у другом: лично мне так понятнее.

Главное чтобы понятно было другим...

Запись от CoderHuligan размещена 08.07.2024 в 15:49 CoderHuligan вне форума

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

По этому я и добавил "в общем случае". Нюансы есть в этом направлении.

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

Главное чтобы понятно было другим...

Это зависит не от парадигмы, а от спроектировавшего/написавшего конкретный код.

Запись от voral размещена 08.07.2024 в 15:53 voral вне форума

Это зависит не от парадигмы, а от спроектировавшего/написавшего конкретный код.

Процедурный код гораздо легче:
1 понимать
2. тестировать
чем объектно-ориентированный. Спорить не буду.

Запись от CoderHuligan размещена 08.07.2024 в 16:09 CoderHuligan вне форума

	Это только для вас.
	Запись от voral размещена 08.07.2024 в 16:11

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

Процедурный код гораздо легче:
1 понимать
чем объектно-ориентированный.

1. не нужно его вам понимать!
2. есть интерфейс - юзайте класс только через интерфейс.
3. тестировщик должен понимать какие данные будут входить на вход, и что должно выходить на выход. ВСЁ!
4. тестировщик это ЭЛИТНЫЙ пользователь того класса, работу которого он тестирует.
5. тестировщику фиолетово, как там внутри класса всё работает.

внутри класса может быть куча процедур с приватным модификатором,
до которых дело есть только у разраба этого класса и НИКОМУ больше!

Запись от XLAT размещена 08.07.2024 в 18:15 XLAT вне форума

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

Запись от CoderHuligan размещена 09.07.2024 в 14:01 CoderHuligan вне форума

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

говорите все же за себя.

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

У нас все упорядочено. Если все разбросано - это значит безграмотный архитектор был на проекте.

Запись от voral размещена 09.07.2024 в 14:03 voral вне форума

	Точно так же процедурный подход ни как не спасает от беспорядка. Более того - беспорядок там "легче" достигается.
	Запись от voral размещена 09.07.2024 в 14:05

5 из 5

Новые блоги и статьи Все статьи Все блоги /
Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .	Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .	мат медиц модель 30. презентация проекта anaschu 27.08.2026 хоп хоп хоп хидахоп, а я кладую))
Как у меня протекала болезнь zorxor 27.08.2026 Здравствуйте, друзья! Эта запись блога предназначена именно для вас - для моих дорогих друзей, которые знали меня лично. Чтобы ответить на вопрос - а что же со мной произошло на самом деле? Я учился. . .	Нашел вот забавное видео о измерениях. Лучшее что я видел на эту тему kumehtar 26.08.2026 ILETXiw9bMQ Основная суть и тезисы по измерениям: 0D (Нулевое измерение): точка, не имеющая длины, ширины, высоты или объема. Объект не может перемещаться в 0D. 1D (Первое измерение):. . .	[EasyBuilder Pro] Памятка по разработке для панелей Weintek ФедосеевПавел 26.08.2026 Памятка по разработке для панелей Weintek ВВЕДЕНИЕ Ранее, при реализации проектов основное внимание уделял разработке управляющей программы для контроллера, а панели оператора доставалось время. . .	Модель по догадкам anaschu 25.08.2026 Прошло две недели. Я уже рассказывал, как разговаривал с сотрудниками у сортировки и как понял, что главная ветка — не про приёмку, а про отбор. Но тогда я думал, что понял механику. На этой неделе я. . .

Сообщение форума

Отменить изменения