LINUX.ORG.RU

Моё понимание ООП

 


1

1

Мою прошлую тему загадили и утопили в молоке, завалили вопросами типа «а что ты понимаешь под ООП». И жалуются что я не отвечаю. Но не на все вопросы есть простые ответы. «Один дурак может задать столько вопросов, что сто мудрецов не смогут ответить!». И всё же я попробую представить своё видение.

Если взять просто данные, хранящиеся в структурах, то их можно сравнить с бухгалтерскими счётами: ты можешь сам прочитать данные, можешь сам изменить их, можешь переписать их себе в блокнот, можешь положить на хранение в ящик или передать их другому.

Объект - это как банкомат. Это - чёрный ящик, который надо подключить в сеть, подключить в интернет, при чём ты не знаешь сколько киловатт энергии он потребляет, сколько траффика он жрёт, сколько других людей и банкоматов влияют работу этого, ты не знаешь сколько данных он хранит. Он полностью сам решает, принимать ли твою банковскую карту или нет. Он может снимать зависящее от инфляции количество денег при запросе на выдачу состояния счёта. Он может быть устаревший или усовершенствованный, где функции могут иметь странные побочные эффекты. Он может вставить в выписку счёта рекламу. Да мало ли что ещё. Это - посредник со всеми вытекающими последствиями. Даже если ты пишешь его сам, используя его в разных проектах, ты можешь наделать изменений, которые могут неявно повлиять и на старые проекты побочными эффектами, либо потерей точности при дополнительный преобразованиях и т.д.

Вобщем, в первом случае модель, где ты контролируешь объём памяти, занимаемый данными, их формат (например, целый или с точкой) ты хранишь их в своей комнате и сам решаешь, делиться этими данными или нет. Это всё возможно из-за того что у тебя есть дополнительные знания (контекст), которые нигде в системе не хранятся. Твои функции, работающие с этими данными, предполагают что данные хранятся в том или ином формате и это позволяет избежать лишних преобразований, а так же необходимость в каждом объекте хранить лишние метаданные.

В случае с объектом ты можешь не знать где хранятся данные (в том числе, географически), сколько памяти задействовано, сколько ресурсов процессора задействовано на их обработку. Видна только маска - интерфейс.

Сразу хочу отметить, что я не против банкоматов, они не идеальны, но пока безналичный расчёт не везде принимают, приходится ими пользоваться. Проблема ООП в том, что в нём всё является таким «банкоматом» и везде принимается только нал. Любому очевидно, что когда имеешь дело с банкоматами, ты не можешь ничего оптимизировать.

ООП - это такая модель, в которой «всё является объектом», то есть данные заворачиваются в объект и вместо естественного для вычислительной машины хода обработки данных «данные на входе -> данные на выходе», твой код имеет дело с интерфейсами, т.е. идёт общение с «чёрным ящиком», который «сам знает что делать».

Простой пример: веб-браузер HTML+CSS+Javascript В этом примере HTML - это данные в чистом виде. Они не «знают» как себя отобразить. CSS - тоже данные. Это не объекты. И есть Javascript код, который имеет полный доступ к дереву документа. И когда ты пишешь веб-браузер, у тебя данные на входе - веб страница на выходе - это информационн-ориентированный подход (Data-oriented), в центре которого данные, а не объекты. Сохраняя страницу в формате .pdf ты тоже создаёшь данные на выходе. Эти данные можно отправить в другую программу для дальнейшей обработки. Это как инструмент.

★★

Последнее исправление: svyatozar (всего исправлений: 4)
Ответ на: комментарий от fsb4000

В С++ есть все те же проверки что и в Rust,

Нету там всех проверок, и дизайн контейнеров другой, тот же метод pop из твоей картинки будет возвращать Option, а не прямую ссылку, и такая ошибка тупо невозможна, и подобный код просто не скомпилируется.

даже больше проверок(большинство unsafe методов в Rust не делают проверки)

Зато в safe все проверки и в релизе остаются, а unsafe заразный и все возможно ошибочные действия использующие unsafe методы будут локализованы в unsafe блоках.

Можно оставить их и в релизе, достаточно добавить макрос _ITERATOR_DEBUG_LEVEL=1

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

anonymous
()
Ответ на: комментарий от fsb4000

большинство unsafe методов в Rust не делают проверки)

И вообще аналог unsafe в C++ это получить у того же вектора тупо сырой указатель через data() и ковыряться с ним, и без всякой возможности локализовать место ковыряния.

anonymous
()
Ответ на: комментарий от Nervous

Исчо раз (в последний повторю): «Сбросим этих дяденек и тётенек с парохода современности и отринем все эти парадигмы ради простой и понятной архитектурной логики. :D :D :D :D :D»

vtVitus ★★★★★
()
Ответ на: комментарий от Kogrom

Проверил реализацию GoF на unsafe - не нашёл. Зато очень много использования Box. То есть, если я правильно понимаю, в коде, который будет использовать эти заготовки, будет сплошной unsafe.

Нет неправильно Box вполне safe конструкция и для работы с ним unsafe не требуется это тупо объекты в куче, а не на стеке.

anonymous
()
Ответ на: комментарий от anonymous

Да, согласен. Вот тут есть пример полиморфизма на Box: https://www.quora.com/What-is-boxing-in-Rust Тогда вопрос с безопасностью снимается.

Остаётся только наследование не интерфейсов (trait). Можно рассуждать о том, что надо наследовать только интерфейсы, но в GUI-фреймворках спокойно наследуют абстрактные и конкретные классы, причем, о ужас, не свои, а библиотечные. Типа, отнаследовали класс Форма, добавили (переопределили) нужные методы и вот у нас GUI. Но это ещё можно на композиции сделать. А если нам нужен новый тип элемента управления, то будет заморочено его реализовывать через наследование интерфейса и композицию.

Kogrom
()
Ответ на: комментарий от Kogrom

но в GUI-фреймворках спокойно наследуют абстрактные и конкретные классы, причем, о ужас, не свои, а библиотечные.

Что-то MFC повеяло, сейчас (этому сейчас уже сильно больше десяти лет) модно же делать все элементы из кирпичиков, которые очень просто связываются, наследование не позволяет легко их комбинировать. Поэтому делают отдельно описание элементов обычно на своем markup (или основанном на xml) языке (QML, WPF) или просто на html (электрон, sciter) отдельно логику работы (часто на частично или полностью на скриптовом языке). Тут наследование уже не нужно практически. На раст как раз недавно открылась такого типа библиотека https://github.com/sixtyfpsui/sixtyfps https://www.opennet.ru/opennews/art.shtml?num=55532

anonymous
()
Ответ на: комментарий от anonymous

делают отдельно описание элементов обычно на своем markup (или основанном на xml) языке (QML, WPF) или просто на html (электрон, sciter) отдельно логику работы

Это просто конфиг. Должно ещё быть ПО, которое этот конфиг прочитает и выполнит.

модно же делать все элементы из кирпичиков

Например, есть кирпичик «кнопка». Можно ли из таких кирпичиков создать элемент «график»? Ну, наверное, можно, только выглядеть это будет вырвиглазно и будет использовать лишние ресурсы.

WPF

Ок, смотрим

using System;
using System.Windows;

namespace CSharp
{
    public partial class CodeOnlyWindow : Window
    {
        public CodeOnlyWindow()
        {
            this.Title = "Main Window in Code Only";
            this.Width = 300;
            this.Height = 300;
        }
    }
}

Наследование есть, использование свойств родительского класса есть. Никаких чудес. Да, использование конфига на xml даёт простоту создания интерфейса, но зато усложняет отладку по сравнению с Windows.Forms.

Kogrom
()
Ответ на: комментарий от hateWin

Да вот так возмет и просто напишет десяток миллионов строк кода.

anonymous
()
Ответ на: комментарий от fpastush

а ООП - это пока единственный способ навести этот порядок

Ну уж точно не единственный, есть структурное программирование, есть функциональщина, в обоих есть модули и этого уже вполне достаточно для наведения порядка.

anonymous
()
Ответ на: комментарий от BRE

клонировал Polkadot иииии… там 137K строк кода на Rust. Это не большой проект. Второй как я понимаю еще меньше. И время жизни проекта 2,5 года - тоже не показатель.

Дело не в том, существуют ли уже гигантские проекты на Rust. В конце концов, язык стабилизировался не так уж давно. Дело в том, что на Rust в принципе возможно создавать большие полезные проекты. Я думаю, что те, кто сейчас выбирает для нового проекта не Rust — недальновидные люди. Rust не идеален, не идеалистичен (за этим к Лиспу и Хаскелю), но Rust — очень практичный язык. Его легко изучить, легко на нём писать и легко его читать. И при этом экономится масса усилий на отладку, что при развитии проекта создаёт гигантскую фору по сравнению с другими.

hbee ★★★★
()
Ответ на: комментарий от hbee

В конце концов, язык стабилизировался не так уж давно.

Не менее шести лет назад - это давно.

Дело в том, что на Rust в принципе возможно создавать большие полезные проекты.

История говорит об обратном.

anonymous
()
Ответ на: комментарий от anonymous

в обоих есть модули и этого уже вполне достаточно

и было модульное до (и без) структурного

vM ★★
()
Ответ на: комментарий от pinus_nigra

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

Русское ООП не может быть с банкоматами и моделями. Вместо банкоматов надо говорить «выдаватели рублей» а вместо моделей… Я бы сказал что модели - «это девки в странных одеждах» но это не точно. У дена73 нужно уточнить.

anonymous
()

ООП - это такая модель, в которой «всё является объектом», то есть данные заворачиваются в объект

Так не заворачивай данные в объект! Данные (если их много) и логика должны храниться отдельно друг от друга. А как эти данные обрабатываются - посредством ООП или ФП - это стиль оформления.

baobab
()

Объект - это как банкомат. Это - чёрный ящик, который надо подключить в сеть, подключить в интернет, при чём ты не знаешь сколько киловатт энергии он потребляет, сколько траффика он жрёт

О господи, какой же бред. Нет. Объект, это, мать его, инстанс класса, полную структуру которого ты знаешь: ты можешь изменить этот класс, ты можешь переписать этот класс, ты можешь унаследовать этот класс и перекрыть методы, ты можешь расширения для класса написать, ты можешь его заменить аналогичным своим классом, ты можешь обвязку к нему сделать и работать с ним только через неё. Никто в реальности не работает в объектами, как с чёрными ящиками: это полностью открытые и понятные сущности. А модификаторы доступа лишь разграничивают, где, кому и как его конечности должны быть видны по мнению автора: мол, вот эту функцию можно дёргать безопасно, а вот эта - чисто для внутреннего использования. Даже не во всех языках есть модификаторы доступа, в том числе и к данным.

Devastator
()
Ответ на: комментарий от Kogrom

Да, использование конфига на xml даёт простоту создания интерфейса, но зато усложняет отладку по сравнению с Windows.Forms.

Там вроде ещё идея была в разделении обязанностей: пока кодерки что-то там под студией строчат, дизайнеры в бленде интерфейс верстают и стили крутят. Короч, пацаны из майкрософт к успеху шли.

Devastator
()
Ответ на: комментарий от alysnix

это ассемблер называется.

Это называется правильная архитектура программы, когда мухи отдельно, а котлеты отдельно. И причем тут ассемблер?

baobab
()
Ответ на: комментарий от baobab

ООП, это мышление сущностями. инстанс класса и есть сущность. как в том мире, что нас, почти всех, окружает.

а мухи отдельно - котлеты отдельно - это несущностный подход. мухи и котлеты, являясь сущностями, тем не менее составляют единое целое, а именно - то блюдо, что вам подали в дешевой столовой! и дешевая столовая - тоже сущность. сущности вездесущи!

alysnix ★★★
()
Ответ на: комментарий от alysnix

а мухи отдельно - котлеты отдельно - это несущностный подход. мухи и котлеты, являясь сущностями, тем не менее составляют единое целое, а именно - то блюдо, что вам подали в дешевой столовой! и дешевая столовая - тоже сущность. сущности вездесущи!

Оставьте эти бредни для тех сирых, кто нифига не может в модели, в следствие чего страдает «воспроизведением поведения @сущностей@»…

Хотя о чём это я, у нас же повсеместно именно кодеры занимаются разработкой структур данных и архитектур программ…

yyk ★★★★★
()
Ответ на: комментарий от alysnix

… мухи и котлеты, являясь сущностями, тем не менее составляют единое целое

Не пробовал …

anonymous
()
Ответ на: комментарий от yyk

Хотя о чём это я, у нас же повсеместно именно кодеры занимаются разработкой структур данных и архитектур программ…

но вы же не можете запретить им это делать?

alysnix ★★★
()
Ответ на: комментарий от yyk

Хотя о чём это я, у нас же повсеместно именно кодеры занимаются разработкой структур данных и архитектур программ…

Правильно вас понял?

у нас же повсеместно именно ЛАМЕРЫ занимаются разработкой структур данных и архитектур программ…
anonymous
()
Ответ на: комментарий от anonymous

у нас же повсеместно именно ЛАМЕРЫ занимаются разработкой структур данных и архитектур программ…

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

alysnix ★★★
()
Ответ на: комментарий от baobab

Данные (если их много) и логика должны храниться отдельно друг от друга. А как эти данные обрабатываются - посредством ООП или ФП - это стиль оформления.

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

другое дело - внутренние состояния обьектов, которые в силу слабости терминологии, тоже называются «данными», хотя вовсе и не данные, а просто точка в многомерном пространстве состояния обьекта.

alysnix ★★★
()
Ответ на: комментарий от Devastator

пока кодерки что-то там под студией строчат, дизайнеры в бленде интерфейс верстают и стили крутят

Да, я читал такое в книжках. Возможно, они предполагали что будет работать как в вебе, что появится профессия WPF-верстальщика. Но в реальности таких верстальщиков я не встречал, а дизайнеры как работали в фотошопе, так и работают, ни про какой бленд знать не хотят. Возможно, это только в моей практике так.

Kogrom
()
Ответ на: комментарий от anonymous

Самое лучшее ООП это в джаваскрипте.

Это прототипное ооп настолько «лучшее», что в итоге таки завезли более-менее нормальные классы.

Devastator
()
Ответ на: комментарий от alysnix

другое дело - внутренние состояния обьектов, которые в силу слабости терминологии, тоже называются «данными»

По моему мнению, информация и есть состояние машины состояний. Она не существует вне машины, будь то реальной или виртуальной.

svyatozar ★★
() автор топика
Ответ на: комментарий от svyatozar

По моему мнению,

Сто программистов, сто мнений ...
anonymous
()
Ответ на: комментарий от anonymous

Я бы сказал что модели - «это девки в странных одеждах»

«Нарядны красны девицы»

anonymous
()
Ответ на: комментарий от Devastator

Ну, так ТС смотрит на ООП не с позиции разработчика, использующего этот подход для проектирования ПО, а как макака типа «хуяк, хуяк и в продакшн». Так что тут он совершенно прав, с его точки зрения оно именно так и должно выглядеть.

anonymous
()
Ответ на: комментарий от anonymous

Ну, так ТС смотрит на ООП не с позиции разработчика,

Шутка

Как говорил персонаж из Аватар

Пусть остаётся среди нас и мы попробуем излечить его безумие ...
anonymous
()

@svyatozar, ООП /архитектура программ/ разная бывает.
В этом вопросе полезно узнать о методах разработки, а не о том нужен ли ООП …

anonymous
()

В случае с объектом ты можешь не знать где хранятся данные (в том числе, географически), сколько памяти задействовано, сколько ресурсов процессора задействовано на их обработку. Видна только маска - интерфейс.

Не только, с чего ты взял. Можешь видеть данные, можешь не видеть.

о естественного для вычислительной машины хода обработки данных «данные на входе -> данные на выходе»

вот ты маняфантазер, ейбогу

Проблема ООП в том, что в нём всё является таким «банкоматом» и везде принимается только нал. Любому очевидно, что когда имеешь дело с банкоматами, ты не можешь ничего оптимизировать.

ну просто феерическая маня. это не проблема ооп, это фича. И ООП не запрещает тебе программировать не по-ООП в одной и той же программе.

ООП существует потому-что это удобно человеку, че вы тут все обсуждаете вообще.

anonymous
()

И когда ты пишешь веб-браузер, у тебя данные на входе - веб страница на выходе - это информационн-ориентированный подход (Data-oriented), в центре которого данные, а не объекты

При этом код, обрабатывающий данные в браузере, чуть более, чем полностью состоит из объектов :)

annulen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.