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

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

Показов 4582 Комментарии 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

Комментарии

1 из 5

Про мама мыла раму.

Вообще говоря точнее будет так

Мама.моет(раму)

Но далее уже всплывают нюансы предметной области и задачи.

Сама реализация процесса помывки может быть полностью реализована в методе "моет". А "Рама" может быть вообще просто ДТО. Да и метод моет может иметь в качестве параметра не класс "Рамы", а интерфейс "МожетБытьПомыть"

Но может быть и сложнее, т.е. в моет реализуется процесс подготовки к помывки и завершения помывки, а между ними вызываться метод класса Рамы.мыть()

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

При чем тут "ломать". Просто есть два параллельных равноправных подхода. Точно такие же "варианты определенного инструмента". Приступаем к новой задаче выбираем подходящие инструменты. В т.ч. ООП vs процедурный vs функциональный.

И вот здесь я считаю, что данные должны быть просто данными, а функции просто функциями, и их нельзя было пихать в одну коробку.

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

Те же ДТО - вот вам и разделение как вы хотите.

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

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

моечему не просто

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

Запись от voral размещена 04.07.2024 в 10:18 voral вне форума

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

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

Лужу, паяю, примусы починяю ...

Запись от politoto размещена 04.07.2024 в 10:43 politoto вне форума

1. а я же предупреждал, что сишкшкодерство портит моск.

2. вместо того, чтобы прочитать Р.Мартина про смысловую нагрузку термина "парадигма" в программировании
нечитатели придумывают уже придуманное сишкошкодерами и объявляют парадигмой.

3. Легалов, судя по ооп-примеру на 11 стр. автор некомпетентен, т.е. программы в ооп парадигме он писать не умеет.

4. вся эта параметрическая хрень со свичом тупо нижний уровень кодинга в составе ооп.

5. если кто-то смог выучить полиморфизм, то это не означает, что теперь ему следует его тыкать во все дыры.

Запись от XLAT размещена 04.07.2024 в 11:08 XLAT вне форума

А "Рама" может быть вообще просто ДТО.

А может быть таким же объктом-функцией.

Да и метод моет может иметь в качестве параметра не класс "Рамы", а интерфейс "МожетБытьПомыть"

Интерфейс "МожетБытьПомыть" это просто ссылка на конкретный объект конкретного типа. Естественно параметры это могут обеспечить в виде ссылочного типа.

Но может быть и сложнее, т.е. в моет реализуется процесс подготовки к помывки и завершения помывки, а между ними вызываться метод класса Рамы.мыть()

Если функции_методы реализованы как объекты-функции, то нет проблем.

Не понятно, что это дает.

Это дает простоту при отделении данных от функций. Да, можно вместо:
мама(а, стирать, брюки);
Писать в обычно процедурном так:
мама_стирать_брюки(а);
но в таком случае мы погружаемся в омут: вместо одного имени объекта у нас много имен действий. Это усложняет код, делает его грязным. Не позволяет мыслить в терминах объектов.

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

Не придется. Конструкторы и деструкторы реализуются просто. При создании объекта можно вызывать конструктор, а можно потом специально иницилизировать созданный объект.

моечему не просто

А как функция-объект поймет с каким экземпляром работает? Тут отсутствует this.

Запись от CoderHuligan размещена 04.07.2024 в 11:21 CoderHuligan вне форума

вместо того, чтобы прочитать Р.Мартина про смысловую нагрузку термина "парадигма" в программировании
нечитатели придумывают уже придуманное сишкошкодерам

А я поставлю такой вопрос и есть ли в нем смысл: указатель на функцию в составе структуры данных есть часть этих данных или нет? И еще: является ли указатель на функцию данными или нет? Вопрос к оопкодерам..

Легалов, судя по ооп-примеру на 11 стр. автор некомпетентен, т.е. программы в ооп парадигме он писать не умеет.

Там же черным по белому написано: "Пример процедурного подхода". Только он на плюсах написан. А в том, что он умеет в плюсы доказано тем, что реализован компилятор O2M. Исходники имеются.

если кто-то смог выучить полиморфизм, то это не означает, что теперь ему следует его тыкать во все дыры.

А я пока о полиморфизме не говорил.

Запись от CoderHuligan размещена 04.07.2024 в 11:30 CoderHuligan вне форума

А я пока о полиморфизме не говорил.

Почему не говорил? Потому что у меня его нет.

Запись от CoderHuligan размещена 04.07.2024 в 11:50 CoderHuligan вне форума

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

она не называется процедурой или функцией, она определяется как объект:

Рекурсивные объекты допускаются?

Запись от politoto размещена 04.07.2024 в 12:07 politoto вне форума

А я пока о полиморфизме не говорил.

говорить не надо - я читаю ваши мысли.

это старая история противопоставлять свичи полиморфизму и наоборот.

Code
1
Там же черным по белому написано: "Пример процедурного подхода"

ок.
на этот случай и был написан 5 пункт.

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

указатель на функцию в составе структуры данных есть часть этих данных или нет?

в отличии от балбесов вызубривших стандарт я почти(не про общие принципы, которые выше любых япов) всегда опираюсь на опыт:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include <iostream>
 
struct Test1
{
    int y = 2024;
};
 
struct Test2
{
    void info() { std::cout << "y: " << y << '\n'; }
 
private:
    int y = 2024;
};
 
int main()
{
    Test1 t1; std::cout << "sizeof t1: " << sizeof t1 << '\n';
    Test2 t2; std::cout << "sizeof t2: " << sizeof t2 << '\n';
}

output:

Code
1
2
sizeof t1: 4
sizeof t2: 4

Запись от XLAT размещена 04.07.2024 в 12:14 XLAT вне форума

Рекурсивные объекты допускаются?

Функция-объект может возвращать значение. В принципе ничего не мешает сделать так, чтобы она поддерживала рекурсию.

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

это старая история противопоставлять свичи полиморфизму и наоборот.

Это к профессору вопрос и к оопкодерам. Вопрос: зачем в рантайм определять какие-то типы. А можно не тратить на это время? Ну наверно.

я почти всегда опираюсь на опыт

Хитро.

Естественно вам покажут только данные. Вы этим только доказали одно: что указатели на методы не являются данными! Ну на внутреннем уровне каждый класс содержит указатели на методы в своем типе. С этим как быть? Если про них молчит sizeof это не значит что их нет.

Запись от CoderHuligan размещена 04.07.2024 в 12:39 CoderHuligan вне форума

Вопрос: зачем в рантайм определять какие-то типы. А можно не тратить на это время?

а вот это ваще древняя история:
cишкокодер может потратить неделю, чтобы его прога из 1000 строк стала меньше на 1(один) байт или быстрее на 1(одну) ns.

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

CoderHuligan,
начинайте писать прожект на 1'000'000 строк и вы почувствуете всеми видами ваших рецепторов ответ на ваш вопрос.

Ну на внутреннем уровне каждый класс содержит указатели на методы в своем типе.

и это хорошо,
вам же нужны уникальные методы?
если нет, то используйте наследование.

Запись от XLAT размещена 04.07.2024 в 12:50 XLAT вне форума

и это хорошо,
вам же нужны уникальные методы?
если нет, то используйте наследование.

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

Запись от CoderHuligan размещена 04.07.2024 в 13:26 CoderHuligan вне форума

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

CoderHuligan,
начинайте писать прожект на 1'000'000 строк и вы почувствуете всеми видами ваших рецепторов ответ на ваш вопрос.

Присоединяюсь к пожеланию. Плюсом пережить с этим проектом несколько жизненных циклов.

Запись от voral размещена 04.07.2024 в 13:41 voral вне форума

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

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

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

Запись от voral размещена 04.07.2024 в 13:46 voral вне форума

	И не обязательно кстати абстрактный класс создается "до"....
	Запись от voral размещена 04.07.2024 в 13:47

Присоединяюсь к пожеланию.

Прежде чем писать проект на 1 000 000 строк (проект ради проекта?))) надо создать язык на котором надо писать проект на 1 000 000 строк.
В принципе можно такой стиль как-то эмулировать на Си или плюсах. Но подозреваю, что это будет очень коряво и некрасиво. то есть нужен специализированный язык.

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

	Но смотрите: в таком стиле, код манипулирует лишь теми объектами, которые требует ТЗ. Спрятаны все действия. Такой код легко отлаживать и он более ясен и интуитивно понятен.
	Запись от CoderHuligan размещена 04.07.2024 в 14:06

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

Прежде чем писать проект на 1 000 000 строк (проект ради проекта?))) надо создать язык на котором надо писать проект на 1 000 000 строк.

одобряю.

но...

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

нужен специализированный язык.

один эксперт как-то сказал:
достаточно иметь понятия или конструкции вылитые в аппарате:
- переменные
- условия
- циклы(вместо гоуту)
- модель памяти

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

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

Запись от XLAT размещена 04.07.2024 в 16:36 XLAT вне форума

	Просто тестовый ЯП создать. Полный по Тьюрингу.
	Запись от CoderHuligan размещена 04.07.2024 в 17:21

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

Нет. Ради опыта. Уверен вы после получения опыта пройдетесь по своим же записям блога и везде самому себе выскажите "Фи"

ЯП тоже вполне себе проектом может быть.

Запись от voral размещена 04.07.2024 в 17:33 voral вне форума

1 из 5

Новые блоги и статьи Все статьи Все блоги /
сукцессия 37. Внедрил дипсик в свой оркестр из ИИ. У него закончилось пространство чата, потому опубликую выводы из его работы здесь anaschu 21.07.2026 ==================================================================== КОНТЕКСТ: Моделирование микоризной сукцессии (AM → ECM) ==================================================================== . . .	сукцессия 36. Делаю прогоны модели около порога бифуркации (превращения эндо микоризы в экто микоризу) anaschu 21.07.2026 СУКЦЕССИЯ МИКОРИЗ: КАК МАТЕМАТИКА ОБЪЯСНЯЕТ ПОДЗЕМНУЮ ВОЙНУ Мы привыкли думать, что лес — это деревья. А грибы — это то, что мы собираем в корзинку осенью. Но если заглянуть под землю, окажется,. . .	ИИ и человечность kumehtar 21.07.2026 Забавно, что общаясь с ИИ, я замечаю, насколько он высказывается умно, и насколько верит в людей. Он умеет прощать. Он знает как отвечать не обесценивая опыт других людей, даже если сам не верит. Он. . .	Нейтральные знания ..., ... чистая наука. Пока что-то проходит модерацию на Хабре, стоит развить мысль ... Hrethgir 20.07.2026 К таким радикальным взглядам я конечно в той публикации не приходил, но чтобы скоротать вечер, решил углубиться немного. 1. Почему показания термометра заряжены целью? Цель заложена в самом. . .
Установка нескольких штампов электронной подписи в строго определенных местах файла docx ВладимирСамохин 19.07.2026 (В!) Работа с Электронной подписью - это неотъемлемая часть современного документооборота. Но что делать, если нужно поставить несколько штампов электронной подписи в строго определенных местах. . .	сукцессия 35. Научная статья о проделанной работе anaschu 19.07.2026 Написал в формате латекс и пдф	Вангую, что это не пройдёт модерацию, и на неделе я запущу свой сервер. Hrethgir 19.07.2026 Эта публикация сейчас в песочнице и ждёт приглашения. https:/ / habr. com/ ru/ sandbox/ 295048/ По ссылке 403. Не очень информативно такую ссылку постить. Запись от Usaga размещена Сегодня в 06:46 . . .	сукцессия 33. открытые вопросы от клауде anaschu 19.07.2026 "Что накопилось за эту часть А — тринадцать правок, из которых шесть пришли из ваших вопросов и каждая оказалась реальной ошибкой, а не калибровкой: односторонний симбиоз, отсутствующий листопад,. . .

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

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