Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Системный анализ, проектирование и UML > ООП vs %Name%

Автор: Majestio 18.1.2019, 17:20

Буэнос диас, амигос!

Понемногу изучая Rust, я столкнулся с тем, что привычные приемы проектирования "не работают". Конечно же я об ООП и его паттернах проектирования. Некоторые "коллеги по цеху" https://habr.com/ru/post/309968/ по стопицот раз, переписывая С++ код на Rust.

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

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

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

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

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

Автор: LSD 21.1.2019, 13:25

Цитата(Majestio @ 18.1.2019, 18:20

)

1) А как быть если полной поддержки ООП в ЯП нет?

Цитата(Majestio @ 18.1.2019, 18:20

)

2) Есть ли приемы/методики проектирования не менее удобные чем объектно-ориентированное?

Удобство понятие сильно субъективное, но процедурный и функциональный подход существуют и имеют своих приверженцев. На том же Си есть очень большое количество ПО, включая ядра ОС.

Цитата(Majestio @ 18.1.2019, 18:20

)

3) А есть ли для них свои "паттерны проектирования", которые есть для ООП?

Конечно. Широко известный map и reduce это как раз такой шаблоны из мира функционального программирования.

ООП в целом достаточно универсальный инструмент и хорошо подходит для большинства задача. Но есть задачи которые им не решаются или решаются плохо. Например ООП не нужно если цель написать скрипт инсталяции и запуска некой программы, там просто не нужны объекты, достаточно процедур. Или например ядро ОС где накладные расходы на объекты не приемлимы.
Как правило ООП или не ООП, определяется задачей - насколько там применимы те или иные языки. И наличием разработчиков с соответвующими навыками.

Автор: ksnk 21.1.2019, 14:03

Majestio, Rust - это заменитель С - языка системного уровня, того, который без плюсов и без решеток... того, который еще от Керниган и Ричи. Языку системного уровня не особо нужны всякие заморочки вроде объектов, так же как они не очень то были нужны С.
Проблема С в том, что он создавался давно, имел довольно странный, по теперешним понятиям, синтаксис и на нем оказалось написано много чего важного, например ядро Юникса. Все это кому-то хочется переписать, вот и появился язык.
Правда, как и для всех языков, растоманы желают быть владычицей морскою, а не сидеть отведенной авторами языка луже. вот от того и плач...
Предсказываю появлние Rust++, за ним Rust# чтобы история пошла по новому циклу развития )))

Автор: LSD 21.1.2019, 15:44

Цитата(ksnk @ 21.1.2019, 15:03

)

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

Rust борется не с синтаксисом, он сам не далеко ушел от Си. Основная идея Rust это безопасность, искоренить все эти утечки памяти и обращения по нулевому указателю.

Автор: ksnk 21.1.2019, 18:18

Цитата(LSD @ 21.1.2019, 15:44

)

не далеко ушел от Си.

?
h-файлы, перегруженные деталями описания функций и т.д. ?
https://nsu.ru/xmlui/bitstream/handle/nsu/9058/kr.pdf?sequence=1&isAllowed=y
страница 31, например... Вот такой он, С )))
Хотя ядро написано уже на более современном, конечно....

Автор: _zorn_ 23.1.2019, 15:09

Цитата(ksnk @ 21.1.2019, 21:03

)

имел довольно странный, по теперешним понятиям

Не понял, и что там не так ? Учитывая что именно этот синтаксис и заимствовали многие, более "успешные" коллеги ?

Цитата(ksnk @ 22.1.2019, 01:18

)

страница 31, например... Вот такой он, С )))

И что там, кроме не понятно зачем использованного капса ? Это же будет синтаксическая ошибка вроде )
То что там описано, хоть один компилятор си скомпилирует ? ) Может все же лучше на практику смотреть, а не на теорию ?

Добавлено через 12 минут и 25 секунд

Цитата(ksnk @ 22.1.2019, 01:18

)

Хотя ядро написано уже на более современном, конечно....

https://stackoverflow.com/questions/20600497/which-c-version-is-used-in-the-linux-kernel
90-й год современность, да smile

Автор: _zorn_ 23.1.2019, 15:27

По вопросу топикстартера - надо применять подходы (возможно вы их не до конца поняли) используемого языка/фреймворка, а не заставлять язык/фреймворк работать так как вы "привыкли". Если не получается - нафига вам этот кактус ?

Автор: ksnk 23.1.2019, 15:41

Цитата(_zorn_ @ 23.1.2019, 15:09

)

Не понял, и что там не так ?

zorn, все копируют базовый синтаксис С++, избегая или меняя классовые различия. Вот он всем привычен и не вызывает раздражение при частом использовании. И не нужно его путать с синтаксисом С. Это две очень большие разницы...

Автор: _zorn_ 23.1.2019, 17:39

Цитата(ksnk @ 23.1.2019, 22:41

)

синтаксис С++

ШТА ???

Вы вообще реально в теме или "теоретик" ? "Синтаксис С++" какбе из Си. "++" это классы, ООП и вот это вот все.

Автор: ksnk 23.1.2019, 18:10

_zorn_, считаю что в теме. smile

Писал что-то для микроконтроллеров на самом настоящем С. В сборках использовался QuickC от Микрософт, он com файлы собирал как-то более удачно, чем борланд.

Автор: _zorn_ 23.1.2019, 18:14

Цитата(ksnk @ 24.1.2019, 01:10

)

Писал что-то для микроконтроллеров на самом настоящем С. В сборках использовался QuickC от Микрософт

Уделал

Но ведь Си не Микрософт изобрел ? )

А что есть "настоящий С" ? То что у вас в голове (потому что "было дело") или то что происходит в реальности ?

Ну где мля на Си, INT капсом пишут (ага он case sensitive smile

)

Автор: ksnk 23.1.2019, 21:19

_zorn_, то, что я привел в ссылке - книга самого Кэрнигана и Ричи. Я сам удивлен стилю, но как иллюстрация к моему тезису, что "раньше все было совсем плохо" это подходит лучше. Сам я писал на более привычном - с фигурными скобками, а не закрывающими тегами. Хотя приходилось по 2 раза перечислять параметры каждой функции и еще дублировать описания функций в Н файл.

Автор: _zorn_ 26.1.2019, 06:16

Цитата(ksnk @ 24.1.2019, 04:19

)

книга самого Кэрнигана и Ричи

И что ? Кто то так сейчас пишет ? smile

И писал вообще последние 20 лет ? smile

Автор: ksnk 26.1.2019, 11:25

Цитата(_zorn_ @ 26.1.2019, 06:16

)

И что ? Кто то так сейчас пишет ?

При чем тут "пишет"? Проблема в том, что нужно "переписать" то, что написано ранее.

Вот, например опубликованы исходники версий юникса для всяких устарелых машин https://www.linux.org.ru/news/opensource/13319215.
1972 год...

Код


main(argc,argv)
char **argv;
{
char buf[512];
int fold, fnew, n;
char *p1, *p2, *bp;
int mode;
        if(argc != 3) {
                write(1,"Usage: cp oldfile newfile\n",26);
                exit();
        }

Автор: LSD 28.1.2019, 13:26

Стиль кода, это не самая большая проблема. В новом проекте можно принять новый, хороший стиль кода. Проблема в концепции. Си как был "высокоуровневым ассемблером", так им и остался.
А новые языки пытаются привнести новые парадигмы: Go - асинхронность, Rust - безопасность.

Автор: _zorn_ 28.1.2019, 20:03

Цитата(ksnk @ 26.1.2019, 18:25

)

Проблема в том, что нужно "переписать" то, что написано ранее.

Не, правда есть такая проблема ? Наверное "рефакторинг" злобные массоны придумали. И поэтому (конечно) никто ничего не "переписывает" smile

Quantum (firefox) на rust. Истерию по Go тоже трудно не заметить. А Линус (надеюсь) до сих пор посылает с++ в опу )

Цитата(LSD @ 28.1.2019, 20:26

)

Go - асинхронность, Rust - безопасность.

JS - массовость (ну и асинхронность) smile

ЗЫ: Язык под задачу, а не задачу под язык smile

Автор: LSD 29.1.2019, 12:13

Цитата(_zorn_ @ 28.1.2019, 21:03

)

JS - массовость (ну и асинхронность)

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

Автор: _zorn_ 17.2.2019, 21:01

Цитата(LSD @ 29.1.2019, 19:13)

Цитата(_zorn_ @ 28.1.2019, 21:03

)

JS - массовость (ну и асинхронность)

В имеет значение "что планировалось" и "что получилось" ? smile