Объясните понятие ООП

Скажите пожалуйста понятным языком, что такое объектно-ориентированное программирование ?

0

Мне нужно посчитать ускорение по второму закону Ньютона. ускорение = Сила / масса .
Создаю свойства "масса" и "сила", они будут проверять корректность данных, ну и хранить их
к ним метод "делилка", который будет разбираться с целочисленностью-нецелочисленностью деления и погрешностью.

Могу упаковать это всё в модуль, но там не будет проксирования; это то же, что использовать поля и методы класса; в них по дороге к вычислениям кто-нибудь может сдуру влезть и что-то переопределить, и я получу на выходе не весть что.

Поэтому я упакую всё в объект, и буду работать внутри него. А что дам пользователю наружу? Конструктор, которому пользователь скормит силу и массу.

Класс назову "Считалка_ускорения".
Работать с ним пользователь будет мак.

моё_укорение = считалка_ускорения (масса: 10, сила: 5)

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

У пользователя в инструкции стоит директива: посчитай ускорение - и он, на заморачивая себе голову деталями, прямо выполняет инструкцию - то есть, работает на уровне языка самой задачи - а не уровне языка решения задачи.

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

Добавлено через 9 минут

Сообщение от Shamil1 Абстрагирование не является чем-то специфичным для ООП.

Абстрагирование вообще не является чем-то специфичным.
Но есть разная приспособленность парадигм для абстрагирования. Есть более удобные инструменты достижения высокоуровневых абстракций - и менее, соответственно.
Чем ближе текст программы к человеческому языку - тем выше работа по уровню абстрагирования. Тем приспособленнее парадигма для абстрагирования.

0

Сообщение от neya Мне нужно посчитать ускорение по второму закону Ньютона. ускорение = Сила / масса . Создаю свойства "масса" и "сила", они будут проверять корректность данных, ну и хранить их к ним метод "делилка", который будет разбираться с целочисленностью-нецелочисленностью деления и погрешностью. Могу упаковать это всё в модуль, но там не будет проксирования; это то же, что использовать поля и методы класса; в них по дороге к вычислениям кто-нибудь может сдуру влезть и что-то переопределить, и я получу на выходе не весть что. Поэтому я упакую всё в объект, и буду работать внутри него. А что дам пользователю наружу? Конструктор, которому пользователь скормит силу и массу. Класс назову "Считалка_ускорения". Работать с ним пользователь будет мак. моё_укорение = считалка_ускорения (масса: 10, сила: 5) Вот это и есть абстрагирование: реализация вычислений спрятана под капот, а пользователь, посмотрев в инструкцию и прочитав, что здесь ему нужно вычислить ускорение - прямо по инструкции - вызывает считалку ускорения и скармилвает ей параметры. У пользователя в инструкции стоит директива: посчитай ускорение - и он, на заморачивая себе голову деталями, прямо выполняет инструкцию - то есть, работает на уровне языка самой задачи - а не уровне языка решения задачи. У него задача - посчитать ускорение - а не вникать в дебри второго закона Ньютона. Вот в этом состоит абстрагирование. Чем больше пользователь разгружен от деталей решения задачи - тем выше уровень абстрагирования.

вот и вся абстракция. Без кучи ненужного ООП-мусора.

Сообщение от neya Чем ближе текст программы к человеческому языку - тем выше работа по уровню абстрагирования.

И ООП тут не при чём.

1

Сообщение от neya Чем ближе текст программы к человеческому языку - тем выше работа по уровню абстрагирования.

В ФП текст программы обычно ближе к человеческому языку, чем в ООП.

2

1

Если Вас спросят "Что такое двигатель внутреннего сгорания", то ответ типа "это машина, в которой внутренняя энергия топлива превращается в механическую энергию" будет неудовлетворительным. Под это определение подходят и паровой двигатель, и реактивный, и даже огнестрельное оружие.

В любой книге по ООП вы найдёте основные принципы ООП: инкапсуляция, наследование, полиморфизм. В некоторых ещё и абстрация, но это совсем уж тавтология, ибо этот принцип лежит в основе (почти) всего. Всё верно, но нужно понимать две вещи:
1. Принципиальное отличие ООП от других парадигм - в использовании полиморфизма подтипов (а для этого нужно наследование или создание по образцу).
2. Использование ключего слова "class" не означает использование ООП-концепции (не является достаточным условием).

1

Масса должна быть неотрицательной, пользователю при ошибке нужно дать возможность её подкорректировать
Переменная mass - глобальная у соседа. У него вообще все переменные всегда глобальные

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

Добавлено через 1 час 4 минуты

Сообщение от korvin_ вот и вся абстракция. Без кучи ненужного ООП-мусора

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

0

Сообщение от neya Тогда эти типы можно создать самостоятельно, это будут классы - и думать в них.

Это не обязательно должны быть классы.
В C# и Java это будут классы, но только потому, что в них всё делается через... классы.

И думать об этом типе мы будем по-разному - в зависимости от того, чем он фактически является - Абстрактным Типом Данных, Миксином и т.д.

Причём, зачастую думать в терминах ООП гораздо менее удобно.
Например, для сортировки Списка проще передать функцию делегат для сравнения, чем создавать класс реализацию IComparer с перегруженным методом Compare.
Например, для обобщённого Списка проще передавать параметр типа, чем писать для каждого типа элементов отдельный класс наследник.
Например, ипользовать Алгебраический Тип Данных проще, чем реализовывать паттерн Посетитель или писать класс наследник для каждого возможного варианта данных. (Представьте, например, парсер, который возвращает либо положительный результат разбора, либо детальную информацию о причинах неудачи)

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

Человек редко думает о задаче в циклах "int sum = 0; for(int i = 0; i < list.length; i++) sum += list[i];". Человек думает "мне нужно сложить все элементы списка" или - математическим языком - "мне нужна свёртка по +". Поэтому ФП обычно ближе (чем ООП) к тому, как думает человек.

1

Сообщение от korvin_ А если я даю общее имя переменным и функциям, объединённым в виде модуля, а не объекта, это какой пункт?

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

0

Сообщение от Shamil1 Это не обязательно должны быть классы.

Вот здесь мне нравится, как человек объектном программировании говорит, с третьей минуты. Это для больших и сверхбольших систем, и если задача до двух тысяч строк кода, то можно обходиться и без
https://www.youtube.com/watch?... =UN%D0%98X

0

Сообщение от Mikhaylo А к модулям вы обращение можете делать?

Что значит «обращение»? Допустим, да, могу.

Сообщение от Mikhaylo У вас была сотня имён, так и осталась, нету упрощения

О чём ты вообще?

Добавлено через 1 час 40 минут

Сообщение от neya Вот здесь мне нравится, как человек объектном программировании говорит, с третьей минуты. Это для больших и сверхбольших систем, и если задача до двух тысяч строк кода, то можно обходиться и без https://www.youtube.com/watch?... =UN%D0%98X

Чушь он говорит.

0

Сообщение от korvin_ О чём ты вообще?

А вы вникаете в суть сообщений? Абстрагирование, обобщение, общее имя, обращение к этому общему имени, переход от частного к общему. Есть оно в случае модулей?

Разве нужна моя помощь в дальнейшем осмыслении?

0

Сообщение от Mikhaylo Абстрагирование, обобщение, общее имя, обращение к этому общему имени, переход от частного к общему. Есть оно в случае модулей?

Конечно.

Сообщение от Mikhaylo Разве нужна моя помощь в дальнейшем осмыслении?

Нужно, чтобы ты ясно излагал мысли, а не пространными фразами выражался.

0

Сообщение от Mikhaylo А к модулям вы обращение можете делать?

Вы не отличите статический класс от модуля.

0

Сообщение от neya Вот здесь мне нравится, как человек объектном программировании говорит, с третьей минуты.

Ничего нового.
Абстрагирование. Любое программирование есть суть абстрагирование.
Инкапсуляция. Есть во всех (практических) языках, независимо от парадигмы.
Наследование. Способ повторного использования кода.
Полиморфизм. То, что он говрит про полиморфизм, лучше не слушать. Для него полиморфизм - это утиная типизация. ("Динамически типизируемые языки единообразно представляют разновидности полиморфизма, что формирует самобытную идеологию в них и влияет на применяемые методологии декомпозиции задач." (с) вики)

0

У меня есть функция SayHello:
Я могу писать "John".SayHello() или SayHello("John"). То есть, до тех пор, пока у нас нет наследования с переопределением (override) метода, возможность писать "John".SayHello() вместо SayHello("John") - всего лишь синтаксический сахар, не влияющий на суть проектирования. Если же есть переопределение, то включается специальный механизм выбора подходящего метода. В разных ЯП этот механизм может быть реализован по-разному.

Если некий код можно выполнить для некого класса, то его можно выполнить и для любого класса наследника. То есть, класс наследник умеет всё то, что умеет базовый класс. Эта концепция называется "полиморфизм подтипов". Она влияет на суть проектирования. Если мы хотим, чтобы некий код выполнялся для разных типов, мы должны связать их наследованием. В этом и заключается ООП.

1

Сообщение от Shamil1 Вы не отличите статический класс от модуля.

Языки разные бывают. А вложение модулей друг в друга? А вложение переменных в модуль?

0

Сообщение от Mikhaylo А вложение модулей друг в друга?

Конечно.

Сообщение от Mikhaylo А вложение переменных в модуль?

Само собой.

0

Ну если модуль ничем неотличим от объектов, то он является объектом. Еще вопросы есть?))

0

Сообщение от Mikhaylo Ну если модуль ничем неотличим от объектов, то он является объектом.

Отличим, просто ты так и не спросил чем.

0

Так определитесь уже, отличим или нет

0