Ответ на пост «Поговорим про ооп»⁠⁠1

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

Чем класс в данном контексте отличается от функции? У класса есть свойства и методы. Это такой свод правил для каждой специальности - для бетонщиков, для штукатуров, для маляров - для каждой специальности отдельно. Когда вы нанимаете пять маляров, вы создаёте пять экземпляров класса маляр. У класса есть свойства. Это например возраст маляра, его рост (мелким малярам сложнее работать без стремянки), вес (некоторым малярам возможно понадобится более основательная стремянка), имя и например оклад. Набирая пяток маляров свойства у каждого из них будут отличаться и как говорит известная телеведущая - это нормально. А вот методы работы у них должны быть строго одинаковые!

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