Что такое объектно-ориентированное программирование (ООП) и его основные принципы?

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

Вот представь себе, что ты не программист, а, допустим, строитель. И тебе надо построить дом. Так вот, ООП — это не просто кидать кирпичи в кучу, а нормально, с умом, организовать процесс, чтобы потом не пришлось всё ломать и строить заново, потому что ванная оказалась на чердаке.

Первый столп — Инкапсуляция. Это, сука, как у тебя дома сейф стоит. У тебя там деньги лежат, документы, фотки с корпоратива, где ты в костюме зайца. Ты же не оставляешь сейф открытым нараспашку? Нет, блядь. Ты его закрываешь на ключ, а ключ либо у тебя, либо у жены. Вот инкапсуляция — это и есть этот сейф. Данные (деньги, компромат) внутри объекта (private). А чтобы их достать или положить — есть специальные методы, типа ключа (public getter/setter). Хочешь положить деньги — ок, через метод deposit(), который проверит, не фальшивки ли ты суёшь. Просто так в сейф залезть и набухаться на эти деньги — хуй тебе, а не доступ.

public class МояЖизнь {
    private String самыйСокровенныйСекрет = "я в детстве боялся клоунов"; // Спрятано нахуй

    public String выболтатьСекретПослеТретьейРюмки() { // Контролируемый доступ
        return самыйСокровенныйСекрет;
    }
}

Второй столп — Наследование. Ну тут всё просто, как в жизни, ёпта. Вот есть у тебя дед — он умел пить самогон, ругаться матом и чинить «Запорожец». Твой отец унаследовал от него эти качества (ключевое слово extends), но ещё и навык «работать на заводе» добавил. А ты унаследовал всё от отца, плюс прикрутил сверху умение «сидеть в интернетах». Все вы — семейство Мужики, но с каждым поколением функционал расширяется, и код не надо писать с нуля. Зачем изобретать велосипед, если можно взять готовый и приделать к нему мотор от бензопилы?

public class Дедуля {
    protected int крепостьОрганизма;

    public void ругатьсяНаПогоду() {
        System.out.println("Да что ж это за хуйня творится-то!");
    }
}

public class Я extends Дедуля { // Наследуюсь, блядь
    private boolean зависимостьОтМемов;

    public void ругатьсяНаПогоду() {
        super.ругатьсяНаПогоду(); // Дедушкин метод вызываю
        System.out.println("*гневно тыкает в смартфон с метео-приложением*");
    }
}

Третий столп — Полиморфизм. Во, это моё любимое, в рот меня чих-пых! Представь, есть у тебя команда «Сделай дело!». Ты её кричишь. Если это обращено к собаке — она принесёт палку. Если к жене — она, возможно, вынесет мусор. Если к программисту — он начнёт гуглить решение на StackOverflow. Одна команда, а действия — разные, в зависимости от того, КОМУ она адресована. В коде это значит, что ты можешь работать с разными объектами (Собака, Жена, Программист) через один общий интерфейс (например, Существо,КотороеМожетСделатьДело), и каждый отреагирует по-своему.

public abstract class Сотрудник {
    public abstract void получитьЗадачу(String задача); // Абстрактно, без деталей
}

public class Тестировщик extends Сотрудник {
    @Override
    public void получитьЗадачу(String задача) {
        System.out.println("Нашёл 15 багов, из них 14 — критических. Всё нахуй сломано.");
    }
}

public class Менеджер extends Сотрудник {
    @Override
    public void получитьЗадачу(String задача) {
        System.out.println("Задача принята в работу! *ставит крайний срок на вчера*");
    }
}

// А вот полиморфизм в действии, мать его!
Сотрудник[] команда = {new Тестировщик(), new Менеджер()};
for (Сотрудник чувак : команда) {
    чувак.получитьЗадачу("Сделать всё"); // Одна команда, а реакции — овердохуища разные!
}

Четвёртый столп — Абстракция. Это, блядь, высший пилотаж. Когда ты не думаешь о том, КАК ИМЕННО работает двигатель внутреннего сгорания, с его там поршнями, клапанами и прочей хуйнёй. Ты просто знаешь, что есть педаль газа, руль и тормоз. Повернул руль — машина поехала в сторону. Вот эта педаль, руль и есть абстракция. Они скрывают от тебя всю сложную хуетень под капотом. В программировании — это интерфейсы и абстрактные классы. Они говорят ЧТО нужно делать, но не говорят КАК. А «как» — это уже проблема конкретной реализации: будь то бензиновый движок, электромотор или, я не знаю, реактивный ранец.

// Абстракция "Устройство для приготовления кофе"
public interface КофеМашина {
    void сваритьКофе(); // Контракт. Всего одна кнопка. Что там внутри происходит — твои проблемы.
}

public class ДешёваяОфиснаяПомойка implements КофеМашина {
    @Override
    public void сваритьКофе() {
        издатьСтрашныйЗвук(); // Скрытая реализация
        выплюнутьЖидкостьЦветаБолота();
        System.out.println("Готово. Наслаждайся, раб.");
    }
    private void издатьСтрашныйЗвук() { /* ... */ }
}

public class КрутаяИтальянскаяШтука implements КофеМашина {
    @Override
    public void сваритьКофе() {
        бережноПомолотьЗёрна(); // Совсем другая, хипстерская реализация
        создатьИдеальныйКрем;
        издатьБлагородноеШипение();
        System.out.println("Вот ваш эспрессо, синьор.");
    }
    private void бережноПомолотьЗёрна() { /* ... */ }
}

Вот и вся философия, ёпта. Не нужно пытаться объять необъятное и держать в голове всю схему двигателя. Создавай понятные «кнопки» (интерфейсы), прячь внутрь объектов их личные тараканы (инкапсуляция), не копипасть код, а наследуйся от того, что уже работает (наследование), и давай одну команду разным объектам, чтобы они сами решали, как её выполнять (полиморфизм). А если всё это вместе связать — получится система, которую хоть и сложно, но МОЖНО поддерживать, не сойдя с ума. Ну, в теории, по крайней мере.