Форум программистов, компьютерный форум, киберфорум
CoderHuligan
Войти
Регистрация
Восстановить пароль
Рейтинг: 3.00. Голосов: 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

    Цитата:
    мама(мыть, раму);
    мама(стирать, брюки);
    мама(готовить, обед);
    Запись от voral размещена 04.07.2024 в 10:18 voral вне форума
  2. Старый комментарий
    Цитата:
    Сообщение от CoderHuligan
    в языках человеческих подлежащее первичнее сказуемого, существительное первичнее глагола:
    Мама мыла раму, естественнее чем: мыла мама раму. Для человеческого ума.
    Лужу, паяю, примусы починяю ...
    Запись от politoto размещена 04.07.2024 в 10:43 politoto вне форума
  3. Старый комментарий
    Аватар для XLAT
    1. а я же предупреждал, что сишкшкодерство портит моск.

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

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

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

    5. если кто-то смог выучить полиморфизм, то это не означает, что теперь ему следует его тыкать во все дыры.
    Запись от XLAT размещена 04.07.2024 в 11:08 XLAT вне форума
    Обновил(-а) XLAT 04.07.2024 в 11:14
  4. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    А "Рама" может быть вообще просто ДТО.
    А может быть таким же объктом-функцией.
    Цитата:
    Да и метод моет может иметь в качестве параметра не класс "Рамы", а интерфейс "МожетБытьПомыть"
    Интерфейс "МожетБытьПомыть" это просто ссылка на конкретный объект конкретного типа. Естественно параметры это могут обеспечить в виде ссылочного типа.
    Цитата:
    Но может быть и сложнее, т.е. в моет реализуется процесс подготовки к помывки и завершения помывки, а между ними вызываться метод класса Рамы.мыть()
    Если функции_методы реализованы как объекты-функции, то нет проблем.
    Цитата:
    Не понятно, что это дает.
    Это дает простоту при отделении данных от функций. Да, можно вместо:
    мама(а, стирать, брюки);
    Писать в обычно процедурном так:
    мама_стирать_брюки(а);
    но в таком случае мы погружаемся в омут: вместо одного имени объекта у нас много имен действий. Это усложняет код, делает его грязным. Не позволяет мыслить в терминах объектов.
    Цитата:
    Тем более, что теперь при интеопретации такого кода еще и придется выяснять, конструктор это или запуск действия.
    Не придется. Конструкторы и деструкторы реализуются просто. При создании объекта можно вызывать конструктор, а можно потом специально иницилизировать созданный объект.
    Цитата:
    моечему не просто
    А как функция-объект поймет с каким экземпляром работает? Тут отсутствует this.
    Запись от CoderHuligan размещена 04.07.2024 в 11:21 CoderHuligan вне форума
  5. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    вместо того, чтобы прочитать Р.Мартина про смысловую нагрузку термина "парадигма" в программировании
    нечитатели придумывают уже придуманное сишкошкодерам
    А я поставлю такой вопрос и есть ли в нем смысл: указатель на функцию в составе структуры данных есть часть этих данных или нет? И еще: является ли указатель на функцию данными или нет? Вопрос к оопкодерам..
    Цитата:
    Легалов, судя по ооп-примеру на 11 стр. автор некомпетентен, т.е. программы в ооп парадигме он писать не умеет.
    Там же черным по белому написано: "Пример процедурного подхода". Только он на плюсах написан. А в том, что он умеет в плюсы доказано тем, что реализован компилятор O2M. Исходники имеются.
    Цитата:
    если кто-то смог выучить полиморфизм, то это не означает, что теперь ему следует его тыкать во все дыры.
    А я пока о полиморфизме не говорил.
    Запись от CoderHuligan размещена 04.07.2024 в 11:30 CoderHuligan вне форума
    Обновил(-а) CoderHuligan 04.07.2024 в 11:31
  6. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    А я пока о полиморфизме не говорил.
    Почему не говорил? Потому что у меня его нет.
    Запись от CoderHuligan размещена 04.07.2024 в 11:50 CoderHuligan вне форума
  7. Старый комментарий
    Цитата:
    Сообщение от CoderHuligan
    она не называется процедурой или функцией, она определяется как объект:
    Рекурсивные объекты допускаются?
    Запись от politoto размещена 04.07.2024 в 12:07 politoto вне форума
  8. Старый комментарий
    Аватар для XLAT
    Цитата:
    А я пока о полиморфизме не говорил.
    говорить не надо - я читаю ваши мысли.

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

    Код:
    Там же черным по белому написано: "Пример процедурного подхода"
    ок.
    на этот случай и был написан 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:
    Код:
    sizeof t1: 4
    sizeof t2: 4
    Запись от XLAT размещена 04.07.2024 в 12:14 XLAT вне форума
    Обновил(-а) XLAT 04.07.2024 в 12:23
  9. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    Рекурсивные объекты допускаются?
    Функция-объект может возвращать значение. В принципе ничего не мешает сделать так, чтобы она поддерживала рекурсию.
    Запись от CoderHuligan размещена 04.07.2024 в 12:15 CoderHuligan вне форума
  10. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    это старая история противопоставлять свичи полиморфизму и наоборот.
    Это к профессору вопрос и к оопкодерам. Вопрос: зачем в рантайм определять какие-то типы. А можно не тратить на это время? Ну наверно.
    Цитата:
    я почти всегда опираюсь на опыт
    Хитро.
    Естественно вам покажут только данные. Вы этим только доказали одно: что указатели на методы не являются данными! Ну на внутреннем уровне каждый класс содержит указатели на методы в своем типе. С этим как быть? Если про них молчит sizeof это не значит что их нет.
    Запись от CoderHuligan размещена 04.07.2024 в 12:39 CoderHuligan вне форума
  11. Старый комментарий
    Аватар для XLAT
    Цитата:
    Вопрос: зачем в рантайм определять какие-то типы. А можно не тратить на это время?
    а вот это ваще древняя история:
    cишкокодер может потратить неделю, чтобы его прога из 1000 строк стала меньше на 1(один) байт или быстрее на 1(одну) ns.

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

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

    Цитата:
    Ну на внутреннем уровне каждый класс содержит указатели на методы в своем типе.
    и это хорошо,
    вам же нужны уникальные методы?
    если нет, то используйте наследование.
    Запись от XLAT размещена 04.07.2024 в 12:50 XLAT вне форума
    Обновил(-а) XLAT 04.07.2024 в 13:25
  12. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    и это хорошо,
    вам же нужны уникальные методы?
    если нет, то используйте наследование.
    У меня и так уникальные методы, так как они прописываются в определении объекта. То есть есть всего лишь один экземпляр метода. В принципе можно использовать и внешние методы в качестве параметров, т.е глобальные либо на уровне модуля, либо проекта. Нет перерасхода памяти.
    Про наследование. Как быть с этим, т.е. с тем, что оно дает в ООП. То есть возможно ли расширять данный объект за счет других? Если в ООП идут от более общих типов к более мелким, то в процедурном, от более мелких к более общим. И это более естественно, так как должен существовать более мелкий тип, чтобы из него можно было сделать более общий. Всё в строгих процедурных принципах когда из кирпичиков создаются иерархические компонентные модели.
    То есть класс "фигура" у нас появится позже, когда будут определены "круг", "треугольник" и "квадрат". В ооп сначала создают абстрактный класс. У нас нет абстрактных классов, но ссылки на конкретные объекты через более общий объект. То есть, объект "фигура" может манипулировать всеми объектами сразу одной командой-методом. В этом смысл обобщения. Если оопники вкладывают в это какой-то свой смысл, то это их дело.
    Запись от CoderHuligan размещена 04.07.2024 в 13:26 CoderHuligan вне форума
  13. Старый комментарий
    Цитата:
    Сообщение от XLAT Просмотреть комментарий
    CoderHuligan,
    начинайте писать прожект на 1'000'000 строк и вы почувствуете всеми видами ваших рецепторов ответ на ваш вопрос.
    Присоединяюсь к пожеланию. Плюсом пережить с этим проектом несколько жизненных циклов.
    Запись от voral размещена 04.07.2024 в 13:41 voral вне форума
  14. Старый комментарий
    Цитата:
    Сообщение от CoderHuligan Просмотреть комментарий
    То есть класс "фигура" у нас появится позже, когда будут определены "круг", "треугольник" и "квадрат". В ооп сначала создают абстрактный класс. У нас нет абстрактных классов, но ссылки на конкретные объекты через более общий объект. То есть, объект "фигура" может манипулировать всеми объектами сразу одной командой-методом. В этом смысл обобщения. Если оопники вкладывают в это какой-то свой смысл, то это их дело.
    Абстрактный класс создаюто только тогда когда он необходим. При этом если есть стадия проектирования вообще не важно ваш подход или ООП. Вы уже точно будете понимать, что реализуется в дочерних или родительских. Т.е. что в ООПешник что вы будете уже точно знать что будет реализовываться в "объекте фигуры" (чтоб вы под этим не подразумевали при вашем подходе)
    Запись от voral размещена 04.07.2024 в 13:46 voral вне форума
  15. Старый комментарий
    И не обязательно кстати абстрактный класс создается "до"....
    Запись от voral размещена 04.07.2024 в 13:47 voral вне форума
  16. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    Присоединяюсь к пожеланию.
    Прежде чем писать проект на 1 000 000 строк (проект ради проекта?))) надо создать язык на котором надо писать проект на 1 000 000 строк.
    В принципе можно такой стиль как-то эмулировать на Си или плюсах. Но подозреваю, что это будет очень коряво и некрасиво. то есть нужен специализированный язык.
    Запись от CoderHuligan размещена 04.07.2024 в 14:04 CoderHuligan вне форума
  17. Старый комментарий
    Аватар для CoderHuligan
    Но смотрите: в таком стиле, код манипулирует лишь теми объектами, которые требует ТЗ. Спрятаны все действия. Такой код легко отлаживать и он более ясен и интуитивно понятен.
    Запись от CoderHuligan размещена 04.07.2024 в 14:06 CoderHuligan вне форума
  18. Старый комментарий
    Аватар для XLAT
    Цитата:
    Сообщение от CoderHuligan Просмотреть комментарий
    Прежде чем писать проект на 1 000 000 строк (проект ради проекта?))) надо создать язык на котором надо писать проект на 1 000 000 строк.
    одобряю.

    но...
    Цитата:
    Сообщение от CoderHuligan Просмотреть комментарий
    нужен специализированный язык.
    один эксперт как-то сказал:
    достаточно иметь понятия или конструкции вылитые в аппарате:
    - переменные
    - условия
    - циклы(вместо гоуту)
    - модель памяти

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

    у меня негативные подозрения, что вы будете двигаться примерно в этой плоскости.
    Запись от XLAT размещена 04.07.2024 в 16:36 XLAT вне форума
  19. Старый комментарий
    Аватар для CoderHuligan
    Просто тестовый ЯП создать. Полный по Тьюрингу.
    Запись от CoderHuligan размещена 04.07.2024 в 17:21 CoderHuligan вне форума
  20. Старый комментарий
    Цитата:
    Сообщение от CoderHuligan Просмотреть комментарий
    Прежде чем писать проект на 1 000 000 строк (проект ради проекта?))) надо создать язык на котором надо писать проект на 1 000 000 строк.
    Нет. Ради опыта. Уверен вы после получения опыта пройдетесь по своим же записям блога и везде самому себе выскажите "Фи"

    ЯП тоже вполне себе проектом может быть.
    Запись от voral размещена 04.07.2024 в 17:33 voral вне форума
 
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2024, CyberForum.ru