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

#soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwareengineervlog
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/id/5f578bdf22e2...
GitHub - github.com/soerdev
Чат для программистов - / discord
Группа ВК - codeartblog

[@vlr9999]

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

[@GrekovR]

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

[@Lucio11a]

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

[@escaldov5891]

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

[@Son-of-the-God---]

Привет SOER, подскажи, я 20+ лет занимаюсь программирование, у меня так же правый глаз как и у тебя, то ли веко опустилось со временем то ли я его не использую, ты не спрашивал в чем причина? У меня точно такая же ерунда как у тебя, хотя вижу прекрасно им, но он как будто в полусне. Спасибо.

[@skipe12s15]

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

[@Nodorgrom]

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

[@arenroger6507]

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

[@zakharbondarev7814]

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

[@vyacheslavgvorus3883]

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

[@user-np5uh8do2x]

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

[@alexfrost103]

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

[@user-yp9ru8jp4b]

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

[@mikitahimpel3283]

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

[@ananasios]

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

[@UnrealSPh]

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

[@JustPlayingBroGD]

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

[@ikorjefocur]

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

[@vladgromov9213]

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

[@vyacheslavgvorus3883]

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

[@TheProfessionalGambler]

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

[@TheProfessionalGambler]

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

[@ikorjefocur]

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

[@P7Vagrant]

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

[@MELkey3]

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

[@P7Vagrant]

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

[@S0ERDEVS]

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

[@user-np5uh8do2x]

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

[@MELkey3]

@@user-np5uh8do2x вопрос то был не про это

[@romanlunin386]

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

[@mukhamed5405]

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

[@vladgromov9213]

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

[@mukhamed5405]

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

[@romanlunin386]

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

[@UnrealSPh]

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

[@user-np5uh8do2x]

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

[@alexanderdell2623]

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

[@gavr_sas]

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

[@skynowa2626]

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

[@john.darksoul]

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

[@ksviety]

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

[@_mirai]

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

[@ksviety]

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

[@_mirai]

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

[@ksviety]

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

[@user-np5uh8do2x]

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

[@sergeysemkin6570]

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

[@deniskulakov682]

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

[@user-mh3bs5ff1c]

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

[@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 =)

[@g3k0s20]

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

[@BiOS1225]

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

[@MrGhost-bg6ud]

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

[@sergZh78]

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

[@edwinshadian2852]

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

[@Varkatel]

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

[@user-np5uh8do2x]

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

[@user-np5uh8do2x]

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

[@user-np5uh8do2x]

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

[@user-np5uh8do2x]

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

[@user-pn9rm2xr7x]

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

[@user-op3iw4xf5m]

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

[@user-yp9ru8jp4b]

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

[@user-np5uh8do2x]

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

[@alexanderdell2623]

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

[@ievgenk.8991]

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

[@serggorod1423]

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

[@serggorod1423]

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

[@Nextgameoficall]

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

[@vlatterran]

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

[@user-np5uh8do2x]

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

[@user-np5uh8do2x]

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

[@Eugene.g]

база

[@dann1kid]

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

[@hwd1978]

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

[@timurdanilenko3582]

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

[@daniilkoliasnikov6696]

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

[@user-np5uh8do2x]

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

[@Eraston]

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

[@user-np5uh8do2x]

Что ты куришь

[@proKaps]

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

[@dmitryo6153]

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

[@user-np5uh8do2x]

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

[@user-zk4dt2mu9f]

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

[@user-hc1hl2nx8e]

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

[@user-zk4dt2mu9f]

@@user-hc1hl2nx8e я не зря добавил уточнение. С точки зрения пользователя кода.

[@user-hc1hl2nx8e]

@@user-zk4dt2mu9f С точки зрения пользователя кода он исчез, а не стал иммутабельным.

[@user-zk4dt2mu9f]

@@user-hc1hl2nx8e ок, измени тогда состояние обьекта, в рантайме, не вводя методов

[@user-hc1hl2nx8e]

@@user-zk4dt2mu9f так его и прочитать нельзя, не только изменить. )))) Иммутабельность - это не про сокрытие.

[@EdwardNorthwind]

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

[@user-np5uh8do2x]

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

[@user-np5uh8do2x]

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

[@user-np5uh8do2x]

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

[@user-np5uh8do2x]

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

[@romanbush5164]

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

[@gavr_sas]

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

[@who-gh6jt]

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

[@limeniye]

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

[@user-iy9ku8hk3x]

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

[@punks_not-dead]

Проблема не в публичности пременной, а в ее мутабельности.

[@user-np5uh8do2x]

Это инкапсуляция братан

[@punks_not-dead]

@@user-np5uh8do2x При чем тут инкапсуляция? Если бы поле было константой, то никакой случайной переписи значения поля извне не произошло бы: сам компилятор стал бы ругаться или что-то в этом духе. Дело не в приватности или публичности поля. Можно накосячить и переписать в какой-то момент и приватную филду и суть не изменится.

[@user-np5uh8do2x]

@@punks_not-dead Мы в первую очередь должны озаботиться границами использования, а уже потом думать про мутабельность. Если у нас один класс использует мутабельную переменную и изменить её значение в каком-то методе это на порядок лучше, чем если она используется в 10 разных местах. Эти данные не нужны внешним потребителям, а значит значение будет использоваться исключительно внутри класса. И только после того как мы определили границы контекста, мы можем думать о том, является ли эта херня мутабельной в этом контексте. Это вопрос следующего порядка. Да, она должна быть ридонли в данном случае, но это зависит от контекста. Так что пока мы не сделаем её приватной, речи о мутабельности идти не может

[@user-np5uh8do2x]

@@punks_not-dead неправильно определённый контекст куда опаснее того, что в классе есть мутабельная переменная, хоть она нигде и не изменяется

[@user-np5uh8do2x]

А хранение данных там где они используются это и есть инкапсуляция

[@user-rg6dg4ip8b]

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

[@user-np5uh8do2x]

PoEAA

[@dmitriyobidin6049]

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

[@lxgdark777]

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

[@MsTim159]

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

[@user-hc1hl2nx8e]

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

[@edwinshadian2852]

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

[@mantrida]

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

[@mukhamed5405]

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

[@gooseob]

Для примера