Чтобы доступа к переменной не было не из методов класса

А через гет сет типо мы не к этой переменной обращаемся

приватные переменные не наследуются как минимум

Насколько я понимаю это не прямой доступ к переменной, нас в универе учили, что прямой доступ к переменной это плохо. А вообще я джаваскриптёр, там таких вопросов нет

Это бред

Какой непрямой?

ты меняешь через сет её

Ты просто не пытаешься подумать чуть дальше банального класса Cat

Почему, наследуются же, просто к ним нет прямого доступа, но в экземпляре класса они же будут существовать?

Ок, почему бы просто не сделать Field { public get; private set;}

нужно использовать сторонний кривой ломбок

Пример покажешь?

Это был вопрос.

>Почему, наследуются же, просто к ним нет прямого доступа,
звучит как утверждение

Приватные поля класса родителя при создании экземпляра класса наследника занимают память?

Например у тебя поле Map.
Ты можешь подсунуть любую реализацию, не меняя клиента.

Или в обьекте Линия поля длины нет, оно расчитывается по координатам концов, а для клиента оно есть.

И да, если не еужно юзать инструменты, основанные на JavaBeans Spec или тесная связность с клиентом не важна, не будет наследования от класса, нет многопоточного использования объекта, то язык не мешает предоставить доступ к полю напрямую.
Например dto с самописными маперами вполне прокатит при жестком отказе от многопоточного использовпния. Выстрел в ногу будет только в объеме самописного  кода, велосипедящего библиотечный функционал, использующий JavaBeans Spec.

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

Тебе к Егору :)
В @painofoop

Да ООП прекрасно без этого реализуется

Да что к Егору-то, просто иммутабельные объекты использовать (см. как люди живут в той же Скале как правило)