Буэнос диас, амигос! Понемногу изучая Rust, я столкнулся с тем, что привычные приемы проектирования "не работают". Конечно же я об ООП и его паттернах проектирования. Некоторые "коллеги по цеху" уже разочаровались по стопицот раз, переписывая С++ код на Rust. В представленной выше ссылке, как по мне, интересна не сама статья как натянуть сову на глобус, а последующие обсуждения. Там промелькнуло хорошее высказывание "Нет ООП-задач. Есть один из подходов - это используя ООП. Как будто он один единственный" (не дословно). Собственно вопросы к обсуждению Приступая к проектированию проекта, большинство разработчиков, которые худо-бедно владеют ЯП с полной поддержкой ООП, этот подход и выбирают. Я не имею ввиду 100-строчные "хелоу ворлд" утилиты. А нормальные, более-менее сложные проекты. 1) А как быть если полной поддержки ООП в ЯП нет? 2) Есть ли приемы/методики проектирования не менее удобные чем объектно-ориентированное? 3) А есть ли для них свои "паттерны проектирования", которые есть для ООП? ЗЫ: Аббревиатуру "ООП" читаем как "Объектно-ориентированное программирование" или "Объектно-ориентированное проектирование" по контексту.
а как люди жили в процедурных языках? есть сишечка, паскаль и ада до определенного времени не имели никакого ооп... как люди живут в функциональных языках типа хаскеля, окамла, фшарпа? функциональщина, дата ориентед дизайн... идеальный язык не должен иметь паттерны, как таковые... в таком языке должен быть всего один путь для решения каждой конкретной задачи и этот путь должен быть оптимальным... и да, если ты не понимаешь функциональщину, то это не вина функциональщины... многие вещи вполне удобно решать в функциональном стиле, при этом компилятору куда проще судить о корректности пьюр функций... посмотри, как в языке элм решена проблема создание веб интерфейсов, красота да и только.. --- Сообщение объединено, 18 янв 2019 --- конкретно касательно раста... есть определенный ряд причин, по которым язык и компилятор такие, какие они есть... не нравится, используй плюсы, никто никого не заставляет юзать раст...
так фундамент ооп строится чрез процедуры/функции == класс/объект есмь всего лишь таблица указателей на переменные и функции. собс-сно, а что такое "идеальный язык программирования", что ты закладываешь в это понятие???
Неправильная постановка вопроса. Изучаю раст, и нравится его концепция. Но наследие С++ не отпускает. Поэтому и интересуюсь.
А по моему правильная. Я с бесика ушла на паскаль потому, что там не было структур и не возможно было описывать вектора. А с паскаля ушла в дельфи потому, что там не было полиморфизма. А с дельфи ушла в Си++ потому что там есть множественное наследование. Как без этого обходится? Да можно к примеру объекты можно заменить указателями на структуры и таблицами функций. К примеру как тут: http://www.sources.ru/pascal/graph/inertia.htm Или как ещё в более древние времена не писать сложных программ. Пишете кучу простых и связываете их воедино при помощи ядра ОС. К примеру: https://github.com/qrush/unix Ещё можно хэндлы использовать и файлы (VFS). http://minix3.ru/docs/DriverPCI-02.pdf Так что другой дороги кроме ООП нету.
1. А объекты это что-то другое? 2. Чем это отличается, от "Не пишите большие классы, пишите маленькие и слабо связанные классы" ? Функции в этом плане гораздо чище. Люди написавшие ОS - не глупые люди. 3. Простите, но это какая-то дичь. LL(1) грамматика не требует объединения данных и кода в одном неделимом "объекте". А вот что бы эту неделимость обеспечить, и из-за нее возникающие проблемы решать, приходиться обкладывать код избыточными геттерами, сеттерами, конструкторами и т.п. Вот и выходит, что начинается с прямого доступа к памяти, для экономии, а заканчивается изобретения иммутабельных структур и зипперов. А люди, которые сразу мирятся с потерей на интерпретатор(не питон, а нормальный) не имеют проблем и нервов ООП.
Это не дичь это норма. Потребности определяет заказчик и окружающая среда. Именно среда определяет будет на планете человек или нет. А не атомы с их квантовыми числами. Они просто не пишут сложных программ. Не напрягаются, вот и не нужно расслабляться. Так синтаксис не объектовый. Ничем не отличается. Только масштабом то ОС а то программа. А до функции это тоже можно сузить. Но там чисто не удобно с визуализацией, синтаксиса не хватает.
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 --- язык которого нет... для меня это язык в первую очередь со строгой статической типизацией, кодогенераторы для всех процов плюс генерация джвм и мсил и джаваскрипт, кросскомпиляторы с любой оси в любую ось, зеро кост абстракции, сборка мусора на этапе компиляции и тд...
а идеального яп по определению быть не может, ибо в разработке всегда качество кода конфликтует с удобством для разраба. И при этом качество кода имеет чёткие критерии, а вот удобство зависит от заскоков разраба. в принципе с точки зрения качества кода хватит тройки == асм (для критических модулей/инлайна по скорости/размеру), сишечка (для всех бинов) и джава (для задач не требующих особой оптимизации).
качество кода и языки, позволяющие стрелять себе в ногу - вещи не совместимые, компилятор должен по максимуму обеспечивать безопасность кода... --- Сообщение объединено, 20 янв 2019 --- вообще говоря об идеальном языке, я уже давно слежу за Red, начинался проект очень многообещающе, но сейчас они ушли куда-то в криптовалюту и проект в итоге перестал нормально развиваться и скатился в гавно... семь лет уже прошло, а в языке только кодогенераторы для x86 (32-битный) и арм (32-битный), никакой толковой автоматизации, сборщик мусора не допилен и много других косяков... на что они потратили эти семь лет - вообще не понятно... видимо квалификации у разработчиков не достаточно...
защит от дурака не было и быть не может == супер защищённый от дурака яп будет тупо генерить тормознутою блоутвару. к тому же, возьмём, к примеру, Вопрос разработки софта для смарт домов == вот аким дикобразом там обеспечить защиту от дурака??? а во всех реал-тайм системах любая операция должна укладываться в чёткие отрезки времени и малейшая тормознутость кода может приводить к порче оборудования и даже жертвам. короче, все эти парадигмы "безопасного" кода приемлемы лишь для работы с сугубо виртуальными объектами и то сильно не всегда. тут надо спецов готовить, кои не имеют привычки само-подстрелов.
UbIvItS, Если бизнес приносит 300% прибыли то бизнес пойдёт на любое притупление. Математика не является точной наукой. Но это очень большой секрет. В коде который подвергли доказательной безошибочности безопасники находят уязвимости. К примеру QNX не является реал-тайм ОС. Если до 3 версии они двигались в этом на правление и там даже файловый менеджер рендерился по частям что-бы гарантированно уложится в квант времени. То начиная с 4 версии они болт забили на это дело там планировщик обычный для ОС. Единственное что спасает это то что, как правило окромя нужных процессов там нет других. В авиатехнике для этого придумана куча стандартов и техник. А на деле о них никто не слышал. Даже для роботов есть ГОСТ Р 60.1.2.1-2016 . Для примера он предписывает остановится роботу если он прилагает усилия больше чем человек.
Бестолковый тред ООП - не самостоятельная методология, а одна из опций. ООП может быть как в императивном языке, так и в функциональном.
Если посмотреть в гугл трендах Ruby, Go, Rust и C++, то видно что Rust совсем не популярен как об этом говорят, у него очень мало запросов, если выбрать Rust язык программирования, а не просто Rust куда входит еще поиски какой то относительно популярной игры. Хотя статистика в stackoverflow говорит что это самый любимый язык двух последних лет, а работают на нем чуть меньше людей чем на C++. Я бы выбрал C++ и ООП, а не модный язык, который потом и не вспомнят, как было с Ruby про него так много везде писали.
ООП не панацея. В новых C++ мне больше нравится функциональный стиль программирования. Да тот же ASIO отдельный на этом построен. Сейчас ООП это больше концепция проектирования, а в реализации чаще приходится применять функциональный стиль программирования и различные новые решения. Здесь JavaScript больше всего крут, он бесконечно гибкий и функциональный. Чистый ООП это в основном Java, там жесткие требования, жесткие границы, не разгуляешься. Современный C++ стал комбайном на любой вкус. Из этих по списку одобряю Golang. Проектировать без ООП? Звучит странно, примерно как просчитывать формулы без математики. Проектировать объектно-ориентированно это использовать абстракцию из объектов и прорабатывать воздействия на них, по аналогии с реальным миром. Реализовать можно на любом языке, хоть ассемблере. Сам по себе ООП в С++ ужасен конечно, иногда проще на структурах построить реализацию, чем на классах. Писать без классов еще не значит, что без ООП.
Модульное программирование: идеи объектов в отдельных файлах, группировка данных с методами в файле для каждого объекта, без поддержки объектов языком программирования. Методу столько-же лет, сколько и программированию.
