@el_gato_de_Ch

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

Инкапсуляция - это скрытие реализации.
Пример из реальной жизни: У нас есть объект - домашний стационарный телефон, у которого есть функция "позвонить(номер телефона)" пользователю, не обязательно знать, как коммутируются каналы, как "летают" электроны внутри, он пользуется готовой функцией.
Пример из программирования: private поля класса.

Наследование - возможность объекта иметь потомков, которые имеют расширенный интерфейс.
Пример: Класс - домашний телефон, класс наследник - мобильный телефон с функцией позвонить, и отправить СМС.

Полиморфизм - присваивание действию одного имени разным объектам в иерархии, чтобы потом каждый объект пользовался этим действием, так как угодно именно ему.
Пример из жизни: Расход бензина у различных автомобилей будет рассчитываться по разному в зависимости от количества электроники, которой напичкана машина. (полиморфизм методов).
Телефон стационарный кнопочный, телефон мобильный сенсорный, поля циферблат будут иметь разные типы в первом случае - МатрицаКнопок, во втором случае - СенсорнаяКлавиатура. (Полиморфизм полей класса)

Пример из программирования: перегрузка функций (методов класса наследника), одни и те же поля класса наследника могут иметь различный тип.

0

@Anton_Kretov

Про инкапсуляцию согласен, с наследованием не совсем. Пример не совсем корректен. Было бы лучше так:
Суперкласс: телефон
Наследники: домашний телефон, сотовый телефон

0

@Kuzia domovenok

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

0

@el_gato_de_Ch

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

0

@abit

если так - то тогда вообще ООП не имеет смысла по большому счёту, учите haskell, во имя добра)
ООП так и задумана, чтобы была абстракция, инкапсуляция, наследование, полиморфизм, в общем всё то, что мы наблюдаем за окном, а не в экране монитора листинга ассемблера/Си

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

Наследование - если честно это старый приём, который раньше назывался агрегирование

Полиморфизм - не путайте с перезагрузкой функций и т.д., реального полиморфизма в С++ я не видел

0

@Kuzia domovenok

нет, это именно так. Иначе чем тебе Си не угодил? В нём есть замечательные struct! Описывай своё 'заокном' сколько хочешь! Кстати, за окном я никакого ооп не наблюдаю. Абстракций никаких, все предметы конкретны, никаких реализаций не сокрыто, полиморфизма нет, всё гораздо более "неабстрактно", т.е. конкретно, чем любой язык может выразить от асма до самих си и хаскела.
Есть ли вообще хоть что-то абстрактное в реальном мире, кроме картин супрематистов?

Добавлено через 9 минут
abit, пока ты называешь наследование "старым приёмом, который раньше назывался агрегированием", тебе лучше воздержаться отвечать на вопросы о наследовании!

1

@gray_fox

ИМО, всё таки на понятия "реального мира" ООП не стоит так прямо отображать, если только для упрощения понимания... Мы же не наследуем класс квадрата от класса прямоугольника, правда?)

0

@rrrFer

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

Про правильное наследование можно у Саттера почитать - он описывает виды отношений, которые может выражать наследование и раскладывает все по полочкам.

Дак вот квадрат является прямоугольником, стороны которого имеют равную длину. Мне кажется, Саттер одобрил бы наследование. (см. правило 37 у Саттера).

Можно почитать Саттера на этот счет. У него там есть описание случаев, в которых агрегирование не даст результата.

Добавлено через 7 минут
Вцелом, все размыто более чем. ООП бывает разным. Вот есть ряд заморских товарищей, которые считают, что в SWI Prolog есть ООП и находят все основания для этого. Так, по их мнению, объект - это экземпляр подключенного модуля. Модуль - класс. Инкапсуляция - модуль предоставляет открытый интерфейс в SWI, все что к нему не относится - закрыто. У модуля (читай объекта) есть состояние - локальная база данных. Модули можно иерархически включать друг в друга, перегружать что-то и т.п. Это коротко, более подробно можно загуглить.
Вобщем, за уши можно притянуть что угодно и куда угодно. Но зачем?
Иное ООП и в смолтолке или Objective-C.

0

@aLarman

Читаю книгу по паттернам, там все паттерны привязаны к реальным объектам, в частности декоратор стратегия, и .др

0

@Kuzia domovenok

aLarman, притянуто за уши. В реале никаких "стратегий" не бывает. Что я хотел сказать, так это: если программисту нужен некоторый интерфейс для его объектов, он смело создаёт абстрактный класс и наследуется от него. Никаких аналогов в реале он не ждёт. Нужен ему какой-то абстрактный inputReader - пожалуйста!

Тут есть и ещё один момент, кстати. Если поставить цель найти реальные аналоги к созданным классам, ты их может и найдёшь... ну притянешь за уши, на крайняк. А вот создавать классы на основе реальн. предметов даже не надо пытаться! В итоге выяснится что для такого подхода нет разницы между наследованием и агрегацией(см. выше), появится наследование треугольника от точки, бмп от танка... и.т.п. казусы.

0

@aLarman

0

@Avazart

Ага а откуда взялись эти названия паттернов? не с реально жизни ?

Русский, английский языки, то же не идеально описывают Мир и чЁ?

Добавлено через 6 минут
А какой есть, нереальный ?

Добавлено через 6 минут
А что есть ?
Это лишь приемы, для описания того что нужно...
Собственно как и литературные приемы применяемые писателем что бы выразить свои мысли и ощущения "под действием этого мира".

Добавлено через 10 минут
Треугольник не являться точкой, поэтому тут изначально наследование идет боком.
Зато треугольник может состоять из точек. (может быть описан)
БМП и Танк могут иметь общий базовый класс, что тут нелогичного?
Это лишь примеры не правильного понимания принципов ООП.

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

2

@Dmitriy_M

Перегрузка функции это полиморфизм в чистом виде, точно так же как и шаблоны.

Добавлено через 1 минуту
в топку. всегда можно посмотреть в документацию.

0

@Avazart

С 1001 страницей ? зачем ?
Другое дело что не всегда можно провести эту аналогию, без ущерба в реализации.

Добавлено через 1 час 59 минут
Может у Мейерса ? У него вроде есть об этом и у него "правила", а у Саттера вроде в "задачах" все.

0

@korvin_

Ну как же, ты можешь бросить камень или гранату, например, т.е. твое действие «бросок» полиморфно относительно предмета броска. =)

http://citforum.ru/programming/digest/lspv/

С какого объекта реальной жизни взялись названия паттернов «Абстрактная фабрика», «Итератор»?

Перегрузка — это такой вид ситуативного (ad-hoc) полиморфизма.

И каков он «реальный полиморфизм»?

0

@Avazart

Нашел: Мейерс С. -"Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ(2006)"


Добавлено через 3 минуты
А что с фабрикой не то ? Фабрика производит продукцию разных типов, чем не соответствие ?

0

KOPOJI

Т.е., вы всегда знаете, из чего состоят все вещества вокруг, машина у вас - полностью прозрачная (также, как и квартира) - ведь ничего же не скрыто?
Я не спорю, не всегда легко найти аналогию - но это не всегда значит, что ее нет.

0

@rrrFer

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

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

0

ValeryS

а давай по другому
точка есть окружность с нулевым радиусом

а почему бы и нет
квадрат частный случай прямоугольника
прямоугольник частный случай параллелограмма
параллелограмм частный случай четырехугольника

это я к тому что проектирования наследования не так просто как кажется на первый взгляд

0

@el_gato_de_Ch

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

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

0