2:02 - Пример структур на C 4:36 - Пример на Pascal 7:10 - Пример на Rust 8:12 - Пример на JavaScript 9:15 - Пример с использованием классов 16:35 - Пример на TypeScript 18:30 - Резюме
То есть вопрос использовать классы или структуры(обьекты, классы без методов) зависит от моделируемой сущности из предметной области? А есть какие-то плюсы от использования структур? Ну плюсов наверное нет от реализации структуры на js в виде обьектов
зависит от того, есть ли у этой сущности поведение или нет. У записи про пользователя, например, или у товара на складе поведения нет, оно есть у пользователя, но не у записи про пользователя. Если мы моделируем паспорт, то метод выдатьПаспорт будет не у паспорта, а у органа, который выдает паспорт, а у паспорта ни каких методов нет, это структура.
Получается структура это типа упрощенный обьект без методов не ссылочного типа. А обычный скаляр который можно сравнивать между собой. Но в js такая фигня отсутствует.
Я вот сейчас потратил час на философский спор с самим собой о применении классов и структур. Я все понял, в каком случае применяются классы, а в каком случае структуры. Но в итоге у меня образовался ментальный конфликт: я теперь не понимаю рациональную суть в применении в одном приложении одного и другого подходов одновременно: классы и структуры с имплементацией методов. Типа, в классах у нас структуры у которых есть свое поведение, а если у структуры нет своего поведения то считается правильным реализовать такую структуру как структуру с имплементацией методов (если нужно что-то посчитать с этими данными). И в чем прикол? Мы в любом способе в итоге будем вызывать методы у конкретного инстанса структуры данных (класса или структуры). Получается это какой-то религиозный спор. Какая нам разница от нашего восприятия и понимания, есть у этой структуры свое поведение или у нее просто должны быть методы для работы с ее данными, если логическая работа с этими структурами данных та же? В таком случае, следуя такой парадигме, если мы считаем, что у нас не живая структура для которой просто нужны методы чтобы что-то посчитать, то неправильно имплементировать методы для этой структуры. Нужно придумать и создать класс, "живой" сущности которая умеет что-то делать, у которого есть методы для работы с данными из этой структуры. Тогда это будет следовать той логике, что у анемичной структуры нет и не может быть своего поведения. А тут получается что мы просто меняем синтаксис для описания одного и того же в зависимости от нашего ментального понимания объекта (живой он или не живой). Ну бред же =) Или поправьте меня пожалуйста, если я неправильно, что-то понял. Я лично вижу это так: или всегда использовать только классы, или всегда только структуры, или использовать классы для структур с методами, а структуры использовать только для описания структур данных и не имплементировать методы. Или хотя бы не смешивать в одной программе ООП подход и имплементацию методов для анемичных моделей.
Ну ибо JS по образу и подобию Си. А вообще они очень похожи. Сегодня самые популярные и практичные языки Си подобные, причем чем более похоже на Си тем популярнее.
Супер, в С++ был по-моему еще union. Как сказано сейчас он устарел, или я ошибаюсь? Он актуален и для чего использовался. В книгах это вскользь описывается.
Все ок с юнионом в C, это способ обращаться к одному и тому же куску памяти как к разным типам, т.е. можно объединить юнионом char и byte и они будут в одной памяти храниться, а обращение разное.
@@TimurShemsedinovСпасибо. Я помню, как я таким способом пытался выполнить задание создать двусвязный список на С++, который мог бы хранить значения любого типа. Там меня раскритиковали, описали типу вот union не используется уже в С++. Я пишу в старом стиле. На том мои пробы и окончились. Но механизм как мне помнится работал. Такие разные программисты-критики.
2:02 - Пример структур на C
4:36 - Пример на Pascal
7:10 - Пример на Rust
8:12 - Пример на JavaScript
9:15 - Пример с использованием классов
16:35 - Пример на TypeScript
18:30 - Резюме
Тимур, вы очень круты! Магия вашего материала делает из кодеров программистов. Доносите фундаментальные знания до масс. Спасибо!)
Иногда мне кажется, что ваши знания в кодинге бесконечны
уже успел с struct познакомиться в Rust. Видео смотрелось как повтор пройденного материала, легко )
То есть вопрос использовать классы или структуры(обьекты, классы без методов) зависит от моделируемой сущности из предметной области?
А есть какие-то плюсы от использования структур?
Ну плюсов наверное нет от реализации структуры на js в виде обьектов
зависит от того, есть ли у этой сущности поведение или нет. У записи про пользователя, например, или у товара на складе поведения нет, оно есть у пользователя, но не у записи про пользователя. Если мы моделируем паспорт, то метод выдатьПаспорт будет не у паспорта, а у органа, который выдает паспорт, а у паспорта ни каких методов нет, это структура.
@@TimurShemsedinov, понял спасибо
Было бы хорошо поменять видео в плейлисте, чтобы были по порядку.
Эх, как будет время
Получается структура это типа упрощенный обьект без методов не ссылочного типа. А обычный скаляр который можно сравнивать между собой. Но в js такая фигня отсутствует.
Скаляр это по определению одно значение. Структуры собираются вводить в js, уже есть проект стандарта
в паскале в нулевом байте строки её длина
Да, паскаль подзабыл, сори
Я вот сейчас потратил час на философский спор с самим собой о применении классов и структур.
Я все понял, в каком случае применяются классы, а в каком случае структуры. Но в итоге у меня образовался ментальный конфликт: я теперь не понимаю рациональную суть в применении в одном приложении одного и другого подходов одновременно: классы и структуры с имплементацией методов.
Типа, в классах у нас структуры у которых есть свое поведение, а если у структуры нет своего поведения то считается правильным реализовать такую структуру как структуру с имплементацией методов (если нужно что-то посчитать с этими данными).
И в чем прикол?
Мы в любом способе в итоге будем вызывать методы у конкретного инстанса структуры данных (класса или структуры). Получается это какой-то религиозный спор. Какая нам разница от нашего восприятия и понимания, есть у этой структуры свое поведение или у нее просто должны быть методы для работы с ее данными, если логическая работа с этими структурами данных та же?
В таком случае, следуя такой парадигме, если мы считаем, что у нас не живая структура для которой просто нужны методы чтобы что-то посчитать, то неправильно имплементировать методы для этой структуры.
Нужно придумать и создать класс, "живой" сущности которая умеет что-то делать, у которого есть методы для работы с данными из этой структуры. Тогда это будет следовать той логике, что у анемичной структуры нет и не может быть своего поведения.
А тут получается что мы просто меняем синтаксис для описания одного и того же в зависимости от нашего ментального понимания объекта (живой он или не живой). Ну бред же =) Или поправьте меня пожалуйста, если я неправильно, что-то понял.
Я лично вижу это так: или всегда использовать только классы, или всегда только структуры, или использовать классы для структур с методами, а структуры использовать только для описания структур данных и не имплементировать методы.
Или хотя бы не смешивать в одной программе ООП подход и имплементацию методов для анемичных моделей.
Вот тут я не понял. Но отвечу: нужно почитать код Метархии, например. И да, нет одного единственно правильного способа, есть разные подходы.
Ого Сишка, не жаваскрипт
Пока что-то помню, папа может си
Ну ибо JS по образу и подобию Си. А вообще они очень похожи. Сегодня самые популярные и практичные языки Си подобные, причем чем более похоже на Си тем популярнее.
теперь стало понятно почему в js у функций конструкторов принято методы вешать на прототип, а не на создаваемый экземпляр непосредственно.
Постойте если генерировать массивы структур то C ничем не хуже C++. Я заинтересовался сишкой.
C вообще гораздо лучше C++, как на меня
Супер, в С++ был по-моему еще union. Как сказано сейчас он устарел, или я ошибаюсь? Он актуален и для чего использовался. В книгах это вскользь описывается.
Все ок с юнионом в C, это способ обращаться к одному и тому же куску памяти как к разным типам, т.е. можно объединить юнионом char и byte и они будут в одной памяти храниться, а обращение разное.
@@TimurShemsedinovСпасибо. Я помню, как я таким способом пытался выполнить задание создать двусвязный список на С++, который мог бы хранить значения любого типа. Там меня раскритиковали, описали типу вот union не используется уже в С++. Я пишу в старом стиле. На том мои пробы и окончились. Но механизм как мне помнится работал. Такие разные программисты-критики.
@@masterguyver84 это правильнее делать на днерериках (обобщенном программировании, шаблонах)
@@TimurShemsedinov Вот на тот период я этого не знал спасибо.
Насколько я знаю в C++ когда дело доходит до производительности то использоваться может все - и вне зависимости от красоты применения.
Спасибо!
Спасибо.