Конкретный пример почему в ООП приватные атрибуты лучше публичных

[@vlr9999]

Минуточку, в последнем примере присвоение в биртхдате без подчёркивания, а это другая ошибка

[@GrekovR]

Вот именно, у тебя ошибка о том, что свойства нет, а не о том, что ты приватному свойству хочешь присвоить значение

[@Lucio11a]

Я, наконец, понял, в чем глобальный смысл модификаторов доступа и насколько они могут упростить жизнь, не смотря на то, что кажется, что кода с ними будет в итоге больше. Благодарю! ))

[@zakharbondarev7814]

Молодец. Красиво и приятное подача материалов.

[@escaldov5891]

На 4:39 на вход принимается более широкий набор значений, но на выходе набор сужается, прямо же как в той серии «Симпсонов»! Там ещё Фландерсу дом построили, и он сужался. Короче, ржачная серия была.

[@vyacheslavgvorus3883]

Создаётся впечатление что Соер вновь для себя ООП открыл без палева и тащиться) Да мужик, ООП крутая штука))

[@АлександрП-г3н]

Внезапно видос для самых маленьких

[@ikorjefocur]

Момент! Во многих языках, в том числе js, присутствует такие штуки как геттеры и сеттеры. По сути в любой момент мы можем заменить на них публичное свойство - добавим валидацию, не поменяв публичный интерфейс класса. Соответственно, публичные свойства можно использовать в ситуации, когда необходимости проверять значения нет.

[@vladgromov9213]

В геттер перед выдачей пихать валидацию - да вы батенька извращенец

[@vyacheslavgvorus3883]

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

[@TheProfessionalGambler]

@@vladgromov9213 он ничего не писал за валидацию в геттере

[@TheProfessionalGambler]

@@vyacheslavgvorus3883 точно, нужно учить плюсы, чтобы фронт писать)

[@ikorjefocur]

@@vladgromov9213 Почему в геттер, когда можно в сеттер? Ну а когда не выходит, почему нет? Какие, собственно, альтернативы? Сделать 2 метода в стиле "getValue" и "setValue"? Так это по сути тоже самое, разнится лишь обертка. И первая обертка мне нравится больше. Что же касается производительности на уровне интерфейса, что типа получение значения может ничего не стоить, значит можем хоть 10 раз подряд его использовать как свойство объекта, не запоминая в переменную - в такие моменты нужно вспомнить, что вообще-то публичных свойств изначально быть не должно. То есть да, абстрактному пользователю моего кода придется держать в голове тот факт, что любое readonly свойство является потенциальныи геттером, а просто публичное - сеттером. Для кого-то звучит как извращение, я же считаю извращением писать парные методы с префиксами "get", "set", "recieve", "update" и т.п. плюс имя свойства, когда можно тоже самое сделать на геттерах и сеттерах.

[@arenmkhoyan]

Спасибо, очень понятное объяснение

[@romanlunin386]

Еще в TS есть readonly, к слову о чистоте:) Ведь никто не запрещает так же менять приватные свойства внутри класса.

[@mukhamed5405]

Почти везде использую

[@vladgromov9213]

Да, readonly решает вопрос с одноразовой валидацией и невозможностью изменить параметр. С другой стороны если поле все же должно меняться, например вы можете поменять дату своего рождения в большинстве приложений.

[@mukhamed5405]

@@vladgromov9213 Если поле должно меняться может тогда его сделать объектом и менять его свойство?

[@romanlunin386]

@@vladgromov9213 ну так при каждом изминении тебе нужно создавать новый экземпляр Age. в том числе он является Value Object, которые по определению иммутабельны

[@alexfrost103]

Люблю ваши видео, могу описать свои ощущения о них как "просто о сложном или сложно о простом". Еще заметил - на моменте 10:31 не тот код показан, там где вы в в обход валидации конструктора передаете некорректное значение.

[@edwinshadian2852]

Я понял наконец-то, почему постоянно твердят - делайте свойства приватными. Теперь понятно, что не из-за желания наштамповать геттеров/сеттеров по методичке. Автору респект и спасибо!

[@Varkatel]

о, давайте нафигачим публичные сеттеры, так точно никто не сможет изменить приватное поле или нет?

[@АлександрП-г3н]

@@Varkatel ахахахаха да. Если бы не придумали аббревиатуру pojo, то даже за умным термином было бы не спрятаться

[@АлександрП-г3н]

@@Varkatel а с пожо можно не рефачить. Изи пизи

[@АлександрП-г3н]

@@Varkatel как же ревью затягивается когда челики вместо того чтобы положить код рядом с данными которые он использует отвечали «это же pojo»

[@АлександрП-г3н]

@@Varkatel и вот, ты сидишь и вместо работы пишешь им лекцию про ооп

[@john.darksoul]

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

[@ksviety]

еще и в конструкторе...

[@_mirai]

​@@ksvietyа где ещё делать валидацию данных?

[@ksviety]

@@_mirai в месте использования (методе)

[@_mirai]

@@ksviety ну таких мест же может быть несколько, правильно? Получается везде нужно дублировать валидацию. Зачем это нужно, если можно это сделать один раз в конструкторе?

[@ksviety]

@@_mirai для этого можно сделать объект, который будет инкапсулировать данные и валидировать их, и использовать его, потому что такая валидация может понадобиться не только в конструкторе этого объекты, но и в других

[@Nodorgrom]

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

[@КириллЕвгеньевич-п4ъ]

Нормас) глянул с племяшей - спасибо за проделанную работу! Но вопрос: зачем постоянно закрывать вим?) пы.сы. за фиш - респект)

[@АлександрП-г3н]

Он зачем-то в новом файле делает всё

[@skynowa2626]

Капитан-привэйт-очевидность

[@UnrealSPh]

Ну то что хочет сказать автор в целом то понятно, но вот выводы которые он сделал могут быть ошибочными. И тут надо понимать след: 1. Принципы != законы. Их применение должно упрощать жизнь, а не усложнять. У вас всегда должны быть чёткие причины делать/не делать что-то. Потому что без этих причин вы просто избыточно усложнить программу 2. Видео никак не поможет новичку понять когда нужно скрывать реализацию, а когда не нужно. На самом деле тут вопрос баланса. Вы держите в голове каков жизненный цикл кода, который вы пишите, а также степень его открытости, в зависимости от того какое кол-во людей будет непосредственно с ним работать. Пример автора не имеет смысла в том контексте, который он обресовал. Другими словами сам придумал проблему, сам её решил. В js при желании можно переписать метод снаружи, передав новую функцию. Скажете что это уже совсем бред? Ну по мне такой же бред что человек передаст в переменную которая имеет хорошее имя не правильное значение. А если у нас работает ворскейс анализ, то лучше сразу писать высокопроизводительный. 3. Ещё главный вопрос в целесообразности. Ситуация, когда код - часть большого интерпрайза или библиотеки от которой зависит +100500 других проектов в мире, и совсем другое это какой нибудь ваш mvp на коленке который умрёт через пару месяцев из за недостатка финансирования. А ещё есть разница когда автор кода твой коллега который сидит рядом и чувак из другой страны. Сложность кода это не константа и не единая линейка. И реальная инженерная задача это правильно сбалансировать проект чтобы его качество было прямо пропорционально трудозатратности создания и поддержки.

[@АлександрП-г3н]

2+. Скока ж тут комментов про ридонли пхпхп

[@sergeysemkin6570]

Всё понятно, всё по факту, но чёт затянул, как мне кажется с итогом. Ну а так моё почтение

[@JustPlayingBroGD]

Хорошее объяснение, спасибо )

[@skipe12s15]

А в чем проблема сделать getter setter для birthDate? Валидацию используйте в setter

[@BiOS1225]

Заголовок видео сильно смутил. После C# чётко разделяю поля и свойства (с get/set). Так вот публичные свойства лучше, чем поля. Оказывается тут речь была про поле

[@MrGhost-bg6ud]

Да, автор называет поля свойствами. Вероятно это зависит от языка.

[@sergZh78]

Да, в C# это решается через сеттер, геттер, если без фанатизма. В моем проекте есть геттеры где задействован даже контекст бд, это конечно уже жесть.

[@КириллЕвгеньевич-п4ъ]

Думаю, многим было бы ещё интересно послушать про рефакторинг: чарн рейты, код смэйлы, оптимизацию (общие подходы, типа профилирования и т.д.), в том числе про преждевременную; возможно линтеры и другие плюхи страхования от болезней... :) Но в любом случае - Спасибо! Возможно, дело моих слов основывается уже на какой-то компенсации потраченного времени, но мало ли, появится энтузиазм...или на коммерческой платформе - в любом случае, надеюсь, что дал правильный совет :) Удачи!

[@mikitahimpel3283]

А вам не кажется, что неявное преобразование типа к строке с помощью конструкции ` + '' ` не лучший пример? Особенно для новичков, которые это посмотрят, а потом будут вместо `.toString()` иcпользовать ` + '' `.

[@ananasios]

Так раскрывалась тема то: для чего публичные и приватные свойства нужны, а не как правильно приводить number в string.

[@UnrealSPh]

Забей) автор объяснил одну тему и запутал несколько)

[@P7Vagrant]

Всегда считал плохим тоном вызывать исключения в конструкторе. Когда объект ещё вроде бы не создан, но уже какую-то память начал занимать, а у нас уже возникает исключение. Сойер, как вы к этому относитесь? Придерживаетесь ли таких же взглядов или считаете что в этом нет ничего страшного? Возможно, есть какие-то рекомендации по работе с конструктора классов?

[@MELkey3]

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

[@P7Vagrant]

@@MELkey3 Звучит логично. Но именно так как вы описали, работает не каждый язык программирования. Впервые я услышал такие утверждения (про плохой тон, делать исключения в конструкторе), от Java разработчиков. Сам я на этом языке не программирую, но если есть здесь джависты, будет интересно узнать их мнение. От этого и пошло такое убеждение по работе с исключениями в конструкторе. И перекочевало на остальные языки программирования. Поэтому, я не исключаю что это может привести к утечке памяти или другим малоприятным и труднозаметным вещам.

[@S0ERDEVS]

Ответил в телеге - t.me/softwareengineervlog

[@АлександрП-г3н]

Сделай шаблонный метод ¯\_(ツ)_/¯

[@MELkey3]

@@АлександрП-г3н вопрос то был не про это

[@deniskulakov682]

Минус 1970 потому что когда создаётся дата из разницы дат снова прибавляется 1970, если кто не понял.

[@daniilkoliasnikov6696]

Провокационный заголовок, а качество контента, как у Евгения Попова. Приватные поля не могут быть лучше публичных. Это просто разные уровни доступа. Все зависит от методологии разработки и договоренностей внутри команды. Спойлер не во всех языках, в тестах можно получить доступ к приватным полям.

[@АлександрП-г3н]

Кстати, ни разу не возникало необходимости получать доступ к приватным полям. Вообще не понимаю зачем туда лезть из теста

[@alexanderdell2623]

Можно примеры на жаве/сишарп,а не тс?Немного непонятный синтаксис

[@gavr_sas]

тут токо 2 отличия, 1 - type X = string это просто алиас для типа, 2 public в парамтрах конструктора это синтаксический сахар чтобы не присваивать в самом конструкторе this.x = x

[@Вальдес-з7й]

Ну так можно же проводить валидацию в сеттере, в чем проблема? А то получится лютый гемморой с аллокацией обьектов под каждое новое значение

[@g3k0s20]

Спасибо за инфу. Мне кажется, что-то с картинкой, будто дымка

[@alexanderdell2623]

Больше про ооп

[@РусланМартынов-ю6э]

Только это не свойства, а поля

[@serggorod1423]

14m44 мало, все интересно, попробуйте объединять по 2 ,минут до 25... 30 !

[@АлександрЛобович-б5я]

Такой вопрос: в конструкторе происходит валидация, но это не избавляет от необходимости верно ввести данные. Значит где-то должны быть проверены данные (в случае приведенного примера - это дата) прежде, чем передать их в конструктор. Значит всё равно нужна предварительная валидация. Верно? Будет хорошим решением в таком случае: у классов делать публичные методы (статические, например), которые проверят валидность, а потом передавать конструктору валидные данные?

[@musikuma8424]

И что делается в случае невалидных данных? Исключение? Если вы про коррекцию входных данных, то да, её надо делать после получения ввода, а не при создании объекта.

[@bdick8136]

Валидация в конструкторе вообще такая себе идея. А если данные не прошли валидацию, то что у меня будет? Объект с невалидным состоянием? А если у меня создается миллион таких объектов? А если я память как то по хитрому аллоцирую под такие объекты и какие то из них не создались (тут зависит от ЯП многое)? Ну куча вопросов в общем остается. Пример учебный и не стоит его воспринимать всерьез. Главное на примере показали то, что хотели показать.

[@musikuma8424]

​@@bdick8136 В C++ объект создан не будет. Про аллокацию есть что-то вроде линии Калба (транзакции, безопасные исключения, kzbin.info/www/bejne/hmKvlIqda7Bmjac 1:22:45)

[@MELkey3]

@@bdick8136 Валидация это громкое слово, понятно что она не должна быть в конструкторе минимум потому что это не ответственность самого типа), но банально проверять на null в конструкторе надо

[@bdick8136]

@@MELkey3 Я считаю, что валидация или null’checking данных в конструкторе плохая идея и вот почему. Когда я создаю объект, то ожидаю, что объект будет создан в каком то валидном состоянии и я смогу с ним что то ПОЛЕЗНОЕ сделать. В случае если валидация в конструкторе не прошла, то я получу не жизнеспособный объект и мне надо будет как то его состояние дополнительно проверять при работе с ним. ИМХО будет правильным валидировать входные данные конструктора ДО вызова того самого конструктора. Если данные не прошли проверки - объект не создается и это логично. Особенно когда я создаю миллион объектов и какие то из них будут плохие? Это совсем никуда не годится. Ну кто то скажет, что можно кинуть эксепшен из конструктора, а я скажу что это самое плохое, что можно сделать в такой ситуации. Эксепшены, их обработка, ведет к раскрутке стека, а это МЕДЛЕННО в однопотоке и еще АСТРОНОМИЧЕСКИ ЧУДОВИЩНО МЕДЛЕННО во многопотоке так как что бы раскрутить стек придется синхронизировать ядра с кэшами. Уже не говоря о том, что память под объекты должна быть аллоцирована (эксепшены в конструкторах могут еще и фрагментацию памяти увеличить в случае срабатывания эксепшена), что само по себе не быстрая задача. Я понимаю, что сферы деятельности у нас скорее всего разные и я скажу за себя (я в геймдеве занят), что если я хочу в конструктор передать данные, то их валидацию буду делать ДО вызова конструктора что бы избежать двух выше описанных проблем. В вебе мб принято валидировать в конструкторах с эксепшенами. Там лишние 100мсек задержки роли особой не играют мб. С валидацией внутри сеттера никаких проблем не вижу. Здесь под вариацией я имею ввиду еще и null'checking. За ранее извиняюсь за текст - пишу с Nokia 3310 =)

[@Eraston]

О, public vs private. Вообще говоря, ООП - это тоталитарный тоталитаризм, который делает красным даже то, что должно быть чёрным или зелёным. Сущность установки данных вообще является входным коннектором взаимодействия, который один. И если в этот коннектор поступает информация, противоречащая сущности класса, то это проблема не этого класса, а того, кто к этому коннектору привязывается. И ограничивать private-ом нужно не поля класса, а организовывать доступ к этим полям квалифицированным классам, которые в курсе что туда можно записывать и как. А чтобы не случился ***ах, на этапе отладки организовать механизм постановки лимит-значений. Короче говоря, как происходит сейчас: есть ящик, в который могут накидать кто угодно и что угодно. И в ящике даже могут стоять сложные фильтры и устройства, которые весь ненужный хлам уберут. Зачем, когда можно ограничить доступ неучам к ящику, которые не понимают, что туда можно запихивать, и оставить это дело профессионалам, - ограничить область видимости переменной для всей программы, за исключением квалифицированных классов.

[@АлександрП-г3н]

Что ты куришь

[@Testtsettest]

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

[@АлександрП-г3н]

Ну есть не только дураки, но и джуны

[@АлександрП-г3н]

Можно чёнить по архитектуре и не для самых маленьких?

[@ievgenk.8991]

Иммутабельность в помощь?

[@dann1kid]

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

[@serggorod1423]

Хорошо но мало!

[@Eugene.g]

база

[@Nextgameoficall]

а нельзя проверку запихнуть в конструктор? зачем отдельное ветвление? Чтобы что?)

[@vlatterran]

Затем чтобы не перегружать конструктор. В коде конструктора тебе важен сам факт валидации, а не то, как конкретно валидируются данные

[@АлександрП-г3н]

@@vlatterran Зачем он сначала присваевает грязное значение и потом вытаскивает его в валидаторе объясните мне тупому

[@АлександрП-г3н]

Я бы в шаблонный метод запихал вызов валидатора и в валидатор передавал аргументы

[@proKaps]

Зачем такое развертывание кода? Пытаешься прочесть как-то поискось, потом становится на весь экран, потом читаешь, и он опять уходит. Глаза ломаешь только. Если хочется показывать лицо, то можно сделать просто в углу где-то

[@romanbush5164]

Зачем постоянно пользоваться vim. При работе тоже используешь 🤣

[@timurdanilenko3582]

Хоспади, да дайте нам в 1С хоть ООП из питона...

[@ЕвгенийАвдеев-и6п]

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

[@РоманВойтук]

Где это он стал иммутабельным? Просто ограничил тех кто может изменять и читать. Иммутабельность - это немного про другое.

[@ЕвгенийАвдеев-и6п]

@@РоманВойтук я не зря добавил уточнение. С точки зрения пользователя кода.

[@РоманВойтук]

@@ЕвгенийАвдеев-и6п С точки зрения пользователя кода он исчез, а не стал иммутабельным.

[@ЕвгенийАвдеев-и6п]

@@РоманВойтук ок, измени тогда состояние обьекта, в рантайме, не вводя методов

[@РоманВойтук]

@@ЕвгенийАвдеев-и6п так его и прочитать нельзя, не только изменить. )))) Иммутабельность - это не про сокрытие.

[@EdwardNorthwind]

Ага, хочешь писать immutable классы, а тут приходят framework'ки и ORM'ки, и требуют конструктор без параметров, геттеры и сеттеры.

[@АлександрП-г3н]

Просто не делай immutable объекты в ООП) Just dont. Раз у тебя пришла туда ормка, то это уже никак не immutable объект. Его жц менеджится фреймворком/орм. На кой его делать иммутабельным? Скорее всего у тебя в прилоге говнокод. У тебя есть дтохи и энтити. Нет доменной модели. Соответственно между сервисами перекидываются либо дтохи либо энтити. И вот ты ломаешь голову как же сделать эти объекты иммутабельными чтобы не было ситуации, когда то, куда ты передаёшь энтитю меняло её состояние. Соответственно твоё приложение придерживается не ООП подхода а ФП. Просто посмотри на то что у тебя все объекты в прилоге это POJO, а логика хранится в сервисах. И вот ты в ооп языке отделяешь данные от поведения и думаешь от чего у тебя говнокод. Ты тупо инкапсуляцией не пользуешься. Чекни PoEAA

[@АлександрП-г3н]

Так, чуть уточню про иммутабельные объекты. Их можно, но это называется Value Object и кроме иммутабельности к ним применимы другие ограничения. Например то, что их ЖЦ полностью менеджится родительским объектом. Так что пока не раскуришь фаулера, про иммутабельные объекты просто забудь. Максимум иммутабельные мапки/туплы, которые инициализируются на этапе стартапа (в остальных случаях это такие же Value Objectы и для них лучше создавать отдельные обёекты, вроде timestampа в видосе выше) и то 300 раз подумай, а надо ли оно тебе

[@АлександрП-г3н]

Сеттеры там не обязательны. Можно настроить ORM так, чтобы через филд маппилось. Это будет правильнее, если доменная модель

[@АлександрП-г3н]

a.k.a. рефлексия

[@gavr_sas]

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

[@hwd1978]

Что за текстовый редактор? Не похож на vim.

[@who-gh6jt]

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

[@limeniye]

публичные/приватные атрибуты? Может быть члены типа?)

[@ЕвгенийКозлов-у4л]

Еще лучше было бы вынести проверку в класс / тип Timestamp. А то для каждого класса, который использует TImestamp нужно писать свою валидацию, которая будет повторятся. Также, не желательно кидать Exception в конструкторе. Лучше чтобы его кидал Timestmap при попытке доступа к данным

[@ЕвгенийСитников-ц4з]

Что вы там курите, чтобы это понимать... Небожители)

[@АлександрП-г3н]

PoEAA

[@dmitriyobidin6049]

Не все вещи заслуживают такого дотошного подхода, как архитектурные видео. Приватные свойства - одна из таких вещей :) Блин, как же ужасно в JS работать с датами... Даже в таком маленьком примере можно нагородить кучу ошибок. Да и с неймингом я бы получше поработал. birthDate типа timestamp, который на самом деле не таймстемп, а просто количество секунд с какой-то даты :) А как тогда нам завести человека, родившегося до 1970 года, если отрицательные даты нельзя? А, погодите, это ж не дата, это дельта от какой-то даты. А значит уже можно отрицательные значения :)

[@MsTim159]

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

[@РоманВойтук]

Ты как минимум пропустил важный закон Постела "будь консервативным к тому, что делаешь, будь либеральным к тому, что получаешь от других" он это в контексте валидации говорил, но применение гораздо шире. Затем он указал причину разделения валидации и обработки (SRP). Затем важный принцип разделения на "чистые" и "грязные" данные. Очень годное видео. Может стоит выделять все эти штуки, а то новички не замечают деталей.

[@edwinshadian2852]

И все это про модификацию извне и принципы ООП звучит, как 10 заповедей. Вроде и правильно, а вроде и непонятно зачем, а значит - можно положить на некоторые. Мантрами про принципы, паттерны и тд сыт не будешь, пока не поймешь, а зачем оно все надо. В видео, по крайней мере, объяснили для новичков, вроде меня, зачем оно действительно нужно, как и зачем применять.

[@lxgdark777]

Ужасный пример вообще не являющийся аргументом против публичных свойств. Как уже отметили ниже, конкретно в этом примере все решается заданием полю модификатора readonly. И это гораздо логичнее, так как я кроме результата в виде возраста могу захотеть вывести и значения дня рождения. Вообще ваши рассуждения применимы к конкретному языку, а не ООП как к таковому. Например в .Net свойство класса априори не будет приватным, так как в том его и суть, чтобы получить к нему доступ из вне. Если мне нужен некий буфер с данными результатами вычислений, то это приватная переменная. То бишь тут даже диалектика иная чем у вас. В общим ролик вводящий в заблуждение своим названием!

[@mantrida]

У меня только один вопрос возник. Зачем писать myAge.birthDate = 999999999999999999999999999999; ??: )

[@mukhamed5405]

Да) нужно было _...

[@gooseob]

Для примера