боже, вот сколько книг читал, сколько уже лекций за пол года прошел, а настолько простой и самое главное понятной и объясняющей трактовки инкапсуляции не слышал. огромное вам спасибо, теперь я хоть понимаю как отвечать на собесах на этот вопрос. правда, большое спасибо
привет) 2 года прошло, как вы написали комментарий. Хочу поинтересоваться, как сложились у вас дела с программированием, получилось ли найти работу? Если да, то что можете посоветовать, чтобы получилось попасть на работу? Заранее спасибо
Я такую аналогию придумал: представьте, на гонках вам нужно вычислять скорость машин по времени прохождения контрольного участка. И есть помощники. Один пишет на вашу доску номер болида, второй время в начале участка, а третий время в конце участка. Ваша задача посчитать. Но машины могут ехать кучно, и иногда начинается путаница: на одной строке оказывается номер одной машины, первое время от другой, а второе время от третьей. Бардак. Тогда вы придумали сделать так. Для каждой новой машины помощники заводят карточку, ну которую пишут номер, два значения времени и отдают карточку вам. Вы считаете скорость, пишете ее в специальное поле и возвращаете карточку. Теперь путаницы нет.
теперь в моем понимании инкапсуляция - механизм языка программирования, который позволяет объединить данные и методы, работающие с этими данными, в единый объект и скрыть детали реализации (блин где то я уже это слышал, но все равно спасибо!)
@@Всемпривет-ч7в Вы спрашиваете: *а ваше какое?* Классическое. Инкапсуляция - это изоляция деталей реализации элемента от клиентского кода. А вот объединение данных и методов их обработки - это концепция класса в ооп, а вовсе не инкапсуляция. А ещё, у инкапсуляции нет задачи что-то срывать. Например, приватный модификатор доступа в ооп отлично изолирует детали, но ничего не скрывает.
В видео всё правильно, зачем ты выдумываешь велосипед, если он есть? Гений, приватный метод, он на то и создан, чтобы скрыть поля/данные от внешнего вмешательства. Я понимаю, каждый по разному говорит, но твое "изолирует" это фактически синоним к скрывает, не понимаю, в чём прикол, когда некоторые так говорят, "изоляция", это как рашка сейчас себя изолирует или же скрывает от цывилизованного мира, просто ты выбрал такое модное слово, но никто не запрещает говорить скрывать.@@princessmary5556
В дополнение ко всему уже сказанному моим тёзкой хотел бы добавить, что инкапсуляция это крайне важный аспект ООП. Я год работал в одной фирме, где народ долгое время игнорировал инкапсуляцию. В результате из кода вырос нелетающий макаронный монстр. В этом коде было пяток классов по 20к строк, которые были настолько сильно связаны друг с другом, что их можно было считать за один. Любое изменение в этих классах с вероятностью 80% приводило к отваливанию каких-то фитч. Единственное, что спасало, это неплохое покрытие тестами. Но и тут был зашквар, поскольку прогон всех тестов длился около часа. Это особо сильно доставало, когда надо было быстро исправить баг, потом исправление, потом исправление исправления и далее рекурсивно. Мораль сего опуса очевидна: инкапсулируйте свои классы во всех смыслах, о которых рассказывал автор ролика, и будет Вам счастье. Те, кто хочет ещё больше узнать о том, как пользоваться инкапсуляцией, рекомендую поискать лекции Егора Бугаенко на тему elegant objects.
Это больше похоже на то, что изначальной проблемой является не отсутствие инкапсуляции, а отсутствие разделения кода по зонам ответственности, и наличие temporal coupling. С таким же успехом проблему можно решить введением иммутабельности, но это сложнее внедрить (и понять), чем инкапсуляцию. Но введение инкапсуляции решит только часть проблем, т.к. если в коде есть temporal coupling, то она от него не спасёт никак, а это основной источник багов. И во многих проектах по факту инкапсуляция сводится к добавлению геттера/сеттера :)
Привет, от бывшего студента! Сергей, первая трактовка это основа ООП-парадигмы, т.е. способ оформления кода и ничего более, когда класс содержит в себе атрибуты и свойства. Но к инкапсуляции это не имеет отношение, т.к. поля можно сделать не только private. Хотя, если имеется ввиду, что класс выступает, как капсула для полей, то все равно - это не инкапсуляция с точки зрения ООП. Тогда и про локальные переменные можно сказать, что они инкапсулированы в методах, но это будет странно. Кроме того инкапсуляция действует не только по отношению к полям, но и методам, позволяя изменять внутренние методы без последствий для пользователей API. P.S. кстати, используя сеттеры без каких либо валидаций и проверки входных значений делает инкапсуляцию бесполезной. Обращение через сеттер к полям без проверок ничем не отличается от того, если бы эти поля были бы public и мы к ним обращались напрямую. Это, кстати, не все осознают.
C public сеттерами полностью согласен, многие просто думают ,что если написать паблик проперти с гет/сет, то они уже юзают инкапсуляцию... а вот про инкапсуляцию локальных переменных в методах тут нет ничего странного, если посмотреть в сторону тех же замыканий
@@SergeyNemchinskiy, да, я так и делаю: сейчас прослушал на 2 раза, и через полгодика с накоплением практики, ошибок, ещё на раз, но воспринимается как в первый раз )
@@Dmitrii-Zhinzhilov коллега, вслушивайтесь во весь спектр слов сопровождающих определение, ведь именно они являются ключом к картине мира инкапсуляции, и непонимание хотя бы одного не создаст общего понимания.
Использование пассивного залога... - позиция жертвы. Да, у нас так принято, но в остальном мире используют активный: My name is...; Meine Name ist....; Ich heiße ...
С удовольствием записался бы на ваши курсы, но проживаю и учусь в Германии. Очень часто обращаюсь к вашим лекциям по темам которые плохо усвоил на основной учебе. Спасибо за ваш канал!
Сергей, спасибо за отличный выпуск, но я думаю было бы полезно если бы вы показали практическое применение каждой парадигмы, (пример кода) Заранее спасибо :)
Почему просто не сказать скрытие, что за "новомодное" слово? К тому же куда понятнее новичкам становиться, возможно это для тех, кто знает русский не проблема, но я это слово не знаю.
А казалось бы о чем спор. Методы, которые работают с данными, должны быть заключены с ними в одном объекте -> соответственно не должно быть методов вне объекта, взаимодействующих с данными-> соответственно данные должны быть сокрыты от внешних воздействий.
Спасибо вам. Очень важная просба, из за того что некоторые люди как я работають в иностранных компаниях, нам важно чтобы вы использовали и английские имена или выражения, потому что это поможеть запонинать и вспоминать, особенно в интервю когда надо обьяснять что-то. Спасибо! Удачи :)
Вчера у меня на канале вышло видео про термины ООП. А тут и у Сергея вышло. А мне пишут: тема заезженная зачем оно надо. Надо - тут действительно много есть, что обсудить и подумать. Что касается инкапсуляции, я ее вообще не разделяю на два принципа т.к. это было бы просто странно одно без другого. Так, что тут Сергей прав: данные, методы, сокрытие - все нужно и не отделимо друг от друга.
Спасибо. У нас был холивар, в котором мне доказывали, что наличие сеттеров - это нарушение принципа инкапсуляции, при том что сеттер принадлежит классу, является его методом и вообще может иметь внутреннюю логику никого не смущало))).
@@SkyAntins Это потому, что прогеры - чудаки. У меня сеттеров почти не бывает вовсе. А при автозаполнении можно указать, генерировать сеттеры или только геттеры и для каких полей.
Инкапсуляция это процес отделения абстрации от реализации. Клиентскому коду нужен только интерфейс с декларируемыми методами, но от клиента скрыта реализация этих методов, в этом суть инкапсуляции
@@HelloWorld-fy8cd Нет никаких "ненамного". Слова "скрыта" и "изолирована" - это два разных слова с принципиально разными значениями. Это - не синонимы. Инкапсуляция именно изолирует детали реализации, а не скрывает их. Возьмите любой типичный заголовочный файл языка с++, в котором объявлен типичный класс с типичной private секцией. Вы можете свободно разглядывать приватные детали именно потому, что они не скрыты. Были бы скрыты, вы бы не смогли их рассмотреть. С технической точки зрения, этот факт имеет важное значение. Если, допустим, у вас в приватной секции будет что-то windows-специфичное, тогда весь заголовочный файл будет иметь зависимость от winapi, и, соответственно, будет прибивать к windows гвоздями клиентский код, который попытается использовать такой заголовок. . Это имеет принципиально значение для кросс-платформенных решений: в публичных заголовках недопустимо использовать ос-зависимых детали. И вот тут на помощь сокрытие (например, можно использовать идеому pimpl) Сокрытие деталей - это не просто изоляция вызывающего кода от вызываемого. Это - сокрытие (и от глаз людей, и от глаз компилятора) информации о типах, и их зависимостях на уровне файла. Важно: сокрытие позволяет скрыть детали на уровне файла, но не на уровне единицы трансляции. А вообще, всё то, что я выше написала - это как бы азы языка. Просто почитайте какой нибудь букварь.
Спасибо вам огромное за ваш труд! Работаю программистом самоучкой вот уже 4-5 лет но некоторые вопросы до конца понял только после того как посмотрел ваши видео. Можете записать видео про design patterns и dependency injection?
Ух, сейчас понабегу :D. Класс - это не объект, это класс объектов. Понятие из математики ) Само собой, если сам класс не является объектом. Например функциональный объект в JavaScript также может являться и классом Экземпляр класса является объектом, а еще объект может существовать без отдельного класса, например простой объект: { name: 'name', rename(name: string) { this.name = name } } Имеет тип: { name: string; rename(name: string): void; } но не относится ни к одному классу кроме как к Object, к которому относятся все объект в JS. Для некоторых(python, ruby, php ...) языков это также справедливо. Также с помощью класса можно выразить пространство имен, например абстрактный класс со статическими методами. В общем я это к том что 2 определения существуют и между ними возникает путаница(как и прикол с внезапным 4-м столпом абстракцией для старичков, а еще SOLID приписывают к столпам ООП) из-за того что эти определения про разное. В первом случае это относится к определению понятия объекта и его свойств, а во втором к мышлению в стиле ООП(философия) и непосредственно к написанию кода(практика). Хотя с другой стороны, всё еще проще: Сокрытие - это сокрытие! :D вот это поворот Инкапсуляция - это размещение в оболочке.
Я бы сказал что уже ООоочень давно просил это видео) Ну тем не менее спасибо что раскрыли эту тему хотя бы сейчас) Слава богу что то что я понял до этого видео совпало с тем что вы рассказали (спасибо ExtremeCode)
Сергей, я не профессионал в программировании, но интересующийся. Если бы я послушал Ваш комент на тему инкапсуляции я бы сошел с ума, но есть книга " как программировать на visual С#" Объявление переменных экземпляров с модификатором доступа pri vate называется сокрытием информации (или инкапсуляцией). Когда приложение создает объект класса GradeBook, переменная courseName инкапсулируется ( скрывается) в объекте, а обращаться к ней могут только члены класса объекта
Инкапсуляция - первая трактовка, это объединение методов и данных в один объект. Вторая трактовка - сокрытие внутренних данных и вызов их через методы самого объекта.
в случае использования рефлексии вообще говорить об ООП (т.е. об инкапсуляции) нет смысла т.к. рефлексия и предназначена для того, чтобы разрушить принципы ООП и обойти его основные принципы.
@@gpvphoobastankvarerera6313 рефлексия не отменяет объектов, как совокупность данных и методов, а позволяет лишь неограниченный к ним доступ. Не отменяет ни наследования, ни полиморфизма, ни абстракции
Сергей, здравствуйте! Правильно ли я понял, что можно рассмотреть как объект коробку передач автомобиля? А в качестве интерфейса взаимодействия - селектор выбора передач. Данные это обороты и мощность двигателя, а методы - передаточные числа.
Спасибо, я за последний год впервые услышал на ютубе адекватное мнение на эту тему. Мне кажется вы упускаете один важный момент инкапсуляции как сокрытия. Инкапсуляция это не только сокрытие состояния, но и внутренней логики. Объект получает данные с диска(кэша) или через http, а клиенту этого объекта все равно откуда появился отчет, например. Это была одна из основополагающих предпосылок возникновения самого ООП - убрать реализацию с глаз долой. От людей, пишущих на современных языках, как-то странно слышать о том, что инкапсуляция это не сокрытие. Хочется спросить у них: "А вот модификаторы доступа какой базовый принцип реализуют?" С другой стороны заявление о том, что инкапсуляция это только сокрытие, звучит еще страннее. В том же самом С были структуры, и можно было реализовать сокрытие их внутреннего содержимого. Но это ни разу не делало C объектно ориентированным языком. И только объединение данных с методами позволило появится ООП в том виде, в котором мы его знаем (вернее это один из необходимых принципов).
Сергей, не в обиду, а в качестве критики. Вот честно - видео вообще НИ О ЧЕМ. Слишком много воды, ни черта не понятно! В вашем видео "Java для начинающих программистов. Часть 1 .Объекты. Классы. Интерфейсы" гораздо лучше и подробнее разбирается и объясняется про ООП. Мне кажется (личное мнение), что если вы в будущем будете перезаписывать видео на эту же тему - то в качестве образца лучше всего использовать именно его. Лайк поставил. Успехов вам!
Хммм. Интересные мысли. Я и не знал что существует 2 трактовки. И что одну из них можно применить к более широкому понятию чем только Class Тогда вылезает проблема, что часто непонятно что является этим "классом" и какие кишки (методы, объекты) отдавать наружу и позволять другим разработчикам использовать их... Короче заставляет задуматься
ну а че там думать. Для сущности создаешь интерфейс или несколько их - те ручки, за которые кто-то извне может дергать класс. А все, что не в интерфейсе - делаешь приватным. Это как паяешь калькулятор и думаешь "а что же мне прятать в корпус, а где отверстия делать" - ну очевидно же, где
Хочется больше услышать про enterprise, почему джаву не начнут заменять? Или почему не получится написать enterprise на nodejs + nestjs(typeScript). Яндекс деньги переписали вроде, или это другой enterprise? Чем именно незаменима джава, и почем другие статически типизированные языки не могут занять нишу в создании новых enterprise проектов?
Прикольно. Чого дуже не вистачає - це графічного супроводу, хоча б на папері можна малювати. На жаль, на обличчі нічого не намальовано, а в кадрі лише воно :)
а есть видосик про "новомодное" движение анти-инкапсуляции -- наоборот отделать данные от кода? пару раз слышал, что на собесе задавали подобные вопрос типа "в чем минусы ООП?"
косвенно к этой же теме: если ООП так круто, почему чтобы узнать про труъ-ООПшные БД приходится гуглить, и оно не используется по умолчанию в каждом чайнике?
Насколько мне известно, абстракция - это принцип любого программирования. Сложно представить процедурный или функциональный подход без переменных и функций (абстракций?)
@@АлексейПоляков-ш1э в широком смысле, абстракция это теоретическое обобщение. так что ответ на ваш вопрос - да. Переменная это абстракция над конкретными значениями, а функция - над конкретными алгоритмами.
@Дмитрий Косачёв, Согласен, только уточню, что абстракция лежит на более фундаментальном уровне, нежели программирование. Это из области формальной логики, и одинаково используется во множестве дисциплин. Как по мне, абстракция - это лучший инструмент для борьбы со сложностью систем. Поэтому, конечно, это не эксклюзивная особенность ООП. Просто в случае ООП многие создают классы, исходя из сиюминутной выгоды (программирование по принципу: "Велика у стула ножка, подпилю её немножко"), а не исходя из абстрагирования предметной области (тогда бы классы гораздо чаще получались логически-объяснимыми и легко понимаемыми).
Т.е можно еще сказать, что главный принцип инкапсуляции - объединение данных в один объект, а сокрытие данных - это уже вспомогательная вещь, без которой наш объект, содержащий данные, был бы доступен для всех.
Добрый день, товарищи. Меня зовут Сергей Немчинский, я программист 9 разряда, почётный ректор Киевского Государственного Института Программостроения и Багоисправления им. Фоксмайндедова.
После всего круговорота неоднозначной информации я пришел к следующему пониманию. Скажите верное ли оно или я что-то упустил? Итак, цитата с википедии: ============================================ В объектно-ориентированных языках программирования и других связанных областях инкапсуляция относится к одному из двух связанных, но разных понятий, а иногда и к их комбинации: 1) Языковой механизм для ограничения прямого доступа к некоторым компонентам объекта . 2) Языковая конструкция, упрощающая объединение данных с методами (или другими функциями), работающими с этими данными. Некоторые исследователи языков программирования и ученые используют первое значение отдельно или в сочетании со вторым как отличительную черту объектно-ориентированного программирования , в то время как некоторые языки программирования, предоставляющие лексические замыкания , рассматривают инкапсуляцию как особенность языка, ортогонального объектной ориентации. Второе определение мотивировано тем фактом, что во многих объектно-ориентированных языках и других связанных областях компоненты не скрываются автоматически, и это можно переопределить; таким образом, сокрытие информации определяется как отдельное понятие теми, кто предпочитает второе определение. ============================================= Предназначение инкапсуляции, как я понял, заключается в том, чтобы отделить интерфейс и реализацию, от нежелательного вмешательства извне к тем вещам, к которым пользователь интерфейса не должен прикасаться и знать о них. И взаимодействовать только через интерфейс. Таким образом может показаться, что первое понятие из вики справедливо, но достаточно ли только его? Выходит, если так считать, то объединение данных с методами здесь лишнее. В таком случае, что будет сокрываться, если нет объединённых ни методов ни данных?По всей видимости это бессмысленно. Из этого следует что ТОЛЬКО СОКРЫТИЕ - это НЕ инкапсуляция. Может есть языки, где нельзя писать код, не объединяя методы и свойства, тогда для них играет роль только первое определение, а второе идет из коробки. Идем дальше, ко второй формулировке. Получается, что есть языки в которых объединение методов и свойств не делает их недоступными извне автоматически, и им для достижения этого требуются свои механизмы, поэтому и зародилась первая формулировка. В итоге это всё равно оба понятия вместе. Из этого следует, что: СОКРЫТИЕ - ЭТО ИНСТРУМЕНТ ДЛЯ ДОСТИЖЕНИЯ ИНКАПСУЛЯЦИИ, но только его одного недостаточно для этого (следует из вывода абзаца выше), требуется еще и объединение методов и свойств. ???????????????????????????? Осталось проверить последний вариант. Возможна ли инкапсуляция только объединением методов и свойств без сокрытия? Даже если в некоторых ЯП сокрытие идёт из коробки и нам стоит заморочиться только с объединением, всё равно используются два понятия вместе, хоть и одно из них из коробки. Здесь у меня нет ответа, есть только предположение: добиться инкапсуляции одним лишь объединением нельзя. (скажите так ли это) Подводя итог, определение инкапсуляции верно если считать оба формулировки неразрывными. Но почему же всё таки кто-то считает, что верно только первое утверждение, а кто-то что верно второе? Помогите прояснить сей нюансы, кто действительно понимает. Надеюсь кому-то мои размышления были полезны.
Вы спрашиваете: *В таком случае, что будет сокрываться, если нет объединённых ни методов ни данных?* Детали реализации. И кстати, инкапсуляция - это не сокрытие данных, а изоляция. Т.е., данныне не скрываются, а просто доступ к ним ограничен (см 1 пункт). Например, на языке си, где отродясь не было никаких классов, можно написать библиотеку, которая предоставит пользователям неккое API. При этом сишную библиотеку можно реализовать таким образом, что бы у клиентского кода не было доступа к деталям её реализации.
Вы спрашиваете: *Возможна ли инкапсуляция только объединением методов и свойств без сокрытия?* Объединение данных и методов их обработки - это концепция оопнутого класса. К понятию инкапсуляции не имеет никакого отношения. А теперь возьмем класс на с++. Это пример объединения данных и методов их обработки. Однако все детали реализации оставим в публичной секции. Т.е., они будут доступны любому желающему. В этом случае уже нет никакой изоляции деталей реализации от клиентского кода. В таких случаях говорят: "инкапсуляция отсутствует".
Вы спрашиваете: *почему же всё таки кто-то считает, что верно только первое утверждение, а кто-то что верно второе?* В первом случае люди отталкиваются от предназначения инкапсуляции: *отделить интерфейс и реализацию, от нежелательного вмешательства извне к тем вещам, к которым пользователь интерфейса не должен прикасаться и знать о них* А во втором случае люди просто идиоты, которые несут всякую чушь.
"Вторая трактовка без первой не работает совсем" - в этом и смысл. Это не две трактовки, а полное определение инкапсуляции. Объединение логики и данных в единый объект и сокрытие его реализации от окружающих. Как писал небезызвестный Дядя Боб: "самая сильная инкапсуляция в языке C, так как там код делится на хэдер и реализацию, где использующий хэдер не знает ничего о реализации". В шарпе и джаве частично данное поведение имитируют интерфейсы.
Слово "объект" применительно к языку си сбивает с толку. Потому что в си объект - это кусок памяти. Возможно вы имели ввиду: "объединение логики и данных в единый элемент". Но это тоже какой то бред. Возможно вы имели ввиду: "отделение логики и данных, с которыми эта логика работает в отдельный элемент" - вот это уже что-то похожее на правду. Вот только не очень понятно зачем нужна первая трактовка. Итак же понятно: что бы что то инкапсулировать, нужно что бы это что-то было. Поэтому достаточно просто сказать: инкапсуляция - изоляция деталей реализации элемента от клиентского кода" Зы: на сишке можно просто подсмотреть глазками, что есть в исходниках, и выковырять данные (или функции) наружу.
@@princessmary5556 А клиентский код инкапсулироваться не должен что-ли?)) Элемента? Элемента чего? Объект - целостная сущность, а элемент - это часть чего-то, а чего - не уточнено. Объект - сущность объектно-ориентированных языков(которые, о боже, потому и называются ОБЪЕКТНО-ориентированными). А C - это просто пример возможности реализовать более сильную инкапсуляцию от Мартина.
@@AlexCSharp Вы спрашиваете: *А клиентский код инкапсулироваться не должен что-ли?* Разумеется, он ничего вам не должен, если только не подписал с вами кредитный договор. Вы спрашиваете: *Элемента?* Да. Вы пишите: *Элемента чего?* Неккой системы: библиотеки, проекта, etc. Вы пишите: *Объект - сущность объектно-ориентированных языков* Не только. Объекты бывают не только в ооп. Вы пишите: *C - это просто пример* Когда вы приводите в качестве примера язык си, то вы придерживаетесь терминологии языка си. В языке си, объект - это термин. Вам нужно процитировать точное определение термина? Или сами погуглите?
Добрый день! Скажите плиз, является ли нарушением инкапсуляции случай, если я обращаюсь к полю объекта для того, чтобы узнать его значение? Например, у объекта есть булево значение ready и я обращаюсь к нему if объект.ready is True: делай что-то. Или все-таки нужно писать метод, который будет мне его возвращать?)
Очень хотелось бы почаще слушать Вас в формате ten minutes about... Удобоваримо объясняете, ёмко. О переменных бы... А вообще хотелось про VAR мнение узнать
А что там еще делать, кроме как холиварить? Вопросы они порой интересные поднимает, но их категоричность, порой вызывает заставляет усомниться в компетентности автора. Я после очередного бреда отписался от них. Обидно не то, что они поленились разобраться, а то что их слушает огромное количество новичков, и они тупо засирают им головы.
🦊Новый поток Advanced курса Enterprise Patterns стартует уже 1 февраля 2023 года ❗
Регистрация - go.foxminded.ua/3GVhKa7
На собеседовании : "... определение не скажу, но Немчинский говорил что бы когда гайку открутили - жопа не отвалилась..."
(Это был первый и последний вопрос) : Поздравляю! Вы приняты!
И не смотря на то, что вы выдвигались на миддл позицию, мы дадим вам сеньйора!
@@malikvalley ...ой, всмысле джуна
а при злостных нарушениях инкапсуляции тоже простреливает не ногу
боже, вот сколько книг читал, сколько уже лекций за пол года прошел, а настолько простой и самое главное понятной и объясняющей трактовки инкапсуляции не слышал. огромное вам спасибо, теперь я хоть понимаю как отвечать на собесах на этот вопрос. правда, большое спасибо
привет) 2 года прошло, как вы написали комментарий. Хочу поинтересоваться, как сложились у вас дела с программированием, получилось ли найти работу? Если да, то что можете посоветовать, чтобы получилось попасть на работу? Заранее спасибо
@@kubezubik6425 Вам честно сказать?)
@@coma4205 желательно)
@@coma4205 желательно)
@@kubezubik6425 совет один, если планируете что либо, то не оставайтесь там где може начаться война) она все планы рушит)
Я такую аналогию придумал: представьте, на гонках вам нужно вычислять скорость машин по времени прохождения контрольного участка. И есть помощники. Один пишет на вашу доску номер болида, второй время в начале участка, а третий время в конце участка. Ваша задача посчитать. Но машины могут ехать кучно, и иногда начинается путаница: на одной строке оказывается номер одной машины, первое время от другой, а второе время от третьей. Бардак. Тогда вы придумали сделать так. Для каждой новой машины помощники заводят карточку, ну которую пишут номер, два значения времени и отдают карточку вам. Вы считаете скорость, пишете ее в специальное поле и возвращаете карточку. Теперь путаницы нет.
теперь в моем понимании инкапсуляция - механизм языка программирования, который позволяет объединить данные и методы, работающие с этими данными, в единый объект и скрыть детали реализации (блин где то я уже это слышал, но все равно спасибо!)
Ваше понимание неверное.
@@princessmary5556 почему, а ваше какое?
@@Всемпривет-ч7в Вы спрашиваете: *почему* Не знаю почему. Может карма у вас такая, а может мамка в детстве уронила.
@@Всемпривет-ч7в Вы спрашиваете: *а ваше какое?* Классическое. Инкапсуляция - это изоляция деталей реализации элемента от клиентского кода.
А вот объединение данных и методов их обработки - это концепция класса в ооп, а вовсе не инкапсуляция.
А ещё, у инкапсуляции нет задачи что-то срывать. Например, приватный модификатор доступа в ооп отлично изолирует детали, но ничего не скрывает.
В видео всё правильно, зачем ты выдумываешь велосипед, если он есть? Гений, приватный метод, он на то и создан, чтобы скрыть поля/данные от внешнего вмешательства. Я понимаю, каждый по разному говорит, но твое "изолирует" это фактически синоним к скрывает, не понимаю, в чём прикол, когда некоторые так говорят, "изоляция", это как рашка сейчас себя изолирует или же скрывает от цывилизованного мира, просто ты выбрал такое модное слово, но никто не запрещает говорить скрывать.@@princessmary5556
В дополнение ко всему уже сказанному моим тёзкой хотел бы добавить, что инкапсуляция это крайне важный аспект ООП. Я год работал в одной фирме, где народ долгое время игнорировал инкапсуляцию. В результате из кода вырос нелетающий макаронный монстр. В этом коде было пяток классов по 20к строк, которые были настолько сильно связаны друг с другом, что их можно было считать за один. Любое изменение в этих классах с вероятностью 80% приводило к отваливанию каких-то фитч. Единственное, что спасало, это неплохое покрытие тестами. Но и тут был зашквар, поскольку прогон всех тестов длился около часа. Это особо сильно доставало, когда надо было быстро исправить баг, потом исправление, потом исправление исправления и далее рекурсивно.
Мораль сего опуса очевидна: инкапсулируйте свои классы во всех смыслах, о которых рассказывал автор ролика, и будет Вам счастье. Те, кто хочет ещё больше узнать о том, как пользоваться инкапсуляцией, рекомендую поискать лекции Егора Бугаенко на тему elegant objects.
Это больше похоже на то, что изначальной проблемой является не отсутствие инкапсуляции, а отсутствие разделения кода по зонам ответственности, и наличие temporal coupling. С таким же успехом проблему можно решить введением иммутабельности, но это сложнее внедрить (и понять), чем инкапсуляцию. Но введение инкапсуляции решит только часть проблем, т.к. если в коде есть temporal coupling, то она от него не спасёт никак, а это основной источник багов. И во многих проектах по факту инкапсуляция сводится к добавлению геттера/сеттера :)
Как я долго ждал от вас этого, спасибо!
Класна подача матеріалу простими зрозумілими словами та з практичними порівняннями)
Одно из самых адекватных объяснений в интернете.
спасибо)я старался)
С каждым Вашим видео я становлюсь умнее =)
и это правильно)
вы молодец)
А я утверждаюсь в своей ничтожности :)
Привет, от бывшего студента!
Сергей, первая трактовка это основа ООП-парадигмы, т.е. способ оформления кода и ничего более, когда класс содержит в себе атрибуты и свойства. Но к инкапсуляции это не имеет отношение, т.к. поля можно сделать не только private. Хотя, если имеется ввиду, что класс выступает, как капсула для полей, то все равно - это не инкапсуляция с точки зрения ООП. Тогда и про локальные переменные можно сказать, что они инкапсулированы в методах, но это будет странно. Кроме того инкапсуляция действует не только по отношению к полям, но и методам, позволяя изменять внутренние методы без последствий для пользователей API.
P.S. кстати, используя сеттеры без каких либо валидаций и проверки входных значений делает инкапсуляцию бесполезной. Обращение через сеттер к полям без проверок ничем не отличается от того, если бы эти поля были бы public и мы к ним обращались напрямую. Это, кстати, не все осознают.
C public сеттерами полностью согласен, многие просто думают ,что если написать паблик проперти с гет/сет, то они уже юзают инкапсуляцию... а вот про инкапсуляцию локальных переменных в методах тут нет ничего странного, если посмотреть в сторону тех же замыканий
Есть определение инкапсуляции. Зачем в точных науках разводить феласафию?
@Svetlana V Программирование это точная наука. Точнее информатика
@@alexplishkin5811 Программирование никогда не было точной наукой)) И сегодня - это вообще ближе к лингвистике, чем к математике и информатике)
@@0imax Пусть будет так. Но есть точное определение инкапсуляции. Не понимаю зачем разводить демагогию.
Как только услышал ''Здравствуйте, мои дорогие" , то сразу подписался на канал.
Приятно вас слушать - как психотерапия :)
Ничего не понятно, но оооочень интересно! Благодарю!
ну тогда послушайте еще раз :)
@@SergeyNemchinskiy, да, я так и делаю: сейчас прослушал на 2 раза, и через полгодика с накоплением практики, ошибок, ещё на раз, но воспринимается как в первый раз )
@@Dmitrii-Zhinzhilov коллега, вслушивайтесь во весь спектр слов сопровождающих определение, ведь именно они являются ключом к картине мира инкапсуляции, и непонимание хотя бы одного не создаст общего понимания.
Вас всё ещё зовут Сергей Немчинский??????
Имя защищено от внешних воздействий)
@@МихаилТолмачев-э9у private final String name = "Sergey Nemchenskiy";
Я тоже в шоке
Использование пассивного залога... - позиция жертвы. Да, у нас так принято, но в остальном мире используют активный: My name is...; Meine Name ist....; Ich heiße ...
@Белояръ Чайка )))
С удовольствием записался бы на ваши курсы, но проживаю и учусь в Германии. Очень часто обращаюсь к вашим лекциям по темам которые плохо усвоил на основной учебе. Спасибо за ваш канал!
Спасибо Сергей, хорошее объяснение!
Сергей, спасибо за отличный выпуск, но я думаю было бы полезно если бы вы показали практическое применение каждой парадигмы, (пример кода) Заранее спасибо :)
Уникальный контент на канале! Блогеров с таким опытом в айти не существует!) спасибо!
Дядь, офигенный стиль подачи инфы! Благодарю!!!
ой, спасибо)
Вы очень хорошо и доступно объясняете. Спасибо Сергей за труд вас и ваших коллег!
стараюсь)
Рад слышать, что инкапсуляция это не только сокрытие)
Почему просто не сказать скрытие, что за "новомодное" слово? К тому же куда понятнее новичкам становиться, возможно это для тех, кто знает русский не проблема, но я это слово не знаю.
Да. Согласен с комментаторами. SOLID было бы круто разобрать. Но в любом случае Сергею спасибо.
А казалось бы о чем спор. Методы, которые работают с данными, должны быть заключены с ними в одном объекте -> соответственно не должно быть методов вне объекта, взаимодействующих с данными-> соответственно данные должны быть сокрыты от внешних воздействий.
Спасибо вам. Очень важная просба, из за того что некоторые люди как я работають в иностранных компаниях, нам важно чтобы вы использовали и английские имена или выражения, потому что это поможеть запонинать и вспоминать, особенно в интервю когда надо обьяснять что-то. Спасибо! Удачи :)
Сергей хороший дядька 👍😀
Серёженька ! Сделай обзор по Delphi, LAZARUS и Free Pascal.
Вчера у меня на канале вышло видео про термины ООП. А тут и у Сергея вышло. А мне пишут: тема заезженная зачем оно надо. Надо - тут действительно много есть, что обсудить и подумать. Что касается инкапсуляции, я ее вообще не разделяю на два принципа т.к. это было бы просто странно одно без другого. Так, что тут Сергей прав: данные, методы, сокрытие - все нужно и не отделимо друг от друга.
Гайку открутили жопа отвалилась! Ты сделал мой день :-D
Спасибо.
У нас был холивар, в котором мне доказывали, что наличие сеттеров - это нарушение принципа инкапсуляции, при том что сеттер принадлежит классу, является его методом и вообще может иметь внутреннюю логику никого не смущало))).
Если сеттер не имеет внутренней валидации для входных аргументов, то грош цена такой инкапсулиции
Почитай про принцип Tell-Don’t-Ask
Ну вообще сеттеры без валидации действительно нужны крайне редко, может в билдерах каких-то только.
Да, нарушают
@@SkyAntins Это потому, что прогеры - чудаки. У меня сеттеров почти не бывает вовсе. А при автозаполнении можно указать, генерировать сеттеры или только геттеры и для каких полей.
блин!!! Нуууу очееннььььь здоровооо было бы, если бы, вы, автор, подкрепляли вашу теорию кодиком, так было бы веселее!!!
РАЗ, ДВА, ТРИ !!! СЕРЁЖЕНЬКА ДАРИ !!!
раз уж про принципы ООП заговорили, давайте заодно и SOLID разберем :) думаю, многим будет полезно.
ну если такая пьянка, то и про самые распространённые паттерны стоит поговорить)
Что за SOLID?
Дуже дякую за пояснення ООП .
Инкапсуляция это процес отделения абстрации от реализации. Клиентскому коду нужен только интерфейс с декларируемыми методами, но от клиента скрыта реализация этих методов, в этом суть инкапсуляции
Не скрыта, а изолирована.
@@princessmary5556 возможно слово "изолирована" подходит лучше, но ненамного)
@@HelloWorld-fy8cd Нет никаких "ненамного". Слова "скрыта" и "изолирована" - это два разных слова с принципиально разными значениями. Это - не синонимы. Инкапсуляция именно изолирует детали реализации, а не скрывает их. Возьмите любой типичный заголовочный файл языка с++, в котором объявлен типичный класс с типичной private секцией. Вы можете свободно разглядывать приватные детали именно потому, что они не скрыты. Были бы скрыты, вы бы не смогли их рассмотреть. С технической точки зрения, этот факт имеет важное значение. Если, допустим, у вас в приватной секции будет что-то windows-специфичное, тогда весь заголовочный файл будет иметь зависимость от winapi, и, соответственно, будет прибивать к windows гвоздями клиентский код, который попытается использовать такой заголовок. . Это имеет принципиально значение для кросс-платформенных решений: в публичных заголовках недопустимо использовать ос-зависимых детали. И вот тут на помощь сокрытие (например, можно использовать идеому pimpl) Сокрытие деталей - это не просто изоляция вызывающего кода от вызываемого. Это - сокрытие (и от глаз людей, и от глаз компилятора) информации о типах, и их зависимостях на уровне файла. Важно: сокрытие позволяет скрыть детали на уровне файла, но не на уровне единицы трансляции. А вообще, всё то, что я выше написала - это как бы азы языка. Просто почитайте какой нибудь букварь.
Рекомендую к просмотру всем, а не только новичкам. А то иного тех.лида спросишь - не может объяснить.
В наше время каждый суслик - тех.лид.
спасибо за рекомендации)
Спасибо вам огромное за ваш труд! Работаю программистом самоучкой вот уже 4-5 лет но некоторые вопросы до конца понял только после того как посмотрел ваши видео. Можете записать видео про design patterns и dependency injection?
Ух, сейчас понабегу :D.
Класс - это не объект, это класс объектов. Понятие из математики ) Само собой, если сам класс не является объектом. Например функциональный объект в JavaScript также может являться и классом
Экземпляр класса является объектом, а еще объект может существовать без отдельного класса, например простой объект:
{
name: 'name',
rename(name: string) {
this.name = name
}
}
Имеет тип:
{
name: string;
rename(name: string): void;
}
но не относится ни к одному классу кроме как к Object, к которому относятся все объект в JS. Для некоторых(python, ruby, php ...) языков это также справедливо.
Также с помощью класса можно выразить пространство имен, например абстрактный класс со статическими методами.
В общем я это к том что 2 определения существуют и между ними возникает путаница(как и прикол с внезапным 4-м столпом абстракцией для старичков, а еще SOLID приписывают к столпам ООП) из-за того что эти определения про разное. В первом случае это относится к определению понятия объекта и его свойств, а во втором к мышлению в стиле ООП(философия) и непосредственно к написанию кода(практика).
Хотя с другой стороны, всё еще проще: Сокрытие - это сокрытие! :D вот это поворот
Инкапсуляция - это размещение в оболочке.
Я бы сказал что уже ООоочень давно просил это видео) Ну тем не менее спасибо что раскрыли эту тему хотя бы сейчас) Слава богу что то что я понял до этого видео совпало с тем что вы рассказали (спасибо ExtremeCode)
Спасибо все поняла
Шикарно!
Сергей, я не профессионал в программировании, но интересующийся. Если бы я послушал Ваш комент на тему инкапсуляции я бы сошел с ума, но есть книга " как программировать на visual С#" Объявление переменных экземпляров с модификатором доступа pri vate называется
сокрытием информации (или инкапсуляцией). Когда приложение создает объект
класса GradeBook, переменная courseName инкапсулируется ( скрывается) в объекте,
а обращаться к ней могут только члены класса объекта
Именно сокрытие всегда и было. Не знал другую трактовку))
У Вас ещё есть лекции по принципам ООП на канале
Которым лет 5-6
Смотрел с удовольствием
Все разжевано, интересно и понятно
спасибо)
Было бы хорошо пару примерчиков каких нибудь показать еще
все будет зависеть от языка. В каждом инакпсуляция реализуется по-своему
Спасибо за видео!
Инкапсуляция - первая трактовка, это объединение методов и данных в один объект.
Вторая трактовка - сокрытие внутренних данных и вызов их через методы самого объекта.
Что за слово странное "сокрытие"? Якщо перекласти, то це "приховування", так наче звучить зрозуміліше.
Спасибо. Хорошо объяснили, доступно и понятно.
очень интересно рассказываете
рад, что нравится)
@@SergeyNemchinskiy, на самом деле ваш подход от " Адама и Евы" помогает быстрее войти в тему. Поэтому ещё раз спасибо
Если учесть, что рефлексия сводит к нулю хоть какую-то возможность ограничения доступа ("сокрытия"), то только первое определение и есть верным
в случае использования рефлексии вообще говорить об ООП (т.е. об инкапсуляции) нет смысла т.к. рефлексия и предназначена для того, чтобы разрушить принципы ООП и обойти его основные принципы.
@@gpvphoobastankvarerera6313 рефлексия не отменяет объектов, как совокупность данных и методов, а позволяет лишь неограниченный к ним доступ. Не отменяет ни наследования, ни полиморфизма, ни абстракции
@@qr46654 Данные и методы их обработки - это концепция класса, а не объекта. В самом объекте нет никаких методов, только данные.
Вашим трактовкам я вращенья придавал. :D
- воин в тёмных одеждах
Сергей, здравствуйте! Правильно ли я понял, что можно рассмотреть как объект коробку передач автомобиля? А в качестве интерфейса взаимодействия - селектор выбора передач. Данные это обороты и мощность двигателя, а методы - передаточные числа.
Инкапсуляция это - капсула!!!
сокрытие это сокрытие, а инкапсуляция это инкапсуляция. Сразу все понятно о ваших курсах)
В тему с инкапсуляцией можно еще рассказать про рефлексию :)
Спасибо за видео, добра вам
спасибо)
Дуже дякую!!!
Спасибо, я за последний год впервые услышал на ютубе адекватное мнение на эту тему.
Мне кажется вы упускаете один важный момент инкапсуляции как сокрытия. Инкапсуляция это не только сокрытие состояния, но и внутренней логики. Объект получает данные с диска(кэша) или через http, а клиенту этого объекта все равно откуда появился отчет, например. Это была одна из основополагающих предпосылок возникновения самого ООП - убрать реализацию с глаз долой.
От людей, пишущих на современных языках, как-то странно слышать о том, что инкапсуляция это не сокрытие. Хочется спросить у них: "А вот модификаторы доступа какой базовый принцип реализуют?"
С другой стороны заявление о том, что инкапсуляция это только сокрытие, звучит еще страннее. В том же самом С были структуры, и можно было реализовать сокрытие их внутреннего содержимого. Но это ни разу не делало C объектно ориентированным языком. И только объединение данных с методами позволило появится ООП в том виде, в котором мы его знаем (вернее это один из необходимых принципов).
Серёжа, по ассемблеру ещё сделай пару обзоров. По 16-bit и 32-bit.
Сергей, не в обиду, а в качестве критики.
Вот честно - видео вообще НИ О ЧЕМ. Слишком много воды, ни черта не понятно! В вашем видео "Java для начинающих программистов. Часть 1 .Объекты. Классы. Интерфейсы" гораздо лучше и подробнее разбирается и объясняется про ООП. Мне кажется (личное мнение), что если вы в будущем будете перезаписывать видео на эту же тему - то в качестве образца лучше всего использовать именно его.
Лайк поставил. Успехов вам!
у меня идет экзамен по этой теме а я смотрю ваше видео
Что из себя представляет объект? Проект? Класс? Функция? Тип данных? Переменная?
Спасибо за подробное разжевывание, понятное даже для "чайников". Полезная рубрика!
спасибо!
Хммм. Интересные мысли. Я и не знал что существует 2 трактовки. И что одну из них можно применить к более широкому понятию чем только Class
Тогда вылезает проблема, что часто непонятно что является этим "классом" и какие кишки (методы, объекты) отдавать наружу и позволять другим разработчикам использовать их...
Короче заставляет задуматься
ну а че там думать. Для сущности создаешь интерфейс или несколько их - те ручки, за которые кто-то извне может дергать класс. А все, что не в интерфейсе - делаешь приватным. Это как паяешь калькулятор и думаешь "а что же мне прятать в корпус, а где отверстия делать" - ну очевидно же, где
@Белояръ Чайка "фасад" назови.
Хочется больше услышать про enterprise, почему джаву не начнут заменять? Или почему не получится написать enterprise на nodejs + nestjs(typeScript). Яндекс деньги переписали вроде, или это другой enterprise? Чем именно незаменима джава, и почем другие статически типизированные языки не могут занять нишу в создании новых enterprise проектов?
Музыка чуть чуть отвлекала громко немного. А так всё поделу, лайкос!
спасибо)
Прикольно. Чого дуже не вистачає - це графічного супроводу, хоча б на папері можна малювати. На жаль, на обличчі нічого не намальовано, а в кадрі лише воно :)
спасибо
О, качество картинки стало круче!)
ничего не понятно, но очень интересно
Все понял. Спасибо!
отлично)пожалуйста)
Серёжа, в Ассемблере всё сложнее с ООП. Ну, ты понял =)
а есть видосик про "новомодное" движение анти-инкапсуляции -- наоборот отделать данные от кода?
пару раз слышал, что на собесе задавали подобные вопрос типа "в чем минусы ООП?"
косвенно к этой же теме: если ООП так круто, почему чтобы узнать про труъ-ООПшные БД приходится гуглить, и оно не используется по умолчанию в каждом чайнике?
Насколько мне известно, абстракция - это принцип любого программирования.
Сложно представить процедурный или функциональный подход без переменных и функций (абстракций?)
А абстракция - это переменные и функции? :D Абстрагированные от класса что ли? или как?))
@@АлексейПоляков-ш1э в широком смысле, абстракция это теоретическое обобщение. так что ответ на ваш вопрос - да.
Переменная это абстракция над конкретными значениями, а функция - над конкретными алгоритмами.
Дмитрий Косачёв уж очень широкий смысл. Можно бесконечно подниматься по уровням абстракции. И таким же образом увеличить количество принципов ООП.
@Дмитрий Косачёв, Согласен, только уточню, что абстракция лежит на более фундаментальном уровне, нежели программирование. Это из области формальной логики, и одинаково используется во множестве дисциплин. Как по мне, абстракция - это лучший инструмент для борьбы со сложностью систем. Поэтому, конечно, это не эксклюзивная особенность ООП. Просто в случае ООП многие создают классы, исходя из сиюминутной выгоды (программирование по принципу: "Велика у стула ножка, подпилю её немножко"), а не исходя из абстрагирования предметной области (тогда бы классы гораздо чаще получались логически-объяснимыми и легко понимаемыми).
@@АлексейПоляков-ш1э Об этом я и говорю. И именно поэтому не стоит называть абстракцию как принцип ООП.
тебе правильно рассказывают, инкапсуляция это не сокрытие, это обеспечение механизма сокрытия
У инкапсуляции вообще нет задачи скрывать что либо.
ВОПРОС - KOTLIN или что-то другое заменит JAVA в АНдроид? Ведь Java не от гугла, а от другой корпорации, уже были с этим проблемы.
заменяет же потихоньку
Т.е можно еще сказать, что главный принцип инкапсуляции - объединение данных в один объект, а сокрытие данных - это уже вспомогательная вещь, без которой наш объект, содержащий данные, был бы доступен для всех.
посоветуйте книгу про ооп спасиба
Добрый день, товарищи. Меня зовут Сергей Немчинский, я программист 9 разряда, почётный ректор Киевского Государственного Института Программостроения и Багоисправления им. Фоксмайндедова.
Thanks!!!
После всего круговорота неоднозначной информации я пришел к следующему пониманию. Скажите верное ли оно или я что-то упустил?
Итак, цитата с википедии:
============================================
В объектно-ориентированных языках программирования и других связанных областях инкапсуляция относится к одному из двух связанных, но разных понятий, а иногда и к их комбинации:
1) Языковой механизм для ограничения прямого доступа к некоторым компонентам объекта .
2) Языковая конструкция, упрощающая объединение данных с методами (или другими функциями), работающими с этими данными.
Некоторые исследователи языков программирования и ученые используют первое значение отдельно или в сочетании со вторым как отличительную черту объектно-ориентированного программирования , в то время как некоторые языки программирования, предоставляющие лексические замыкания , рассматривают инкапсуляцию как особенность языка, ортогонального объектной ориентации.
Второе определение мотивировано тем фактом, что во многих объектно-ориентированных языках и других связанных областях компоненты не скрываются автоматически, и это можно переопределить; таким образом, сокрытие информации определяется как отдельное понятие теми, кто предпочитает второе определение.
=============================================
Предназначение инкапсуляции, как я понял, заключается в том, чтобы отделить интерфейс и реализацию, от нежелательного вмешательства извне к тем вещам, к которым пользователь интерфейса не должен прикасаться и знать о них. И взаимодействовать только через интерфейс.
Таким образом может показаться, что первое понятие из вики справедливо, но достаточно ли только его? Выходит, если так считать, то объединение данных с методами здесь лишнее. В таком случае, что будет сокрываться, если нет объединённых ни методов ни данных?По всей видимости это бессмысленно. Из этого следует что ТОЛЬКО СОКРЫТИЕ - это НЕ инкапсуляция. Может есть языки, где нельзя писать код, не объединяя методы и свойства, тогда для них играет роль только первое определение, а второе идет из коробки.
Идем дальше, ко второй формулировке. Получается, что есть языки в которых объединение методов и свойств не делает их недоступными извне автоматически,
и им для достижения этого требуются свои механизмы, поэтому и зародилась первая формулировка. В итоге это всё равно оба понятия вместе. Из этого следует, что:
СОКРЫТИЕ - ЭТО ИНСТРУМЕНТ ДЛЯ ДОСТИЖЕНИЯ ИНКАПСУЛЯЦИИ, но только его одного недостаточно для этого (следует из вывода абзаца выше), требуется еще и объединение методов и свойств.
????????????????????????????
Осталось проверить последний вариант. Возможна ли инкапсуляция только объединением методов и свойств без сокрытия? Даже если в некоторых ЯП сокрытие идёт из коробки и нам стоит заморочиться только с объединением, всё равно используются два понятия вместе, хоть и одно из них из коробки.
Здесь у меня нет ответа, есть только предположение: добиться инкапсуляции одним лишь объединением нельзя. (скажите так ли это)
Подводя итог, определение инкапсуляции верно если считать оба формулировки неразрывными.
Но почему же всё таки кто-то считает, что верно только первое утверждение, а кто-то что верно второе?
Помогите прояснить сей нюансы, кто действительно понимает. Надеюсь кому-то мои размышления были полезны.
Вы спрашиваете: *В таком случае, что будет сокрываться, если нет объединённых ни методов ни данных?* Детали реализации. И кстати, инкапсуляция - это не сокрытие данных, а изоляция. Т.е., данныне не скрываются, а просто доступ к ним ограничен (см 1 пункт). Например, на языке си, где отродясь не было никаких классов, можно написать библиотеку, которая предоставит пользователям неккое API. При этом сишную библиотеку можно реализовать таким образом, что бы у клиентского кода не было доступа к деталям её реализации.
Вы спрашиваете: *Возможна ли инкапсуляция только объединением методов и свойств без сокрытия?* Объединение данных и методов их обработки - это концепция оопнутого класса. К понятию инкапсуляции не имеет никакого отношения. А теперь возьмем класс на с++. Это пример объединения данных и методов их обработки. Однако все детали реализации оставим в публичной секции. Т.е., они будут доступны любому желающему. В этом случае уже нет никакой изоляции деталей реализации от клиентского кода. В таких случаях говорят: "инкапсуляция отсутствует".
Вы спрашиваете: *почему же всё таки кто-то считает, что верно только первое утверждение, а кто-то что верно второе?* В первом случае люди отталкиваются от предназначения инкапсуляции: *отделить интерфейс и реализацию, от нежелательного вмешательства извне к тем вещам, к которым пользователь интерфейса не должен прикасаться и знать о них* А во втором случае люди просто идиоты, которые несут всякую чушь.
Расскажите пожалуйста какие у Вас есть курсы и для чего какой нужен.
в описании под видео ведь есть список курсов со ссылками на сайт, где о них можно прочитать. А вас вообще какое направление интересует?
"Вторая трактовка без первой не работает совсем" - в этом и смысл. Это не две трактовки, а полное определение инкапсуляции. Объединение логики и данных в единый объект и сокрытие его реализации от окружающих. Как писал небезызвестный Дядя Боб: "самая сильная инкапсуляция в языке C, так как там код делится на хэдер и реализацию, где использующий хэдер не знает ничего о реализации". В шарпе и джаве частично данное поведение имитируют интерфейсы.
Слово "объект" применительно к языку си сбивает с толку. Потому что в си объект - это кусок памяти. Возможно вы имели ввиду: "объединение логики и данных в единый элемент". Но это тоже какой то бред. Возможно вы имели ввиду: "отделение логики и данных, с которыми эта логика работает в отдельный элемент" - вот это уже что-то похожее на правду. Вот только не очень понятно зачем нужна первая трактовка. Итак же понятно: что бы что то инкапсулировать, нужно что бы это что-то было. Поэтому достаточно просто сказать: инкапсуляция - изоляция деталей реализации элемента от клиентского кода" Зы: на сишке можно просто подсмотреть глазками, что есть в исходниках, и выковырять данные (или функции) наружу.
@@princessmary5556 А клиентский код инкапсулироваться не должен что-ли?)) Элемента? Элемента чего? Объект - целостная сущность, а элемент - это часть чего-то, а чего - не уточнено.
Объект - сущность объектно-ориентированных языков(которые, о боже, потому и называются ОБЪЕКТНО-ориентированными). А C - это просто пример возможности реализовать более сильную инкапсуляцию от Мартина.
@@AlexCSharp Вы спрашиваете: *А клиентский код инкапсулироваться не должен что-ли?* Разумеется, он ничего вам не должен, если только не подписал с вами кредитный договор. Вы спрашиваете: *Элемента?* Да. Вы пишите: *Элемента чего?* Неккой системы: библиотеки, проекта, etc. Вы пишите: *Объект - сущность объектно-ориентированных языков* Не только. Объекты бывают не только в ооп. Вы пишите: *C - это просто пример* Когда вы приводите в качестве примера язык си, то вы придерживаетесь терминологии языка си. В языке си, объект - это термин. Вам нужно процитировать точное определение термина? Или сами погуглите?
@@princessmary5556 По делу что-то будет, или софистика - единственное, во что ты умеешь?
Пойду форточку открою, ппц ты душный.
@@AlexCSharp По делу я уже выше подробно расписала. Ппц, вы дебил, который даже не вдупляет гендер человека, с которым вы общаетесь.
Если знакомы с Angular/Angular Material, то хотя бы раз должны были встретится со второй трактовкой инкапсуляции, которую привел автор
Моя самая правильная версия. Инкапсуляция это когда вы программируете:
private int a;
int getA(){return a};
void setA(int a) {this.a = a;}
Добрый день! Скажите плиз, является ли нарушением инкапсуляции случай, если я обращаюсь к полю объекта для того, чтобы узнать его значение? Например, у объекта есть булево значение ready и я обращаюсь к нему if объект.ready is True: делай что-то. Или все-таки нужно писать метод, который будет мне его возвращать?)
Лучше метод isReady(), чтобы не было возможности снаружи поменять его значение.
Да.
сайд эффект? как интересно.... (а что это такое? :)
Побочный эффект
А есть ли языки в которых можно сокрыть данные? Подозреваю что данные всегда можно изменить минуя методы объекта.
с/с++
Не толпа, а друзья Дункана МсЛауда)))
А про SOLID будет?
Есть уже)
@@nelkor3427 уже да) и даже уже все эти видео я посмотрел)
Сергей, а вы случайно снимаете видео не на Logitech C920?
нет
Существует только 3 гендера так сказать. Спасибо за выпуск!
Инкапсуляция реализует абстракцию. Три принципа как есть.
Очень хотелось бы почаще слушать Вас в формате ten minutes about... Удобоваримо объясняете, ёмко. О переменных бы... А вообще хотелось про VAR мнение узнать
На Extreme Code целые холивары по этой теме
XD. Инкапсуляция - это СОКРЫТИЕ! (XD)
@@andreyvolkov3117 I hate you!))
Маслята и Питихон
инкастыляция
А что там еще делать, кроме как холиварить? Вопросы они порой интересные поднимает, но их категоричность, порой вызывает заставляет усомниться в компетентности автора. Я после очередного бреда отписался от них. Обидно не то, что они поленились разобраться, а то что их слушает огромное количество новичков, и они тупо засирают им головы.
гарно
Не понятно, что плохого в скрытии методов в объекте без данных.
Спасибо ,очень понятно и просто. Приятно вас слушать✌️
дякую!!!