Главная ошибка новичков в ООП!

А вы встречали такое понимание инкапсуляции?
C# Medium от Junior до Middle - ijunior.ru/csha...
БОРИС (Бесплатное Обучение Разработки Игр) - ijunior.ru/bori...
МОЯ КНИГА - csharpbook.saku...
ГРУППА КАНАЛА - holymonkey
ШКОЛА ПРОГРАММИРОВАНИЯ ЯЮНИОР - holymon...
Я В VK - rsakutin
INSTA - / sakutinhuytin
ЧАТ В ТЕЛЕГЕ - t.me/csharp_fa...

[@avraamlin7022]

видео можно было сделать короче фразой- "Нет времени объяснять просто купи курс медиум c#"

[@crn05]

я медиум c# в 3м поколении, карты подсказывают мне, что ваши классы плохо инкапсулированы, беда ждет вашу программу. С вас 100$

[@volodymyrtsaruk8055]

Я включил это видео узнать главную ошибку, а воды у меня дома и так достаточно

[@proleternal]

То, что ты не понимаешь слово "инвариант" и другие термины ооп - это только твоя проблема

[@mantrida]

Инкапсуляция - это защита. Вот он уровень понимания ! Скорей бегите покупать курс.

[@VoidPtr]

3 вариант способен знатно выбесить тех, кто будет с таким кодом взаимодействовать

[@funnyvalentine8738]

Забавно, сколько не смотрел видео от Романа, не понимал особо ничего, пока не начал непосредственно кодить и пытаться реализовать классовую иерархию в своём проекте. И в один всё стало ясно, и про сокрытие, и про инкапсуляцию, и почему все три скрина одинаковые, и как писать нормалтно

[@vinik_tfo]

Нихрена эти классы не одинаковы, различия проявят себя после создания производных от них классов. эдит: Ты, Роман, молодец, но покупать я курсы, конечно же, не буду.

[@toxicknight3079]

Речь же была, что они будут одинаковыми для пользователя, когда он будет оперировать с экземплярами этих классов.

[@rsakutin]

В чем будет разница при наследование?

[@vinik_tfo]

@@rsakutin если не ошибаюсь, то можно будет при надобности переопределить свойства и методы, в которых хранится логика

[@rsakutin]

@@vinik_tfo Нет, они же не виртуальные :)

[@vinik_tfo]

@@rsakutin мда, туплю как никогда, в любом случае, это была лишь реклама курсов?

[@justcore]

Что-то нет у меня никакого желания учиться по этому курсу.

[@Gromitinc]

Ну нету и нету

[@AtlanticCG]

Ну почему люди так предвзято относятся к истеричным высокомерным сучкам?? Они же тоже люди! А ну купи курс быстро!!! :D

[@andrewmolotkoff4231]

@@AtlanticCG Самый недооценённый коммент...

[@AtlanticCG]

@@andrewmolotkoff4231 не не, это самый недооцененный курс!

[@andrewmolotkoff4231]

@@AtlanticCG Хорошо сказал!

[@mvgreen4509]

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

[@stolentine]

Увы видео поймет только тот кто уже умеет в нормальную инкапсуляцию. Надо было пример методов привести изменения состояния

[@toxicknight3079]

Чет все равно не особо дошло. Жаль в конце нет примера класса с инкапсуляцией.

[@Kenflesh24]

Это тупо байт на покупку

[@consoleapp1527]

Toxic Knight а ты купи курс - узнаешь

[@aaymax]

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

[@OOOJohnJ]

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

[@ИапГоревич]

Имеется в виду, может быть, что _int money - "любое" целое число, но деньги в настоящей жизни - Неотрицательное число, так что не один из них не имеет инкапсуляцию(Но я не уверен, Повторюсь)

[@eugene8863]

@@ИапГоревич опять же реальная жизнь и программа это разные вещи, интерфейса где было бы описано что эти деньги не могут быть отрицательными мы не видим, а значит они могут быть отрицательными и человек выше всё правильно сказал))). Интерфейса в плане того что это реальные деньги, вообщем каких то их значимых характеристик.

[@crn05]

@@ИапГоревич заведите кредитку, и узнаете, как деньги могут быть отрицательными

[@ИапГоревич]

@@crn05 Это уже другая сущность

[@vasilevsky_a]

@@crn05 так деньги на кредитном счете всегда положительные тоже. Допустим у тебя кредитная карта с лимитом 100000, ты тратишь 5000 и потраченная сумма отнимается с твоего кредитного счета, но все равно остаётся неотрицательной(в примере 95000). нельзя превысить лимит, иначе в операции будет так же отказано как и с использованием обычной карты на которой недостаточно средств.

[@НиколайТорощин-е6э]

Это что было? Обычно пояснение нормальное примеры... А это что? Такими темпами можно будет отписываться от канала... Пока просто дизлайк... Реально можно было простого сказать: - "купите курсы, и бла бла бла".

[@CultureofSpeech]

Чудесно звучит 🎉 А когда будет продолжение этой темы разговора ⁉️🤔

[@saint8283]

Короче надо свой канал создавать. А то что-то очень мало реально полезной информации. В основном одна попса, оторванная от реальности.

[@Tornado-ln7fq]

Инкапсуляция- это Капсула в капсуле,еще называют подзорная труба,или тип матрешки.Вот и все)

[@alexanderrrurrer9072]

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

[@Nidere]

т.е. ты хочешь сказать, что примеры на видео не идентичны?

[@ИапГоревич]

@@kaas228 Так в Википедии написано, вроде бы, но я не уверен

[@Nidere]

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

[@Nidere]

@bitmap ты с голосами в голове споришь? Потому что мы обсуждали ООП и инкапсуляцию, и идентичность вариантов с т.з. ИНКАПСУЛЯЦИИ. При чем тут твоя рефлексия, которая инкапсуляцию на болте крутит, ломая ООП во все дыры? Охрененно ты привел пример, что "проперти нужны чтобы добавить валидаторы" в ответ на тезис об идентичности открытых полей и пропертей БЕЗ ВАЛИДАТОРОВ Пей таблетки короч

[@princessmary5556]

@@Nidere Что такое "карго-культ" ?

[@travoltik]

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

[@fullboarduck5491]

Всё понятно, действительно думал не так, спасибо

[@ЮрийШпорхун]

Внезапно, тут все неплохо. Обычно я и ожидаю услышать - "защита инвариантов", а то разведут помои по поводу сокрытия или связи данных и поведения (что является только методами обеспечения данной защиты).

[@Pepper-Vaseline]

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

[@princessmary5556]

Верно. Инкапсуляция - это просто изоляция деталей реализации от клиентского кода. Инвариант - свойство функции (класса/модуля) сохранять работоспособность вне зависимости от корректности вызывающей стороны. Грамотная инкапсуляция - один из способов, позволяющий обеспечить грамотный инвариант.

[@ИбрагаХаликов]

Спс коментам , сохранил свое время

[@kirillfedorenko5325]

Спасибо что предотвратили мне самую главную ошибку новичков в ООП

[@pandalove6795]

Привел бы правильным пример хотя бы. Почему 3 не инкапсулированый пример? В полне в геттерах и сеттерах можешь делать с value что ты хочешь. Проверять, менять и тд. А пользователь об этом не узнает.

[@toxicknight3079]

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

[@pandalove6795]

@@toxicknight3079 да но в то же время только в 3 пример можно было добавить сразу что-то в геттеры и сеттеры а так да логично что нет нигде инкапсуляции. Одно и тоже происходит

[@toxicknight3079]

@@pandalove6795, во 2 примере тоже можно добавить что-то в get и set.

[@pandalove6795]

@@toxicknight3079 ну эт да

[@OOOJohnJ]

третий пример - развёрнутая форма второго

[@hardlandingtac]

Есть на моем канале ролик под названием "К чему приводит тотальная инкапсуляция?", думаю те кто не хотят покупать курс от Романа - могут его посмотреть бесплатно :) там на пару часов с примерами ... сам Роман меня периодически подбешивает, но это короткое видео ему удалось ... тут он полностью прав

[@vladoss4643]

Можно про абстракцию поподробнее?? Это вы о чём? Что за абстракция, которая позволяет менять приватные поля?

[@elteranos1452]

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

[@stanislavsh6582]

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

[@princessmary5556]

Бред.

[@viv3000]

мне кажется или роман в примера показал классы шредингера? Их в одном случае можно назвать инкапсулированными а в другом нет

[@vr29645]

С каких пор отсутствие сокрытие данных приравнивается к отсутствию инкапсуляции?

[@Вячеслав-ф2ю6и]

Первое видео, что увидел на твоем канале. Не подпишусь.

[@andriyborukh8076]

Ух тут Полыхнуло! ) Да реклама неплохая. а идея тут проста, инкапсуляция должна быть именно отделением реализации класа от другого кода ( если говорим о ООП язике. Та же инкапсуляция может быть и в модульном програмировании и в других парадигмах) а не гетерами и сетерами. По сути инкапсуляция предоставляет возможность отгородить реализацию класа от другой части программы предоставив интерфейс для взаимодействия между класом и другими частями вашей программы.

[@princessmary5556]

Инкапсуляция никому ничего не должна. У вас очень неграмотная речь. Вы не русский?

[@andriyborukh8076]

@@princessmary5556 просто раскладки русской не было

[@AlexBrainhow]

Вот это кликбейт, вот этого я не ожидал

[@НейтральныйМаппер-з2м]

СПАСИБО ЗА КОММЕНТЫ ААХААХАХА

[@kandreyk9159]

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

[@faseplay.]

Скорее да, чем нет. Инкапсуляция - защита полей и свойств объекта от внешнего неправильного использования. Если, например, к имени есть ограничения, нарушение которых может нарушить работу программы, то они должны быть описаны в методах get и set.

[@princessmary5556]

@@faseplay. Никому они ничего не должны. Вы неверно понимаете предназначение инкапсуляции.

[@AnaLIntrudeRR]

Вообще автор сам не понимает, что есть инкапсуляция, ибо он считает, что она появляется только, когда данные в поля класса записываются не в первозданном виде, а как-то перед этим меняются или опосредованно меняют поля класса. Инкапсуляция это объединение данных и методов для работы с ними в один объект, все. Не важно что эти методы делают и как. Хорошо это показывает разница между типом struct и типом class. Поэтому можно сказать, что не используется инкапсуляции только в первом примере. Ибо нет методов, только данные. И то, если туда же перетащить методы из третьего, то внезапно она появится. Да, не будет сокрытия, потому что поля публичные, и методы будут бессмысленными, но это никак не умаляет применение инкапсуляции. Поэтому вопрос не в том, есть она или нет, в любом классе она по опредению есть. А в том, чтобы показать грамотный пример ее применения.

[@princessmary5556]

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

[@AnaLIntrudeRR]

@@princessmary5556 Речь идет о парадигме ооп, которую все умные дядечки выделяют именно, как свойство ооп, не присущее той же процедурщине. Поэтому и определение я дал именно в контексте ооп. А если само наличие функций/методов считать инкапсуляцией... ну, так тоже можно, наверное. Тогда инкапсуляция и повторное использование кода, как парадигмы, можно вообще опускать и никогда не упоминать, потому что это уже зашито вообще во все языки программирования в той или иной форме.

[@princessmary5556]

@@AnaLIntrudeRR Нет, когда речь идет конкретно об инкапсуляции, то речь идет именно об инкапсуляции, а не о "парадигме ооп". Не выдумывайте чушь. Само наличие функций/методов не является инкапсуляцией, потому что само по себе их наличие ещё ничего не инкапсулирует. А идея повторного использования кода вообще не является парадигмой. Вы, пожалуйста, немножечко порядок наведите у себя в голове.

[@princessmary5556]

@@AnaLIntrudeRR Вы сами поняли, что за чушь написали? *Речь идет о парадигме ооп, которую все умные дядечки выделяют именно, как свойство ооп* С ваших слов, умные дядечки выделяют парадигму ооп как свойство ооп. Тут одно из двух: либо умные дядечки забыть принять свои таблетки, либо вы написали чушь.

[@DroidChannelify]

Сударь вы ошибаетесь в своих суждениях.

[@dimav1640]

так а че, как по мне очень даже полезное видео

[@Filimon_enc]

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

[@TheStalkerWest]

к примеру, свойство public int Money { get; private set; }, будет инкапсулировано?

[@rsakutin]

Да, но например такое public ReferenceType Property { get; private set; } Уже нет Как и такое например public int[] UnitsHealth { get; private set; }

[@TheStalkerWest]

@@rsakutin Получается для ссылочных типов не действует инкапсуляция?

[@rsakutin]

@@TheStalkerWest Действует. Просто её не достичь закрытием сеттера.

[@TheStalkerWest]

@@rsakutin Окей, спасибо, не знал этого.

[@kirillsviderski4739]

@@TheStalkerWest действует. Но инкапсуляция это не написание public/private.

[@alexkoda6472]

Длина видоса 322, тут все понятно

[@mrmelog4320]

И это весь ролик??? Я думал ты хоть покажешь что такое настоящая инкапсуляция.

[@jtdstudio1729]

В чём суть этого видео? Здесь нет урока от слова совсем

[@oygan100]

Роман вам тему говорит. Сам программирую более 10 лет. В ООП инкапсуляция это самое ценное.

[@princessmary5556]

Именно в ооп?

[@artimka68]

@@princessmary5556 А как инкапсуляция может быть без ООП?🙃 Вообще большинство больших программ пишутся ООП, а C#(примеры в ролике на этом языке) - это вообще весь ООП ЯП.

[@princessmary5556]

@@artimka68 Раз вы задаете такой вопрос, значит вы вообще не понимаете, что такое "инкапсуляция". Вам нужно сначала разобраться с терминологией. Попробуйте прямо здесь, в комментариях сформулировать определение понятия "инкапсуляция". А после того, как вы поймете, что такое инкапсуляция, и для каких целей она используется, у вас уже подобные вопросы отпадут сами собой.

[@artimka68]

@@princessmary5556 Инкапсуляция - способ формирования элементов в ООП, состоящий в ограничении внешнего доступа к данным и обьеденении данных с методами. Но возможно я понял вашу мысль, вы хотите сказать что "инкапсуляция" это что то глобальное? Но я не представляю инкапсуляцию без ООП и функций.

[@princessmary5556]

@@artimka68 Вы написали бред. Инкапсуляции вообще не имеет к ооп никакого отношения. А кроме того, "объединение данных с методами их обработки" - это концепция оопнутого класса.

[@TurovodSPB]

Последняя конструкция вообще, как оправдание использования прайвед полей. Бессмысленно. Все просто. Поля прайвед, конструктор, свойства геттеры. Вот и вся инкапсуляция.

[@kostenkoff]

а пример?

[@redunit629]

думал будет что-то полезное (

[@zzz3781]

Ты не можешь одинаково изменять, тк в гетере и сетере могут быть разные ограничения

[@rsakutin]

В данных примерах ограничений нет

[@wydiwys]

@@rsakutin но и примера где ограничений нет но оно инкапсулировано нет тоже...

[@omoloni]

@@wydiwys он же сказал что этого быть не может

[@menelai6306]

Ром, я у тебя видел видос по WinForms где ты делал типо клон ОСУ за 30 минут. Не хотел бы сделать подобное но с игрой Трон (там где светоциклы гоняют по полю типо змейки). В ютубе на русском я подобного не нашёл , а с форума копипиздить без каких либо комментариев трудновато да и менее полезно думаю.

[@ivankupnevskij4370]

блин, коментаторы, да что ж вы прицепились к рекламе в конце?? Роман правильно все сказал. Идея в том, чтобы донести СУТЬ а не ФОРМУ принципа (в данном случае инкапсуляции). Тоесть эти 3 куска кода реально по факту ничего не скрывают, защищают, проверяют (что предпологает инкапсуляция) - они просто предоставляют полный доступ к данным. И ПОДОБНЫЕ заблуждения в ООП весьма критичны и стоит обратить внимание на них.

[@saharaprotocol]

повыё6ывался, молодец.

[@marfuton]

Зач АСМР?

[@sergeibelko9908]

Ответил правильно (никакой), т.к. здесь все public и все изменить можно (в 3-ем примере тоже через методы). Но я всегда воспринимал инкапсуляцию как сокрытие реализации класса или метода от внешних вредителей.

[@princessmary5556]

Вы точно не путаете понятие "сокрытие" и "изоляция" ? Сокрытие - это например, идиома pImpl. А если данные ни от кого не скрываются, а просто расположены в private, то это не сокрытие, а изоляция.

[@lufog]

Орнул, спасибо.

[@ilya_fimin]

Ну...

[@caffeinejavacode1475]

как ты изменишь name, money если они private

[@omoloni]

через метод

[@НикитаВасилевич-ж6х]

Не ну пиздить идеи с extreme code такая себе идея.

[@rsakutin]

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

[@rsakutin]

Собственно нашёл, посмотрел. Я хорошо отношусь к авторам ExtremeCode но у них определение в большей степени тоже про модификаторы и упаковку. Спиздил не спиздил решайте сами но учтите что я вещаю про другое.

[@Ananas0902]

@@rsakutin расслабься, мужик. Всегда найдется тот кто решит доебаться ради того что бы доебаться. Научись их игнорировать, побереги нервы

[@toxicknight3079]

На ExtremeCode иначе инкапсуляцию трактовали. Буквально несколько дней назад их видос смотрел.

[@Qnoize]

Ну я бы не сказал бы, что там кто-то что-то спиздил. Определения у них разные, схожесть только в одном - что большинство не правильно понимают инкапсуляцию!

[@sochniy_skuf]

Какое извращенное представление об инкапсуляции. Оказывается jetbrains расставив все точки в вопросе инкапсуляции сильно ошиблись. Тут такое дарование умное сидит, но использование среды visual studio четко характеризует лектора

[@rsakutin]

А где джетбрейнс раставили точки?

[@АлександрКвитко-в8т]

Просто словоблудие!

[@michailantipov6914]

Афтор, удали видео, не вводи людей в заблуждение. Тем более новичков.

[@mmospanenko]

Автор очень далеко от начала понимания идей ооп, вообще не в ту сторону

[@back_to_life0]

Бред

[@Oleksandp]

ААААААААААААААААААААААААААААА!!!!!!!!!!!1111111111111111 Что за ХНЯ?! 1. За паблик филды без надобности нужно бить линейкой по рукам. Первая сериализация/замыкание/биндинг, и начинаешь познавать боль. Интерфейсы вообще не применишь. Паблик филды нужны только для структур, по большому, и то их как правило делают readonly. 2. Вторая модель типичный класс данных без логики. И все пишут именно такие подели по причинам описаным в п.1 3. Генерить лапками get-set методы вместо свойств... Если я такое напишу, мне сразу вызовут дурку. Если public field еще можно объяснить ленью, то вот это можно объяснить только психическим расстройством. Вывод: сделали два неправильных примера на один типичный, без контекста и с умными щами расказываем как все нехорошо... Не надо так, людям же больно такое смотреть. p.s. "экстрим код" в свое время довольно прикольно объяснил что "инкапсуляция" вообще-то не только про сокрытие, а так же про логическое объединение в одно целое.

[@crn05]

3й класс вполне себе инкапсулирован, и там все готово, чтобы создать логику в геттере и сеттере, просто она там не нужна. if(value>1000000) { Console.WriteLine("А-ну пройдемте с нами, товарищ"); value=0; _money=value }

[@pan-gloowl]

80% годноты + 20% калла