[Lost Tower]

Объектно ориентированное программирование(ООП)…

Что это?

Из названия понятно, что это программирование, ориентированное на объекты.

Что есть объект?

Да хоть что! Все можно воспринимать как объект: стакан — объект, ложка в стакане — опять же объект, и даже ложка со стаканом так же может восприниматься как объект.

И чем же тогда нам может помочь понятие, включающее в себя всё? Ведь, говоря, что «всё — объект», мы лишаем уникальности любое подмножество этого «всего». Впринципе, так и есть: мы обезличиваем вещи, делаем их проще. Зачем? Да чтобы проще было с ними работать!

Чем же этот поход к программированию хорош?

Тем, что такой подход наибоее близок к человеческому пониманию. Представьте, что я бы сказал, что стакан — это множество значений, таких как «высота», «ширина», «длина» и «объём». Такого представления стакана нам хватит, чтобы написать программу, подбирающую упаковку для стакана (размеры упаковки) + мы могли бы сделать возможность выбора (для пользователя) «какого объёма ему нужна тара». Впринципе, для интернет-магазина этого уже может и хватает… Итого, нам потребовалось 4 сущности для описания такой вещи как стакан. Мы их удерживали в голове как отдельные вещи… Думаю, не стоит Вам объяснять, что держать в голове 4 вещи сложнее, чем одну (стакан), пусть даже и подразумевая, что у него есть какие-то параметры…

Что мы сделали, собрав воедино высоту, длину, ширину и объём? Мы абстрагировались от них на новый уровень абстракции(извините за тавтологию) – «стакан», мы инкапсулировали 4 сущности в одну! «Абстракция данных» и «инкапсуляция» являются одними из принципов ООП.

Хм… стакан — это, конечно, хорошо, но вот наш интернет-магазин набрал обороты, и наши покупатели не довольны, что у нас стаканы не различаются по цвету… Мы можем сказать «O’key, ща напишу новую абстракцию ‘цветной стакан’», но делать это «с нуля» глупо, лучше использовать наработки из «предыдущей серии». И вот мы берём наш старый тип абстракции «стакан» и, основываясь на нём, создаём новый, но с дополнительным пунктиком – «цвет». Но делаем это не банальным переписованием, а говорим «нам, пожалуйста, тип абстракции, основанный воооон на том, но с новым пунктом ‘цвет’». И у нас готов новый класс, как бы наследующий от предыдущего все качества. Этот принцип называется «наследование». Мы получили «ребёнка»(потомка) от родительского типа «стакан»(предок), который унаследовал все плохие и хорошие качества отца

Отлично! Теперь у нас есть механизм создания сложных иерархий(родов). Причём каждый следуйщий в роду наследует все качества предыдущего и добавляет некоторые свои… А вдруг унаследовалось что-то «плохое»(ненужное), или нам просто показалось, что в этом поколении какое-то свойство должно выполняться по-другому… Например, всё тот же тип «стакан», был у него метод(действие над ним) «запаковаться», где он брал свои габариты, выбирал коробку из какой-то базы и командовал «запаковать» вот в эту коробочку…

Но пришли новогодние праздники и вы создали «стакан новогодний подарочный», наследуясь от «цветного стакана» (ну, вы помните, абзацем ранее мы его создали), а «цветной стакан» унаследовал метод упаковки от обычного стакана. Но нам то нужен не обычный способ! Всё-таки праздники ! Мы, конечно, можем создать новый метод «упаковать празднично», а тот (предположим его звали «упаковать») оставить «на память» об эволюционном процессе (подобно копчику)… Но такой подход до добра не доведёт: ну ладно, 1 копчик… а представьте 10 Так что надо что-то делать! И тут нам ООП предлагает «полиморфизм» – это когда одному названию соответствует несколько вещей. В нашем случае — одному методу «упаковать» мы сопоставим 2 команды. То есть переопределим в нашем новогоднем типе этот метод по-своему (сбантиками и блёстками)… И никаких копчиков!

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

Ничего похожего не нашёл.