Кaкиe cyщecтвyют пpинципы

Если ты про страуструповскую мантру, то "инкапсуляция, наследование, полиморфизм".
При этом JS много лет прекрасно жил без инкапсуляции, а Go великолепно чувствует себя без наследования. Более того, интерфейсы, существующие в большинстве ООП-языков, нужны именно для того, чтобы наследования не было.

Указанная религиозная матнра - это не ООП, а всего лишь самый модный вариант ООП.

P.S. "Абстракцию" к существующим несколько десятилетий "принципам" добавили всего несколько лет назад.

P.P.S. Полиморфизм элементарно реализуется без ООП в любом процедурном языке, имеющем указатели (ссылки) на подпрограммы.

Хорошая новость: с некоторыми из принципов ООП ты уже знаком! :) Наследование нам уже пару раз встречалось в лекциях, и мы успели с ним поработать.

Наследование — механизм, который позволяет описать новый класс на основе существующего (родительского). При этом свойства и функциональность родительского класса заимствуются новым классом.

Для чего нужно наследование и какие преимущества оно дает?

Прежде всего — повторное использование кода. Поля и методы, описанные в родительских классах, можно использовать в классах-потомках.

Если у всех типов автомобилей есть 10 общих полей и 5 одинаковых методов, тебе достаточно вынести их в родительский класс Auto. Ты сможешь использовать их в классах-потомках безо всяких проблем.

Сплошные плюсы: и количественно (меньше кода), и, как следствие, качественно (классы становятся гораздо проще).

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

В общем, как и в обычной жизни: все мы чем-то похожи на наших родителей, а чем-то отличаемся от них :)
Принцип 2. Абстракция
Это очень простой принцип. Абстракция означает выделение главных, наиболее значимых характеристик предмета и наоборот — отбрасывание второстепенных, незначительных.

Не будем изобретать велосипед и вспомним пример из старой лекции про классы.

Скажем, мы создаем картотеку работников компании. Для создания объектов «работник» мы написали класс Employee. Какие характеристики важны для их описания в картотеке компании? ФИО, дата рождения, номер социального страхования, ИНН. Но вряд ли в карточке такого типа нам нужны его рост, цвет глаз и волос. Компании эта информация о сотруднике ни к чему.

Поэтому для класса Employee мы зададим переменные String name, int age, int socialInsuranceNumber и int taxNumber, а от лишней для нас информации вроде цвета глаз откажемся, абстрагируемся.

А вот если мы создаем картотеку фотомоделей для агентства, ситуация резко меняется. Для описания фотомодели нам как раз очень важны рост, цвет глаз и цвет волос, а номер ИНН не нужен.

Поэтому в классе Model мы создаем переменные String height, String hair, String eyes.

Принцип 3. Инкапсуляция
С ним мы уже сталкивались. Инкапсуляция в Java означает ограничение доступа к данным и возможностям их изменения.

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

Простой пример из жизни.

У тебя есть имя и фамилия. Их знают все твои знакомые. Но у них нет доступа к изменению твоего имени и фамилии. Этот процесс, можно сказать, «инкапсулирован» в паспортном столе: поменять имя фамилию можно только там, и сделать это можешь только ты. Остальные «пользователи» имеют доступ к твоему имени и фамилии «только на чтение» :)

Еще один пример — деньги в твоей квартире. Оставлять их на виду посреди комнаты — не лучшая идея. Любой «пользователь» (человек, пришедший к тебе домой) сможет изменить число твоих денег, т.е. забрать их. Лучше инкапсулировать их в сейфе. Доступ будет только у тебя и только по специальному коду.

Очевидные примеры инкапсуляции, с которыми ты уже работал, — это модификаторы доступа (private, public и т.д.), а также геттеры-сеттеры.

Если поле age у класса Cat не инкапсулировать, кто угодно сможет написать:

Cat.age = -1000;

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

Под комментом дополнение

Ссылка на источник запрещена анти-спам системой