ООП vs %Name%

Тема в разделе "WASM.ZEN", создана пользователем Majestio, 18 янв 2019.

Метки:
  1. Majestio

    Majestio New Member

    Публикаций:
    0
    Регистрация:
    31 окт 2017
    Сообщения:
    15
    Буэнос диас, амигос!

    Понемногу изучая Rust, я столкнулся с тем, что привычные приемы проектирования "не работают". Конечно же я об ООП и его паттернах проектирования. Некоторые "коллеги по цеху" уже разочаровались по стопицот раз, переписывая С++ код на Rust.

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

    Собственно вопросы к обсуждению

    Приступая к проектированию проекта, большинство разработчиков, которые худо-бедно владеют ЯП с полной поддержкой ООП, этот подход и выбирают. Я не имею ввиду 100-строчные "хелоу ворлд" утилиты. А нормальные, более-менее сложные проекты.

    1) А как быть если полной поддержки ООП в ЯП нет?
    2) Есть ли приемы/методики проектирования не менее удобные чем объектно-ориентированное?
    3) А есть ли для них свои "паттерны проектирования", которые есть для ООП?

    :dntknw:

    ЗЫ: Аббревиатуру "ООП" читаем как "Объектно-ориентированное программирование" или "Объектно-ориентированное проектирование" по контексту.
     
  2. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.241
    а как люди жили в процедурных языках? есть сишечка, паскаль и ада до определенного времени не имели никакого ооп... как люди живут в функциональных языках типа хаскеля, окамла, фшарпа?

    функциональщина, дата ориентед дизайн...

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

    и да, если ты не понимаешь функциональщину, то это не вина функциональщины... многие вещи вполне удобно решать в функциональном стиле, при этом компилятору куда проще судить о корректности пьюр функций... посмотри, как в языке элм решена проблема создание веб интерфейсов, красота да и только..
    --- Сообщение объединено, 18 янв 2019 ---
    конкретно касательно раста... есть определенный ряд причин, по которым язык и компилятор такие, какие они есть... не нравится, используй плюсы, никто никого не заставляет юзать раст...
     
  3. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.074
    так фундамент ооп строится чрез процедуры/функции == класс/объект есмь всего лишь таблица указателей на переменные и функции.
    собс-сно, а что такое "идеальный язык программирования", что ты закладываешь в это понятие???
     
  4. Majestio

    Majestio New Member

    Публикаций:
    0
    Регистрация:
    31 окт 2017
    Сообщения:
    15
    Неправильная постановка вопроса. Изучаю раст, и нравится его концепция. Но наследие С++ не отпускает. Поэтому и интересуюсь.
     
  5. Pavia

    Pavia Well-Known Member

    Публикаций:
    0
    Регистрация:
    17 июн 2003
    Сообщения:
    2.409
    Адрес:
    Fryazino
    А по моему правильная. Я с бесика ушла на паскаль потому, что там не было структур и не возможно было описывать вектора.
    А с паскаля ушла в дельфи потому, что там не было полиморфизма.
    А с дельфи ушла в Си++ потому что там есть множественное наследование.

    Как без этого обходится? Да можно к примеру объекты можно заменить указателями на структуры и таблицами функций.
    К примеру как тут:
    http://www.sources.ru/pascal/graph/inertia.htm

    Или как ещё в более древние времена не писать сложных программ.
    Пишете кучу простых и связываете их воедино при помощи ядра ОС.
    К примеру:
    https://github.com/qrush/unix

    Ещё можно хэндлы использовать и файлы (VFS).
    http://minix3.ru/docs/DriverPCI-02.pdf

    Так что другой дороги кроме ООП нету.
     
  6. q2e74

    q2e74 Active Member

    Публикаций:
    0
    Регистрация:
    18 окт 2018
    Сообщения:
    988
    1. А объекты это что-то другое?
    2. Чем это отличается, от "Не пишите большие классы, пишите маленькие и слабо связанные классы" ? Функции в этом плане гораздо чище. Люди написавшие ОS - не глупые люди.
    3. Простите, но это какая-то дичь. LL(1) грамматика не требует объединения данных и кода в одном неделимом "объекте". А вот что бы эту неделимость обеспечить, и из-за нее возникающие проблемы решать, приходиться обкладывать код избыточными геттерами, сеттерами, конструкторами и т.п. Вот и выходит, что начинается с прямого доступа к памяти, для экономии, а заканчивается изобретения иммутабельных структур и зипперов. А люди, которые сразу мирятся с потерей на интерпретатор(не питон, а нормальный) не имеют проблем и нервов ООП.
     
  7. Pavia

    Pavia Well-Known Member

    Публикаций:
    0
    Регистрация:
    17 июн 2003
    Сообщения:
    2.409
    Адрес:
    Fryazino
    Это не дичь это норма. Потребности определяет заказчик и окружающая среда. Именно среда определяет будет на планете человек или нет. А не атомы с их квантовыми числами.

    Они просто не пишут сложных программ. Не напрягаются, вот и не нужно расслабляться.

    Так синтаксис не объектовый.

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

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.241
    https://wiki.haskell.org/Haskell_in_practice
    http://www.ocaml.org/learn/companies.html
    https://github.com/jah2488/elm-companies
    https://clojure.org/community/success_stories
    https://codesync.global/media/successful-companies-using-elixir-and-erlang/

    многие успешные проекты и компании с тобой не согласны... наверное потому, что мышление у людей не ограничено одной парадигмой... они открыты чему то новому...

    да, отличная идея уйти с более менее безопасного языка в язык с андефайнд и анспецифайд бехэйвиор... множественное наследование вообще не нужный консепт, который в большинстве случаев можно заменить композицией вместо наследования... не говоря уже про даймонд оф дред, да более того множественное наследование во многих книгах называют код смелом... переход на другой язык из-за множественного наследования не говорит ни о чем кроме того, что человек не может строить нормальные архитектуры для проектов...
    --- Сообщение объединено, 19 янв 2019 ---
    смысл спрашивать, ты либо учишь и пытаешься понять консепт, либо игнорируешь его и сидишь на жопе ровно в своем уютненьком ооп... что тебе нового по твоему об этом могут сказать на форуме о низкоуровневом программировании?
    --- Сообщение объединено, 19 янв 2019 ---
    язык которого нет... для меня это язык в первую очередь со строгой статической типизацией, кодогенераторы для всех процов плюс генерация джвм и мсил и джаваскрипт, кросскомпиляторы с любой оси в любую ось, зеро кост абстракции, сборка мусора на этапе компиляции и тд...
     
  9. M0rg0t

    M0rg0t Well-Known Member

    Публикаций:
    0
    Регистрация:
    18 окт 2010
    Сообщения:
    1.574
    Не юзать ООП.

    Я вот не юзаю и не собираюсь. Процедурных ЯП хватает для всего.
     
  10. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.074
    а идеального яп по определению быть не может, ибо в разработке всегда качество кода конфликтует с удобством для разраба. И при этом качество кода имеет чёткие критерии, а вот удобство зависит от заскоков разраба. в принципе с точки зрения качества кода хватит тройки == асм (для критических модулей/инлайна по скорости/размеру), сишечка (для всех бинов) и джава (для задач не требующих особой оптимизации).
     
  11. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.241
    качество кода и языки, позволяющие стрелять себе в ногу - вещи не совместимые, компилятор должен по максимуму обеспечивать безопасность кода...
    --- Сообщение объединено, 20 янв 2019 ---
    вообще говоря об идеальном языке, я уже давно слежу за Red, начинался проект очень многообещающе, но сейчас они ушли куда-то в криптовалюту и проект в итоге перестал нормально развиваться и скатился в гавно... семь лет уже прошло, а в языке только кодогенераторы для x86 (32-битный) и арм (32-битный), никакой толковой автоматизации, сборщик мусора не допилен и много других косяков... на что они потратили эти семь лет - вообще не понятно... видимо квалификации у разработчиков не достаточно...
     
  12. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.074
    защит от дурака не было и быть не может == супер защищённый от дурака яп будет тупо генерить тормознутою блоутвару. к тому же, возьмём, к примеру, Вопрос разработки софта для смарт домов == вот аким дикобразом там обеспечить защиту от дурака??? а во всех реал-тайм системах любая операция должна укладываться в чёткие отрезки времени и малейшая тормознутость кода может приводить к порче оборудования и даже жертвам. короче, все эти парадигмы "безопасного" кода приемлемы лишь для работы с сугубо виртуальными объектами и то сильно не всегда. тут надо спецов готовить, кои не имеют привычки само-подстрелов.
     
  13. Pavia

    Pavia Well-Known Member

    Публикаций:
    0
    Регистрация:
    17 июн 2003
    Сообщения:
    2.409
    Адрес:
    Fryazino
    UbIvItS,
    Если бизнес приносит 300% прибыли то бизнес пойдёт на любое притупление.

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

    К примеру QNX не является реал-тайм ОС. Если до 3 версии они двигались в этом на правление и там даже файловый менеджер рендерился по частям что-бы гарантированно уложится в квант времени. То начиная с 4 версии они болт забили на это дело там планировщик обычный для ОС. Единственное что спасает это то что, как правило окромя нужных процессов там нет других.

    В авиатехнике для этого придумана куча стандартов и техник. А на деле о них никто не слышал.

    Даже для роботов есть ГОСТ Р 60.1.2.1-2016 . Для примера он предписывает остановится роботу если он прилагает усилия больше чем человек.
     
    UbIvItS нравится это.
  14. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.074
    Pavia, мне трудно с Вами не согласиться. кстати, очень меткое замечание..
    :)
     
  15. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    Бестолковый тред :) ООП - не самостоятельная методология, а одна из опций. ООП может быть как в императивном языке, так и в функциональном.
     
  16. Quasar3с48

    Quasar3с48 New Member

    Публикаций:
    0
    Регистрация:
    14 фев 2019
    Сообщения:
    3
    Если посмотреть в гугл трендах Ruby, Go, Rust и C++, то видно что Rust совсем не популярен как об этом говорят, у него очень мало запросов, если выбрать Rust язык программирования, а не просто Rust куда входит еще поиски какой то относительно популярной игры. Хотя статистика в stackoverflow говорит что это самый любимый язык двух последних лет, а работают на нем чуть меньше людей чем на C++. Я бы выбрал C++ и ООП, а не модный язык, который потом и не вспомнят, как было с Ruby про него так много везде писали.
     
  17. im.

    im. Active Member

    Публикаций:
    0
    Регистрация:
    16 сен 2017
    Сообщения:
    310
    ООП не панацея. В новых C++ мне больше нравится функциональный стиль программирования. Да тот же ASIO отдельный на этом построен. Сейчас ООП это больше концепция проектирования, а в реализации чаще приходится применять функциональный стиль программирования и различные новые решения. Здесь JavaScript больше всего крут, он бесконечно гибкий и функциональный. Чистый ООП это в основном Java, там жесткие требования, жесткие границы, не разгуляешься. Современный C++ стал комбайном на любой вкус. Из этих по списку одобряю Golang.

    Проектировать без ООП? Звучит странно, примерно как просчитывать формулы без математики. Проектировать объектно-ориентированно это использовать абстракцию из объектов и прорабатывать воздействия на них, по аналогии с реальным миром. Реализовать можно на любом языке, хоть ассемблере. Сам по себе ООП в С++ ужасен конечно, иногда проще на структурах построить реализацию, чем на классах. Писать без классов еще не значит, что без ООП.
     
    Последнее редактирование: 7 мар 2019
  18. Talomir

    Talomir Member

    Публикаций:
    0
    Регистрация:
    13 янв 2023
    Сообщения:
    51
    Адрес:
    Slovackia
    Модульное программирование: идеи объектов в отдельных файлах, группировка данных с методами в файле для каждого объекта, без поддержки объектов языком программирования. Методу столько-же лет, сколько и программированию.