для C with classes private/public нужно было что бы разделять публичную часть интерфейса от приватной, что мол в заголовочные файлы а что в реализации. А так в том же Си за счет разделения на заголовочные файлы и так с инкапсуляцией все было просто замечательно.

Основная суть разделения - ты изолируешь пакет и поставляешь его в виде динамической библиотеки. и тогда апдейт библиотеки не требует рекомпиляции всего проекта

надо прятать информацию о том как мы с данными работаем а не данные сами по себе

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

оттуда уже необходимость в абстракциях и т.д.

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

Есть инкапсуляция везде тут
Мы тут везде что-то прячем

В одном случае в конструкторе может быть что-то спрятано по части  трансформации данных

В обоих случаях спрятаны правила калькуляции

В случае класса вообще прячем внутрянку фигуры и просто можем работать как с обьектом

да но зачем его прятать?

так, давайте будем разбираться.

есть функции. они принимают на вход данные и выплевывают результат. есть процедуры - они мутят сайд эффекты.

мы инкапсуляции и прочие "data hiding" делаем что бы изолировать сайд эффекты. если сайд эффектов нет - то принципиальной разницы между circle.area и area(circle) нет.

Чтобы скрыть как не важную характеристику при подсчете площади, когда у нас уже есть фигура

есть фигуры, на площадь одной  один параметр влияет, на другую другой , ну и оставим внутри, скроем нюанс

Выставив только метод подсчета площади

И не важно, можем мы смотреть что это: радиус, ширина/высота или гипотенуза

Скрыли  детали для подсчета площади и все, а когда надо препарировать конкретную фигуру — вскрыли детали

вся эта штука с "разделением стэйта" идет не из булшита про "объекты реального мира и его свойства" а из необходимости контроля за сайд эффектами. То что Дейкстра в goto considered harmful описывал

Симула процессы симуляции объектами описывала потому что это был удобный способ привязать "процесс" который ты симулируешь к стэйту этого процесса, за счет этого лучше контролировать сайд эффекты

в этом же была идея smaltalk - резать стэйт на скоупы

короч есть два аспекта которые влияют на декомпозицию системы:

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

к слову подход area(circle) лучше согласуется с open/close и идеей функциональной абстракции 🙂

ну а что до джавы и похапе - вы функции не юзаете не потому что ООП а потому что неудобно сделано. с модулями удобно например.

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

Ок, примем эти ограничения

Но даже с публичным состояниему нас объект — капсула
В иных случаях он предстаёт только как капсула, в других ещё и поведение у него есть
Во всех этих случаях нутрянка скрыта как минимум семантически, раскрыт интерфейс

И даже если нет приватных модификаторов: имея метод, который в себе скрываем вызовы др методов — есть сокрытия и публикация некоторой капсулы (для более явного этого явления и придумали абстрактные классы и интерфейсы₽

и эта капсула может быть просто файлом)

по факту ты "сузил" контекст обсуждения до "похапе". И в этом плане ок, мы просто дали определение классу.

Прикол в том что все это не поможет тебе определить "что должно быть внутри границы а что во вне". Вот это "данные и методы по работе с этими данными" это весело и красиво, но стоит тогда мерять метрику lack of cohesion что бы понять "а не склеил ли ты много объектов в один"

это капсула только если данные меняются только изнутри этой капсулы. условно у тебя "свойства" это просто публичные геттеры. Или ридонли поля. Если у тебя стэйт объекта меняется извне то ты по сути открываешь свою капсулу. По сути нет границ распространения сайд эффектов