По поводу последнего объяснения. Каждый студент может быть человеком потому, что у каждого студента есть все методы и поля, которые присущи человеку. В то же время, у студента в вашем примере есть еще дополнительное поле - направление, которого нет у людей. По этому каждый человек не может быть студентом - у него нет того дополнительного поля, той конкретизации объекта "студент" под названием "направление". Скажем так, на жизненном примере: все огурцы являются овощами, но не все овощи могут быть огурцами. Потому что огурцы имеет свои собственные особенности (поля, методы), как те же студенты имеют направление. По моему, подобное объяснение было бы чуть понятней :) Но всё равно спасибо, что пытаетесь донести до людей принципы ООП.
@@now.7348 Композиция более гибкая, чем наследование. Основное отличие между ними состоит в том, что композиция позволяет переиспользовать код без его расширения. Наследование при этом требует расширения существующего класса. Другое важное отличие: при композиции мы можем повторно использовать код даже из sealed-класса, тогда как унаследоваться от него невозможно.
Володя говорит всё правильно и понятно! То что вы написали, всё он это и говорит, это вы наверное не поняли его, хотя смысл, судя по вашему комментарию, вы поняли Напишу то что говорит Володя: С точки зрения логики: огурец принадлежит овощам С точки зрения программирования: внутри огурца есть все данные овоща!
Наверное будет верно сказать что Студент расширяет Человека :) если же мы говорим о super то extends в современной терминологии. Очень верно наследование подано, как в комбинаторике: В ⊂ A :) Ну а из этого можно кучу всего понять типа операции над множествами и тп и тд :) Спасибо, буду рекомендовать.
У меня наследование зашло, когда услышал слово конкретизация. Когда думаешь, делать класс наследником или нет, очень просто понять, ответив на вопрос: "а ты тем самым конкретизируешь этот класс? Рассматриваешь его подробнее?"
А сейчас я скажу как надо было сделать правильно! Надо было просто написать приложение для оформления документации в виде кода по сути первые языки и были документацией - документация это и есть язык А его синтаксис(но это узкая сфера) более шире - способы выражения языка Способ выражения может быть и блок схема со стрелочками, изображения и ... А вот конкретная реализация это код Базовых функций немного (может быть 100-200 скажем) И четкое описывается их поведение, а вот конкретная реализация оптимизируется под железо На основе этих 100-200 функций и вточности известного их поведения пишется вся остальная документация Т.е. документация документации Витоге такой код если реализованы его базовые функции можна перенести куда угодно Т.е. то что надо было сделать это наиболее простое орудие для оформления документации и формирование кода на ее основе(при реализации базовых функций под конкретную систему конечно) А навели тень на плетень и вместо инструмента для реализации мы получили на выходе кучу условностей Вот что сейчас вобщемто и надо программисту так это хороший инструмент для программирования на документации А реализацию функций он и сам напишет Даже в машинных кодах можна реализовать 100 базовых функций при наличии опокодов системы
Zabavno. Ja u4usj GO a etot video horowo objasnjaet Struct, Type, metodi i daze interfeisi. :) A kak glubako mozhno nasledovatj? Estj lji kakie to ograni4enija?
Вы интересно раскрыли тему. С точки зрения языка человек это то, что вложено уже в понятие студент. Это называется темой в слове вроде уже имеющийся и известный вложенный смысл. А рема это, что то новое вложенное в слово. Но с точки зрения объектов, или популяций студент являются частью понятия человек.
ООП в ЦПП надо рассказывать с проблем, которые возникают в реальной жизни программиста и примеры того, как мысль человеческая изгибалась и какие косяки творили исторически пока пришли к ООП и методы решения этих проблем исторические тоже надо рассказывать, а потом надо рассказать теорию решения этих задачи, а вот тока потом реализацию через ООП ЦПП.. а так само по себе ООП в ЦПП это нечто, что студень слушает и тут же забывает, так как не понятно нахрен так всё усложнять )) вместо того чтобы написать проще в одну строку этот ненавистный код и пойти бухать в кабак представьте себе, что вы семестр изучаете гидравлические тяги в экскаваторе, и в конце вам неожиданно на экзамене препод говорит: вот вы тяги изучили, а теперь расскажите ка, так какие же ямы необходимо копать для домов этажностью свыше 50 )) Вы чувствуете, да? )) ВЫ НЕ СМОЖЕТЕ ПРАВИЛЬНО ВЫКОПАТЬ ЯМУ, ЗНАЯ ИДЕАЛЬНО КАК УСТРОЕН ЭКСКАВАТОР )))))))))) Вы не решите ни одну прикладную задачу на ООП, хоть ТРИЖДЫ вы наязусть запомните весь ООП )) Ну и какой смысл изучать ООП в отрыве от практического применения? потеря времени.. потеря Опять же пишу не о данном ролике. Автор молодец. Суховато, но вполне.. Просьба автора не записывать на свой счёт мои умозаключения выше.
круги Эйлера на доске, намекают на понятие Множество. типа, класс - множество данных и методов для работы с ними. Множество Студент, включает в себя множество Человек.
Мысли в слух... ИМХО Каким образом для человека возникает объектность?! Именно восприятие объектности. Например, мы в школе решаем задачу по геометрии, рисуем треугольник, ставим точки, проводим между ними линии и подписываем углы. Мы этого не замечаем, но наш мозг СРАЗУ организует локальный реестр объектов: А - точка В - точка С - точка АВ - отрезок - значение ВС - отрезок - значение СА - отрезок значение
Извините, но мне кажется что тут есть небольшая ошибка( с точки зрения реализации в языках программирования). Мне не совсем ясно, каким образом мы можем записать в массив "человеки" одного из студентов? Ведь под массив у вас выделяется фиксированное количество памяти, а объект из класса студент будет занимать больше места, чем объект класса человек. Тогда места у вас не хватит. Разве не так?
+Александр Гончаренко Грандиозный комментарий! Это на самом деле будет зависть от того, как именно ваш язык программирования воспринимает работу с объектами. В том случае, если он попытается записать сам объект в массив определённой длинны, то ... что-то должно измениться. В языках вроде C/C++ у вас такого сделать напрямую не получится, сохранив при этом все данные, не получится. А вот если наш язык работает с объектами через ссылки (или если мы работает со ссылками на объекты в C/C++), то в этом случае у вас не будет никаких проблем. Благодарю вас. Возможно дали мне хорошую идею для следущего видео урока.
Да, например, в Джава, если так сделать, то у объекта типа Студент будет доступно только то, что есть у человека, а чисто его студенческие вещи (свойства и поведение) будут недоступны.
Владимир, как в моем понимании исключить парадокс между компьютерным представлением и логическим представлением наследования: если рассматривать классификацию как поиск, то дополнительные поля, которые появляются в дочернем классе, являются дополнительными параметрами для сужения круга поиска
+Ilmir Tazetdinov Интересно. Советую вам развивать эту идею. Она даже может найти очень обширное пременении в ОО языках, в которых нет классов (например Javascript).
Мне кажется, что в этом уроке стоило бы затронуть и наследование методов супер-класса...с ними, лично у меня, было гораздо больше проблем. В целом все неплохо.
Хочу спросить про ожидание человека в аргументе. Это когда мы пишем имя ожидаемого класса "Человек" в аргументе , но можем туда передать и объект студента?
+Том Харди Тема полиморфизма - это сопутствующее понятие. В нём как раз подразумевается, что объект может вести себя как объект своего класса, и также как объект всех его родительских классов. Может и стоило назвать урок "наследование и полиморфизм"...
А разве функция которая должна принимать класс Человек, а принимает - класс студент, не должна Студента преобразовывать в Человека, подобно тому, как int преобразовывается во float в функции, которая это float и принимает?
Почему человека нельзя добавить в массив к студентам? Потому что от студентов мы ожидаем определенного поведения: наличие студ билета, хождение на лекции, привязка к кафедре, а объект человека такими качествами не обладает.
Смешной урок. Студент тоже человек xDD С наследованием понятно. А вот как связать эти классы и дать понять компьютеру что данные одного включают данные другого я не совсем понял. Для этого используется функция что ли?
Carman Schtern Это будет зависить от языка программирования. Например на C++ class Parent { int a; }; class Child : public Parent { int b; }; А на Java class Parent { private int a; } class Child extends Parent { private int b; } Теперь у объектов класса Parent есть целое число a. А у Child-а есть a и b. Но учтите, что они есть-то есть. Но в моём примере не хватает функций доступа к ним.
Ты говоришь что имя студента можна записать в массив имен людей это так но что если потребуется записать направление :) ? По сути дела мы имеем дело с программированием с условностями Ну или если сказать по другому с обусловленным программированием Обусловленно оно понятное дело парадигмами разработчиков Соответственно если ты этих условностей не знаешь то и программировать на с++ ты не сможешь Равно как и понимать код других программистов которые пишут на этом языке
Не понравилось. Некорректно, сумбурно и не понятно для тех, кто не в теме. Если не нравится термин "наследует" применительно к классам, можно было-бы использовать "расширяет". Это более вписывается в парадигму ООП и поведение классов.
Только хотел написать про то, что ещё существует термин "расширение", "расширяет". Тогда диаграмы надо рисовать по-другому. Тогда внутри большого круга с названием Студент будет маленький круг с названием Человек (так как класс не только может получать какие-то поля и методы другого класса, но так же добавлять свои методы и поля; это собственно и было показано: у Студента ещё есть направление, например).
Да ладно, нормально все объяснено, все понятно. Объяснение через расширение это было бы одной стороной медали, т.е. тут автор объяснил и с точки зрения логики, и с точки зрения программирования. Расширение же получилось бы чисто программированием. Хотя я не знаю, почему вы все ругаетесь на слово наследование, ведь в целом, оно все так же подходит. Наследник все так же часть рода так сказать)
да разслабтесь вы сказано же это обусловленное парадигмами разработчиков программирование Т.е. это не логика в чистом виде Если вы хотите программировать на этом языке вам надо знать все эти условности Просто послушать сказочку тех кто этот язык писал и поняв в чем именно и как он обусловлен принимать это в расчет при написании кода Так же прийдется посидеть-посоображать как эти обусловленности взаимосвязаны и взаимодействуют Есть конечно и какие то возможно ограничения возникшие от чисто методологических проблем Т.е. что то у них не получилось реализовать на должном уровне Т.е. это данность вот такая, и чем раньше вы это поймете тем лучше Спрашивать как так это все равно что спрашивать программиста какого лешшего он сюда функцию суммирования добавил, как так , тут больше умножение подойдет Ответ его примерно такой - вот захотелось мне так, конечно они так не отвечают и возможно у них даже есть какое то мнение на этот счет но это лишь мнение (не факт) (хотя и факт присутствия мнения) я бы таким людям нифига бы не доверил :)
Совершенно неверное объяснение наследования с точки зрения теории множеств. В реальной жизни студенты это часть людей. В наследовании -дочерний класс может, как минимум, быть таким же, или расширять функционал родителя. т.е. уж с функцией родителя точно справится. Полиморфизм поведения и изменение области видимости в сторону повышения являются частью той же идеи.
Alex Bekhtin Нет. То что вы сейчас сказали - это именно совершенно верное объяснение. Мне кажется вы сами себя запутали где-то. 1. Класс студенты находится полностью внутри класса Люди. 2. Объект Человек находится полностью внутри объекта Человек. Тут легко запутаться, так как одно подразумевает другое, но звучит совершенно подругому. Для того, чтобы выразить подкласс, вы обязаны дать ему все характеристику суперкласса и возможно ещё какие-то новые.
Vladimir Mozhenkov С точки зрения наследования все люди являются студентами, или любым дочерним классом. т.е. являются как минимум людьми. Любой студент является человеком и даже более. На вашей диаграмме получается, что не всякий студент это человек. Но при наследовании он как минимум человек, и ещё что-то (опционально).
Vladimir Mozhenkov Я обдумал ваши слова и пересмотрел видео. И да. В чём то вы правы. Я думаю что объяснение наследования в теории множеств не совсем корректно. Ваш пример хорошо иллюстрируется если сделать второго наследника от человека. Тогда становится очевидно, что не всё что Человек это Студент, может оказаться, что он тот второй класс. А вот если рассмотреть это с точки зрения функционала, то окажется, что функции человека доступны студенту (пока всё верно - подмножество) и даже шире. Вот это "шире" ни коим образом не укладывается в диаграмму, а именно оно и не даёт Человеку стать Студентом. Если бы оно было просто подмножеством, то с ролью своего подмножества (Студента), класс родитель вполне бы справился. Получается та самая сложность понимания. Я тоже неверно объяснил свою претензию к видео, но суть именно такова. Вообще, считаю что рассматривать наследование в отрывы от полиморфизма тяжело, потому как именно полиморфизм и является конечной целью.
Но "человеков" больше, чем студентов. Толпа студентов находится в толпе людей. Толпа студентов является толпой "человеков". Если к толпе студентов прибавим толпу пенсионеров - это тоже будет толпа "человеков". И пенсионеры в отдельности тоже входят в толпу "человеков". И вот мы на диаграмме рисуем уже второй маленький кружок внутри большого.
По поводу последнего объяснения. Каждый студент может быть человеком потому, что у каждого студента есть все методы и поля, которые присущи человеку. В то же время, у студента в вашем примере есть еще дополнительное поле - направление, которого нет у людей. По этому каждый человек не может быть студентом - у него нет того дополнительного поля, той конкретизации объекта "студент" под названием "направление". Скажем так, на жизненном примере: все огурцы являются овощами, но не все овощи могут быть огурцами. Потому что огурцы имеет свои собственные особенности (поля, методы), как те же студенты имеют направление.
По моему, подобное объяснение было бы чуть понятней :) Но всё равно спасибо, что пытаетесь донести до людей принципы ООП.
Хотел бы более полную, с примерами, инфу когда применять наследование, а когда композицию.
@@now.7348 Композиция более гибкая, чем наследование. Основное отличие между ними состоит в том, что композиция позволяет переиспользовать код без его расширения. Наследование при этом требует расширения существующего класса. Другое важное отличие: при композиции мы можем повторно использовать код даже из sealed-класса, тогда как унаследоваться от него невозможно.
Володя говорит всё правильно и понятно!
То что вы написали, всё он это и говорит, это вы наверное не поняли его, хотя смысл, судя по вашему комментарию, вы поняли
Напишу то что говорит Володя:
С точки зрения логики: огурец принадлежит овощам
С точки зрения программирования: внутри огурца есть все данные овоща!
Он об этом и говорил. "Каждый студент являеется человеком, но не каждый человек может быть студентом".
Дуже гарно пояснюєте. дякую вам
Эх Володя, Володя. Дай вам Бог здоровья!
Наверное будет верно сказать что Студент расширяет Человека :) если же мы говорим о super то extends в современной терминологии.
Очень верно наследование подано, как в комбинаторике: В ⊂ A :) Ну а из этого можно кучу всего понять типа операции над множествами и тп и тд :)
Спасибо, буду рекомендовать.
Отлично объяснил. Палец вверх!
Для меня этот урок уже открытие! Если будут производные от этого урока - буду рад!
все студенты - человеки,
но НЕ все человеки - студенты.
У меня наследование зашло, когда услышал слово конкретизация. Когда думаешь, делать класс наследником или нет, очень просто понять, ответив на вопрос: "а ты тем самым конкретизируешь этот класс? Рассматриваешь его подробнее?"
А сейчас я скажу как надо было сделать правильно!
Надо было просто написать приложение для оформления документации в виде кода
по сути первые языки и были документацией - документация это и есть язык
А его синтаксис(но это узкая сфера) более шире - способы выражения языка
Способ выражения может быть и блок схема со стрелочками, изображения и ...
А вот конкретная реализация это код
Базовых функций немного (может быть 100-200 скажем)
И четкое описывается их поведение, а вот конкретная реализация оптимизируется под железо
На основе этих 100-200 функций и вточности известного их поведения пишется вся остальная документация
Т.е. документация документации
Витоге такой код если реализованы его базовые функции можна перенести куда угодно
Т.е. то что надо было сделать это наиболее простое орудие для оформления документации
и формирование кода на ее основе(при реализации базовых функций под конкретную систему конечно)
А навели тень на плетень и вместо инструмента для реализации мы получили на выходе
кучу условностей
Вот что сейчас вобщемто и надо программисту так это хороший инструмент для программирования на документации
А реализацию функций он и сам напишет
Даже в машинных кодах можна реализовать 100 базовых функций при наличии опокодов системы
хорошо, что не Вы автор видео. Хотя под Ваше изложение можно быстро уснуть, это плюс.
Zabavno. Ja u4usj GO a etot video horowo objasnjaet Struct, Type, metodi i daze interfeisi. :) A kak glubako mozhno nasledovatj? Estj lji kakie to ograni4enija?
Второе видео тоже классное)
Спасибо!
Вы интересно раскрыли тему. С точки зрения языка человек это то, что вложено уже в понятие студент. Это называется темой в слове вроде уже имеющийся и известный вложенный смысл. А рема это, что то новое вложенное в слово. Но с точки зрения объектов, или популяций студент являются частью понятия человек.
Про щелчек в мозгу - все действительно так!
фильма "Матрица" вспоминается)
ООП в ЦПП надо рассказывать с проблем, которые возникают в реальной жизни программиста и примеры того, как мысль человеческая изгибалась и какие косяки творили исторически пока пришли к ООП и методы решения этих проблем исторические тоже надо рассказывать, а потом надо рассказать теорию решения этих задачи, а вот тока потом реализацию через ООП ЦПП..
а так само по себе ООП в ЦПП это нечто, что студень слушает и тут же забывает, так как не понятно нахрен так всё усложнять )) вместо того чтобы написать проще в одну строку этот ненавистный код и пойти бухать в кабак
представьте себе, что вы семестр изучаете гидравлические тяги в экскаваторе, и в конце вам неожиданно на экзамене препод говорит: вот вы тяги изучили, а теперь расскажите ка, так какие же ямы необходимо копать для домов этажностью свыше 50 ))
Вы чувствуете, да? )) ВЫ НЕ СМОЖЕТЕ ПРАВИЛЬНО ВЫКОПАТЬ ЯМУ, ЗНАЯ ИДЕАЛЬНО КАК УСТРОЕН ЭКСКАВАТОР )))))))))) Вы не решите ни одну прикладную задачу на ООП, хоть ТРИЖДЫ вы наязусть запомните весь ООП ))
Ну и какой смысл изучать ООП в отрыве от практического применения? потеря времени.. потеря
Опять же пишу не о данном ролике. Автор молодец. Суховато, но вполне.. Просьба автора не записывать на свой счёт мои умозаключения выше.
Владимир, а что вы думаете про множественное наследование, хорошо это или плохо?
Alex Demeamiuk Это отдельная и очень большая тема. Если кратко, то если это делать правильно, то это очень мощный подход способный на многое.
круги Эйлера на доске, намекают на понятие Множество. типа, класс - множество данных и методов для работы с ними. Множество Студент, включает в себя множество Человек.
Отлично!
Володя молодчина!
стало ясно почти сразу, что-то такое было в высшей математике :)
жЫрный лайк!
Мысли в слух... ИМХО
Каким образом для человека возникает объектность?! Именно восприятие объектности.
Например, мы в школе решаем задачу по геометрии, рисуем треугольник, ставим точки, проводим между ними линии и подписываем углы.
Мы этого не замечаем, но наш мозг СРАЗУ организует локальный реестр объектов:
А - точка
В - точка
С - точка
АВ - отрезок - значение
ВС - отрезок - значение
СА - отрезок значение
Извините, но мне кажется что тут есть небольшая ошибка( с точки зрения реализации в языках программирования).
Мне не совсем ясно, каким образом мы можем записать в массив "человеки" одного из студентов? Ведь под массив у вас выделяется фиксированное количество памяти, а объект из класса студент будет занимать больше места, чем объект класса человек. Тогда места у вас не хватит. Разве не так?
+Александр Гончаренко Грандиозный комментарий!
Это на самом деле будет зависть от того, как именно ваш язык программирования воспринимает работу с объектами. В том случае, если он попытается записать сам объект в массив определённой длинны, то ... что-то должно измениться. В языках вроде C/C++ у вас такого сделать напрямую не получится, сохранив при этом все данные, не получится.
А вот если наш язык работает с объектами через ссылки (или если мы работает со ссылками на объекты в C/C++), то в этом случае у вас не будет никаких проблем.
Благодарю вас. Возможно дали мне хорошую идею для следущего видео урока.
я правильно понимаю , что в подразумевалось отношение видовых(Суперкласса) и родовых(подкласса) понятии??
Да, например, в Джава, если так сделать, то у объекта типа Студент будет доступно только то, что есть у человека, а чисто его студенческие вещи (свойства и поведение) будут недоступны.
Владимир, как в моем понимании исключить парадокс между компьютерным представлением и логическим представлением наследования: если рассматривать классификацию как поиск, то дополнительные поля, которые появляются в дочернем классе, являются дополнительными параметрами для сужения круга поиска
+Ilmir Tazetdinov Интересно. Советую вам развивать эту идею. Она даже может найти очень обширное пременении в ОО языках, в которых нет классов (например Javascript).
В EcmaScript уже есть классы !
Вот ссылка на курс: www.codeschool.com/courses/es2015-the-shape-of-javascript-to-come
Мне кажется, что в этом уроке стоило бы затронуть и наследование методов супер-класса...с ними, лично у меня, было гораздо больше проблем.
В целом все неплохо.
Почему непонятно, это же как одна папка в другой папке!
Либо я совсем не понял или что то пропустил, раз для меня всё логично.
Все палки деревянные, но не все деревянные палки бывают дубовыми. Они могут быть кленовыми, березовыми и т.д., но все они деревянные.
Хочу спросить про ожидание человека в аргументе. Это когда мы пишем имя ожидаемого класса "Человек" в аргументе , но можем туда передать и объект студента?
студент тоже человек :)
Владимир, как вы смотрите на , чтобы вместо понятия класс использовать понятие "категория"?😊
Добрый день, донатить ещё актуально?
Владимир, Вы скорее тут задели еще и тему полиморфизма, но не назвали её таковой.
+Том Харди Тема полиморфизма - это сопутствующее понятие. В нём как раз подразумевается, что объект может вести себя как объект своего класса, и также как объект всех его родительских классов.
Может и стоило назвать урок "наследование и полиморфизм"...
Ох он и кумарный
А разве функция которая должна принимать класс Человек, а принимает - класс студент, не должна Студента преобразовывать в Человека, подобно тому, как int преобразовывается во float в функции, которая это float и принимает?
Вяч Шева Происходит конвертация указателя, а сам объект уже готов. Чуть позже выложу видео об этом, оно уже снято.
Спасибо за ответ.
Почему человека нельзя добавить в массив к студентам? Потому что от студентов мы ожидаем определенного поведения: наличие студ билета, хождение на лекции, привязка к кафедре, а объект человека такими качествами не обладает.
Смешной урок. Студент тоже человек xDD
С наследованием понятно. А вот как связать эти классы и дать понять компьютеру что данные одного включают данные другого я не совсем понял. Для этого используется функция что ли?
Carman Schtern Это будет зависить от языка программирования.
Например на C++
class Parent
{
int a;
};
class Child : public Parent
{
int b;
};
А на Java
class Parent
{
private int a;
}
class Child extends Parent
{
private int b;
}
Теперь у объектов класса Parent есть целое число a. А у Child-а есть a и b. Но учтите, что они есть-то есть. Но в моём примере не хватает функций доступа к ним.
Всё ясно, спасибо.
Vladimir Mozhenkov , было бы воопше сууупер, если бы вы уделяли несколько минут практике и демонстрации кода
Ты говоришь что имя студента можна записать в массив имен людей это так но что если потребуется записать направление :) ?
По сути дела мы имеем дело с программированием с условностями
Ну или если сказать по другому с обусловленным программированием
Обусловленно оно понятное дело парадигмами разработчиков
Соответственно если ты этих условностей не знаешь то и программировать на с++ ты не сможешь
Равно как и понимать код других программистов которые пишут на этом языке
Не понравилось. Некорректно, сумбурно и не понятно для тех, кто не в теме. Если не нравится термин "наследует" применительно к классам, можно было-бы использовать "расширяет". Это более вписывается в парадигму ООП и поведение классов.
Только хотел написать про то, что ещё существует термин "расширение", "расширяет". Тогда диаграмы надо рисовать по-другому. Тогда внутри большого круга с названием Студент будет маленький круг с названием Человек (так как класс не только может получать какие-то поля и методы другого класса, но так же добавлять свои методы и поля; это собственно и было показано: у Студента ещё есть направление, например).
Да ладно, нормально все объяснено, все понятно. Объяснение через расширение это было бы одной стороной медали, т.е. тут автор объяснил и с точки зрения логики, и с точки зрения программирования. Расширение же получилось бы чисто программированием. Хотя я не знаю, почему вы все ругаетесь на слово наследование, ведь в целом, оно все так же подходит. Наследник все так же часть рода так сказать)
вебмани не удобно, сделай киви
Володя, добавь себе яндекс кошелек. Не всем удобно вебмани.
да разслабтесь вы сказано же это обусловленное парадигмами разработчиков программирование
Т.е. это не логика в чистом виде
Если вы хотите программировать на этом языке вам надо знать все эти условности
Просто послушать сказочку тех кто этот язык писал и поняв в чем именно и как он обусловлен принимать это в расчет при написании кода
Так же прийдется посидеть-посоображать как эти обусловленности взаимосвязаны и взаимодействуют
Есть конечно и какие то возможно ограничения возникшие от чисто методологических проблем
Т.е. что то у них не получилось реализовать на должном уровне
Т.е. это данность вот такая, и чем раньше вы это поймете тем лучше
Спрашивать как так это все равно что спрашивать программиста какого лешшего он сюда функцию суммирования добавил, как так , тут больше умножение подойдет
Ответ его примерно такой - вот захотелось мне так, конечно они так не отвечают и возможно у них даже есть какое то мнение на этот счет но это лишь мнение (не факт) (хотя и факт присутствия мнения)
я бы таким людям нифига бы не доверил :)
Ольга Татуревич,
у вас ус отклеился.
Володь, дай PayPal. Спасибо за туруды!
+Vladimir Krylov Указан на канале: Volodya@WhenGendarmeSleeps.org
Совершенно неверное объяснение наследования с точки зрения теории множеств. В реальной жизни студенты это часть людей. В наследовании -дочерний класс может, как минимум, быть таким же, или расширять функционал родителя. т.е. уж с функцией родителя точно справится. Полиморфизм поведения и изменение области видимости в сторону повышения являются частью той же идеи.
Alex Bekhtin Нет. То что вы сейчас сказали - это именно совершенно верное объяснение. Мне кажется вы сами себя запутали где-то.
1. Класс студенты находится полностью внутри класса Люди.
2. Объект Человек находится полностью внутри объекта Человек.
Тут легко запутаться, так как одно подразумевает другое, но звучит совершенно подругому. Для того, чтобы выразить подкласс, вы обязаны дать ему все характеристику суперкласса и возможно ещё какие-то новые.
Vladimir Mozhenkov С точки зрения наследования все люди являются студентами, или любым дочерним классом. т.е. являются как минимум людьми. Любой студент является человеком и даже более. На вашей диаграмме получается, что не всякий студент это человек. Но при наследовании он как минимум человек, и ещё что-то (опционально).
Alex Bekhtin Значит вы неправильно рассмотрели диаграмму.
Alex Bekhtin P.S. "С точки зрения наследования все люди являются студентами" нет. Все студенты являются людьми. Есть люди, которые не студенты.
Vladimir Mozhenkov Я обдумал ваши слова и пересмотрел видео. И да. В чём то вы правы. Я думаю что объяснение наследования в теории множеств не совсем корректно. Ваш пример хорошо иллюстрируется если сделать второго наследника от человека. Тогда становится очевидно, что не всё что Человек это Студент, может оказаться, что он тот второй класс. А вот если рассмотреть это с точки зрения функционала, то окажется, что функции человека доступны студенту (пока всё верно - подмножество) и даже шире. Вот это "шире" ни коим образом не укладывается в диаграмму, а именно оно и не даёт Человеку стать Студентом. Если бы оно было просто подмножеством, то с ролью своего подмножества (Студента), класс родитель вполне бы справился. Получается та самая сложность понимания. Я тоже неверно объяснил свою претензию к видео, но суть именно такова. Вообще, считаю что рассматривать наследование в отрывы от полиморфизма тяжело, потому как именно полиморфизм и является конечной целью.
студент не внутри человека, а наоборот, челевек внутри студента, дочерний класс всегда больше суперкласса
Но "человеков" больше, чем студентов. Толпа студентов находится в толпе людей. Толпа студентов является толпой "человеков". Если к толпе студентов прибавим толпу пенсионеров - это тоже будет толпа "человеков". И пенсионеры в отдельности тоже входят в толпу "человеков". И вот мы на диаграмме рисуем уже второй маленький кружок внутри большого.
В данном примере рассматривается не отношение классов, а отношение множеств.
Потеря времени