Со всеми этими выкладками мы приблизились к пониманию того, что в коде в начале статьи нет никакой “магии”, “фокусов”, “интуиции”, “подбора” и прочих грязных хаков, а есть лишь чистая математика, во всей своей первозданной красоте. Для меня главным выводом из этой истории стала новость о том, что преобразование float в int и наоборот путем переинтерпретации одного и того же набора бит – это не ошибка программиста и не “хак”, а вполне себе иногда разумная операция.
Ошибаетесь. В этом коде есть чудовищный и катастрофический хак, который просто обязательно надо было упомянуть. А именно, нарушение правила strict aliasing-а при разадресации указателя. Все беды в коде возникают оттого, что кто-то проникся «элегантным решением», не разобравшись во всех деталях, а потом начинает применять его к месту и не к месту.
Эту и другие темы я разбирал в своем докладе на конференции C++ Russia. Кому интересно, можете заглянуть.
Есть такая беда, в университетах порой учат, что ООП — единственно правоверный подход, серебряная пуля в мире программирования. А потом выпускник сталкивается с Rust. И не знает даже, откуда начинать его понимать.
Концепция работы в Rust, по моему скромному мнению, самая адекватная из ООПшных. Есть структуры данных (в том числе они же — дескрипторы объектов реального мира. Структуры можно вкладывать друг в друга для получения более сложных структур.
struct Point {
x: i32,
y: i32,
}
struct Size {
width: i32,
height: i32,
}
struct Rect {
origin: Point,
size: Size,
}
Есть описание поведения структур, их характерные черты. (кстати, сообщество уже определилось, как переводить traits?). Их могут наследовать более глобальные описания.
Структуры могут иметь методы для работы с собой, но порой нам нужно работать с разнородными данными, имеющими какую-то общую черту. В таком случае мы используем trait. Вот и всё, данные отдельно, поведение отдельно. Половина проблем с разработкой иерархии классов решается сама собой.
А если смотреть глобально — случаи бывают разные. Где-то ООП с классами удобно, где-то старый добрый императивный подход, где-то функциональный, бывает, что нужен какой-то дикий гибрид.
Например, моё мнение: не нужно городить ООП поверх файловой системы. Ну, хорошо, File — это нормально. А вот функции типа mkdir, touch, stat, rename — не ложатся на парадигму никак. Поэтому люди выдумывают синглтоны, непонятные классы, FileManager и прочую ересь. Но зачем плодить лишние сущности, когда можно всё оставить, как есть (ну, может, сделать кроссплатформенные обёртки).
Очень большая боль ниже спины в ООП — различного рода оповещения. Для их реализации создаётся огород классов в 5-10. Хотя в функциональном программировании всё уже давно придумано. Почему не используем, если язык позволяет? Скорее всего, потому, что не научили…
Так что, не стоит в очередной раз разоблачать ООП, просто идите и учите другие парадигмы. Каждая из них имеет смысл и область применения.
Эту и другие темы я разбирал в своем докладе на конференции C++ Russia. Кому интересно, можете заглянуть.
Кажется, это рекурсия!
Концепция работы в Rust, по моему скромному мнению, самая адекватная из ООПшных. Есть структуры данных (в том числе они же — дескрипторы объектов реального мира. Структуры можно вкладывать друг в друга для получения более сложных структур.
Есть описание поведения структур, их характерные черты. (кстати, сообщество уже определилось, как переводить traits?). Их могут наследовать более глобальные описания.
Структуры могут иметь методы для работы с собой, но порой нам нужно работать с разнородными данными, имеющими какую-то общую черту. В таком случае мы используем trait. Вот и всё, данные отдельно, поведение отдельно. Половина проблем с разработкой иерархии классов решается сама собой.
А если смотреть глобально — случаи бывают разные. Где-то ООП с классами удобно, где-то старый добрый императивный подход, где-то функциональный, бывает, что нужен какой-то дикий гибрид.
Например, моё мнение: не нужно городить ООП поверх файловой системы. Ну, хорошо, File — это нормально. А вот функции типа mkdir, touch, stat, rename — не ложатся на парадигму никак. Поэтому люди выдумывают синглтоны, непонятные классы, FileManager и прочую ересь. Но зачем плодить лишние сущности, когда можно всё оставить, как есть (ну, может, сделать кроссплатформенные обёртки).
Очень большая боль ниже спины в ООП — различного рода оповещения. Для их реализации создаётся огород классов в 5-10. Хотя в функциональном программировании всё уже давно придумано. Почему не используем, если язык позволяет? Скорее всего, потому, что не научили…
Так что, не стоит в очередной раз разоблачать ООП, просто идите и учите другие парадигмы. Каждая из них имеет смысл и область применения.
Ещё бы IDE для Rust, было бы вообще супер!
https://npo-echelon.ru/production/65/10920
Ну уж нет, как минимум один гордый растафарианин (или как там договорились самоназываться?) читает это. Пускай и только в хобби-проекте использую)