Здравствуйте, мои дорогие. И сегодня я с вами хочу поговорить про обучение вождению. Вождение автомобиля - это управление автомобилем. Управление автомобилем это управлением движением. Управление может быть ручкой (это первые автомобили), рулем, штурвалом, джойстиком. Джойстиком можно управлять самолетом Боинг, мы как раз запустили такой курс, приходите к нам учиться. Управление ручкой удобно на первых автомобилях, но если вы хотите ехать быстро, то выбирать нужно управление рулем. В современных автомобилях для управления есть руль (его нужно крутить) и педальки (их нужно нажимать). Если вы сейчас тот самый человек, который выбирает какие-то курсы, автошколу, то я фактически вам рассказал все, что надо знать. Да конечно, вам расскажут про какие-то ПДД, дорожные знаки, безопасность маневров. Я вижу, что там обучение занимает, ну какие-то даже месяцы, я не могу этого понять, с моей точки зрения вождению нужно учиться в реальной ситуации, прямо выезжаете в центр большого города и сразу учитесь. И по большому счету - про педальки и руль я вам рассказал, это все основы и вам нужно быстрее сесть за руль и ехать. В общем не понимаю я эти автошколы, зачем они это делают, возможно выгодно вам продать права на вождение. Люблю вас, подписывайтесь, ставьте лайки и ... пока!
Абсолютно согласен. Помню когда после Си начал изучать С++ все было легко и понятно, и я очень быстро начал писать на С++ ПРОЦЕДУРНЫЙ код. Овладел ООП только спустя пару лет - когда стал "видеть улицу с другой точки зрения". За те два года я очень много писал программ, и когда поведение программы сильно усложнялось - приходило понимание как применять объекты.
Меня вынужденный переход с С++ на Java сильно в понимании ООП подтолкнул, там в принципе не может быть кода вне классов. Пришлось сначала выдумывать что в какой класс запихать, чтобы эта сволочь хоть как-то заработала, а потом уже и мозг перестроился. Но на старый свой код теперь без слез не взглянешь)
Никто не ответит на этот вопрос. Когда война закончится, Украина освободит все свои территории и Россия будет платить репарации. И то не факт, что после этого Немчинский разрешит курсы.
В программировании парадигма -- скорее подход, чем взгляд. Процедура (подпрограмма) работает со своими данными и может вызываться неоднократно, что экономит труд. Но данные портятся при параллельном вызове одной и той же процедуры. Поэтому придумали классы -- упрятывание процедур и их данных в описание. Каждый раз при вызове класса из любого места программы из описания в памяти порождается содержимое класса (объект), и с ним работают. Это также экономит код, но при параллельных порождениях объектов их данные не портятся. ООП -- это просто!
То есть вы свели всю ООП к инкапсуляции? И решили, что ООП - это просто? Инкапсуляция - это подход, но ООП не сводится к инкапсуляции и может существовать без инкапсуляции. А защиту данных от внешнего вмешательства мы можем сделать через замыкания или еще каким-либо образом, не обращаясь к ооп.
9:02 чем они особенные в этом плане? Они всего лишь передают видео потоком, где там много разных потоков данных? В этом примере, думаю, было бы более кстати примеры каких-то realtime приложений, где действительно все выстроено как dataflow, например через Rx
Имхо, ООП , конечно, классно, но ей не хватает правил для определения объектов. Хотя такие правила есть в теории баз данных - обеспечение оптимального хранения всей необходимой информации, нормализация и т.п. Например, есть склад, где можно выделить объект "товар", а можно выделить "транзакцию"(любое перемещение товара). Второй вариант больше подходит для учёта, особенно когда товары делимы (например, можно отсыпать часть товара). Возможно, та же фигня и с потоковым видео.
Там в Ютубе, есть данный который я посмотрел это видео спустя 9 месяцев после выхода на ютюб? Если нет то что бы выводить такую информацию нужно опять запрагроммироват кто? Оба? Или фульстак сам сможет? Ответе пожалуйста языком как программиста
Не верьте этому дяде, что за бабло и 2 недели он научит Вас ООП. Просто начинайте кодить на плюсах или решетке. И через несколько лет и несколько десятков проектов, таки дошедших до продакшена, Вы с удивлением для себя обнаружите, что Ваша башка уже мыслит объектно - ориентировано, а не процедурно, как было ранее.
Я так и не понял, чем процедура отличается от объекта, кроме названия. Интересно было бы сделать одну и туже задачу двумя этими способами и показать разницу. Методы объектов это те же параметры процедуры. Но гораздо сложнее в написании.
Нихрена себе! Я понял с этого видео, что такое ооп! Как он сказал про потоковую обработку, что её сложно подогнать под ооп, потому что само описание предметной области не содержит толком объектов, так я понял, что в коде надо объекты(экземпляры классов, которые составляют объекта предметной области) искать и смотреть что они делают, оставляя остальной код на потом. И теперь стало яснее, что именно происходит и как и почему.
Процедурное программирование более универсально. ООП не везде разумно использовать. А бардак при разработке это не проблема используемой парадигмы. Это пренебрежительное отношение к документации и планированию, распределению зон ответственности, разработке единого стиля при написании кода, и.т.д.
Вы представили все ООП только в разрезе инкапсуляции. Лишь вскольз упомянув о всех трех принципах: инкапсуляция, полиморфизм и наследование. Это как бы и есть те три слона, на которых базируется мир ООП на заставке к ролику. Так про всех слонов и надо бы, наверное. Может поэтому другие курсы обширнее? Вы выбрали одного слона (инкапсуляцию), назначив его главным. Ну это в общем-то известная общая проблема. Большинство программистов именно так и понимают ООП, как инкапсуляцию. И для них понятие полиморфизма чуждо, наследование еще куда ни шло. Такие разработчики не понимают, что такое интерфейсы и зачем они нужны. Они их используют чисто в разрезе практик и паттернов. Абсолютно не понимая смысла. Разработчики, освоившие изначально процедурный стиль, понимая только инкапсуляцию, начинают писать программы в ООП в том же процедурном стиле. Осознавая классы как микробиблиотеки процедур с упакованными микробиблиотечными свойствами, удобные в использовании. И не более. Кстати, вы упустили важный шаг в истории про переход от процедурного стиля к ООП, это процедурные библиотеки (модули, в некоторых языках), которые уже умели инкапсулировать свойства и методы. Но толчком к переходу к ООП стали именно наследование и полиморфизм. PS. Ну и стоит наверное с самого начала четко разделять классы и объекты (как экземпляры классов). Первое, с чем сталкивается новичок - это непонимание чем отличается класс от объекта. А вы тут в ролике классы объектами называете. PS2. Первая ключевая проблема процедурного подхода, это конечно же не проблема упорядочивания процедур, а потеря управляемости в связи с том, что процедуры начинают связываться логикой, которая никак не оформлена специально (не инкапсулирована), эта логика держится только в голове программиста, освоившего нужные библиотеки и понявшего взаимосвязь процедур. Вторая ключевая проблема процедурного подхода - полное отсутствие полиморфизма. Долгое время не было осознания необходимости полиморфизма. Наследование худо бедно можно реализовать в процедурах, инкапсуляцию тоже, но только не полиморфизм. Это ничем не эмулировать. Это внутри механизма ООП. И вот когда пришло осознание, что никакими ухищрениями полиморфизм не реализовать в процедурах, вот тогда ООП пришел в отрасль окончательно.
Если бы ООП было только про принцип разбиения процедур и описания типов на блоки, то никто не называл бы это парадигмой, скорее подходом. Причем такой подход и так легко применяется в процедурных языках - один файлик разбиваем на множество, а для удобства поиска создаем иерархию модулей по предметной области. Так что это видео даже отдаленно не про ООП.
Это видео про то, как у них классно учат, а у других хуже. Немчинский рекламщик с претензий на серьезные вещи. Не обосрать других - это нужно иметь культурный багаж в несколько поколений... Джентльмен - это чел у которого три поколения имеют диплом Оксфорда!
Добрый день, подскажите пожалуйста, поступил на курсы по Data Since , они будут идти около года, можно ли мне изучать параллельно английский язык или он будет мешать обучению на курсах?
Отсутствие знания английского будет мешать обучению на IT-курсах существенно сильнее. Практически любой популярный язык программирования и почти вся IT-терминология основана на английском языке. Так что какие-то конструкции изучаемого вами языка программирования будут для вас либо непонятными наборами букв, которые придется зубрить как заклинания, либо почти связными, хоть и примитивными, предложениями на английском языке, которые при знании английского несложно читать и строить самостоятельно.
Ваще пофиг. Даже если будешь английский знать, будешь видеть тарабарщину. Я свою первую прогу написал переводя через яндекспереводчик названия переменных. Английский вообще никак не помогает, основа это реальные примеры кода которые находил в инете, например на стаке. Уже конечно поздно, но если есть возможность переходи на разработчика. В дата саентис ломанулась куча народа, а больше работы не стало. При этом профа хоть и востребована, но и специфичной т.к. каким-нибудь рогам и копытам нафиг не сдался дата саентис. А вот сайт им нужен и разраб всегда работу найдёт. Без опыта ты будешь год работу искать и то не факт что найдёшь, это самый большой минус дата саентиса. Потом уже сможешь на дата саентиса выучиться и уйти.
Сергей, в процедурном нам никто не мешает разбить процедуры логически по модулям, например StrUtils. Но проблема с поиском кода все еще останется. Пользовательские типы - классы создают явные связи, одни вызывают другие и потянув за один, мы вытягиваем себе всю необходимую для работы цепочку. Настройки подключения -> сессия -> исполнение sql. В процедурном тоже конечно видно связи модулей по импортам, но все это крайне быстро превращается в ад. В питоне с этим сложнее, но в статической типизации наш код даже не запустится пока мы не внедрим все нужные зависимости.
Я, как человек который много много раз за много много лет гуглящему "что такое ООП?" могу с уверенностью заявить: Нифига вы не объяснили. Да, сейчас то я уже знаю что это такое но этот видос такой-же нифига реально не объясняющий как и куева туча остальной информации в сети. И, ДА, понял я это только по практике, когда в один прекрасный момент было: "Ааааааа, воооооот, я понял"!
@@Konev-VA Ну так, а почему бы не объяснить это раньше? Суть то видео в чём??? Яркий пример это видео где объясняется число Пи, конечно же я знал что Пи это 3,14 - это же все знают, вот там, как говориться, на пальцах объяснено, и вот только поле того видео я понял "что это" и "зачем это". Вот и тут так, я знаю что ООП это парадигма, а вот суть "что это" и "зачем это", для тех кто совсем не в курсе, здесь не доведено...
@@dimkinn1 Это типа как ты не понял что я объяснил??? Попробую еще раз: Я, как человек давно уже знающий что это такое и объясняю что это видео этого не объясняет совсем, как и тонны подобных статеек и видосиков... И нех тут выделываться, показывать на машину и говорить что это "машина" не объясняет никуёшеньки!!! P. S. И говорить что она "ездит" тоже не объясняет никуя...
@@ni55an а потом GC придет все эти объекты собирать... а вообще скорее всего имеется ввиду, что такую систему куда проще задизайнить в функциональной парадигме, нежели в объектной. Просто нет смысла забивать гвоздь экскаватором
@@ksviety чтобы никто не приходил, можно вообще на C писать и самому чистить память, но какой в этом смысл, если память и процессоры стоит дешевле, чем работа прогера? Не сказал бы, что в функциональной проще задизайнить. В ней нужно строго следить за иммутабельностью, сайд эффектами и т.д., а ООП в этом не ограничивает. Экскаватор это инструмент, а парадигма это не инструмент, это концепция
Смысл ООП в том, что эта парадигма позволяет создавать данные в рантайме. Т.е. управлять динамически изменяемым дампом памяти в процессе работы программы. Все остальное - это шелуха. Хотя, понимаю, что это трудно объяснить на раз людям , которые , особенно, никогда не имели дело с языками программирования, в которых дамп данных статичен... )))) Являюсь Вами подписчиком. У Вас большой талант общаться с людьми ...)))))))
ОБЬ - Корень слова "обьяснение", поймёшь что означает корень поймешь это слово и осознаешь что это видео не о том о чём ты предполагал :) Лайк за тупейшую очепятку!!!
Новички теперь задаются вопросом: "В чем всё-таки разница между процедурой и объектом?" Звучит как: в чем разница между умением говорить и человеком? - то есть вещи очевидно несравнимые. Объект лучше понимается через противопоставление его структуре данных, эти две концепции - абсолютные антиподы. Процедура в процедурной парадигме будет совершать операции над структурой данных, но в ООП та же самая процедура как неотъемлемая часть объекта будет совершать манипуляции над данными/состояниями своего объекта. В процедурной парадигме - процедуры являются центром мироздания, а в ООП мы имеем дело с объектоцентризмом. Инкапсуляция, полиморфизм, абcтракция и наследование - это техники, повышающие качество объекто-ориентированного кода, но не являются необходимым условием для ООП.
Объект - это набор переменных (свойства) и функций (методы), которые характеризуют структуру данных из предметной области. Класс - это заготовка для объекта. Соответственно, объект - экземпляр класса. Например операторными скобками { } инкапсулируют, т.е. скрывают логику в этой части программы от всей прочей. Вот точно также парадигмой ООП проектируют каждую программу, которая сложна, как внешний мир и его предметные области. Для меня описание выше когда дошло лучше прочих философских рассуждений.
Класс - это не заготовка. Это класс. Так и надо изначально говорить, чтобы потом не говорить о классе, как о шаблоне или заготовке. Класс - это описание набора свойств (определяют состояние) и методов (определяют поведение), которые характеризуют декомпозированный элемент предметной области. Объект - экземпляр класса, отражающий состояние и поведение конкретного элемента предметной области в соответствии со спецификацией класса. И инкапсуляция - это не скрытие логики. Класс - это не черный ящик. Инкапсуляция - это группировка состояния и поведения в одном месте (в классе), которое человек способен контролировать, и управляемость которого гарантирована "контрактами" ООП конкретного языка (например, модификаторами доступа).
@@vladimirblagin3105 Боюсь, Ваше объяснение смогут понять только те, кому оно уже не нужно)) Они и так уже знают, что такое класс и объект. Мне много лет назад объяснили "на пальцах" это еще проще: Есть типы данных - стринг, интежер, флоат и пр. Но можно создать и свой тип данных, в зависимости от потребностей. Это и будет класс. А объект - это переменная этого типа данных. Все. Всякие инкапсуляции и наследования для понимания придут позже.
Сейчас в последнее время даже начали выделять четвёртый принцип ООП такой как Абстракция и видел 1 раз, как выделяли даже пятый принцип Композиция, но если с Абстракцией ещё можно согласиться, то вот Композиция может казаться дополнением необязательным, которое просто рассказывает об одной возможности ООП :)
обычно композицию называют частным случаем агрегации. Агрегация - два объекта связаны между собой, но при уничтожении главного объекта агрегированный объект продолжает существовать. Композиция - это частный случай агрегации, при котором между двумя объектами создается сильная связь. При уничтожении главного объекта уничтожается и вложенный. Как-то так. Но это ведь не относится к принципам ООП, насколько я понимаю, это варианты взаимодействия между классами. Типа наследование, дружба и т.д. А принципы ООП - это собственно наследование, инкапсуляция и полиморфизм. Но вы правы, в последнее время стали выделять 4ый принцип абстрагирование.
Моё мнение: пока вы не начнёте писать хоть какую-то +/- среднюю программу - не поймёте что такое ООП, SOLID, зачем это придумали и как это использовать
Новичкам про ООП надо понять одну простую вещь. ООП - оно не про предметную область (ибо сишная структурка объект реального мира отображает не хуже объекта джавы). Оно про организацию кода. Ибо до него в чисто процедурном подходе данные приходилось хранить либо в глобальном стейте, что давало адок в рантайме (ибо отловить, кто нагадил, было крайне сложно), либо перешвыривать в параметрах процедур, что нехило загаживало код. И самый фундаментальный принцип ООП - инкапсуляция (не то, что джаверы придумали, а изначальное ее понятие), то есть объединение кода и обрабатываемых им данных в одну сущность. Уже одно это дало нехилый буст к возможной сложности программ. Наследование и прочие полиморфизмы уже скорее приятные бонусы.
Для джуна - НИЧЕГО непонятно. Я сделал вывод что если я программирую работу с каким то объектом (цена, погода, перевод слова), то я программист ООП. Тогда вопрос - приведите пример программы НЕ с объектом. Калькулятор на питоне - это работа с объектом (вводимая юзером цифра)
Если не знаешь, зачем нужен класс Object, то ты не знаешь, что такое ООП. А когда ООП не знаешь, то и программ в ООП у тебя нет. А про класс Object не знаешь тогда, когда думаешь, что можно было бы и выкинуть его. Так что даже долгий курс не гарантирует освоение ООП учащимся.
Новичку сложно объяснить (действительно объяснить, а не навалить формулировок) что такое ООП, потому как новичёк не знаком еще с проблемами, которые ООП призван решать. Для того, кто осваивает свои первые хеллоу-программы это все может показаться ненужным усложнением и магией, хорошо это ложится на разум тогда, когда учебные проекты достигают той сложности, при которой начинает напрашиваться объединение структур данных и методов их обработки.
@@Моякавярня Работает на практике это следующим образом. Вообще между чисто процедурным подходом и ООП есть еще промежуточная парадигма с названием "Структурное программирование", о котором сегодня почти все почему-то забыли. Хотя... это уже игра терминами, при желании ее можно отнести к подвиду процедурного подхода. Не суть. Когда в твоем проекте напрашивается объединение разработанных тобой структур данных с функциями, которые обрабатывают эти структуры - можно считать что ты созрел для ООП.
Сергей, я Вас очень уважаю, но про ООП Вы в этом видео как раз рассказали настолько сложно, что я за терминами потерялся. Где-то встречал пояснение ООП на примере подбора кузова автомобиля. Никакой терминологии и все просто и понятно. :)
Я скажу проще и самое главное: ООП это способ облегчить использование уже созданного кода, всё идёт по пути упрощения, сделать сложное простым, вот ООП позволяет это реализовать
"Будь проще, и люди к тебе потянутся". Так говорили, когда я служил в армии. Не знаю, как будут восприняты мои советы, но все же решил вставить свои "пять копеек". По-перше, "проще" - это никаких лишних новых словей типа "парадигма". Набор правил! Ибо так оно и есть на самом деле. Наборы различных правил, начиная от "верблюжьей" или "венгерской записи" и аж до SOLID, всяких "паттернов" (не очень хорошо отношусь к применению иностранных слов взамен привычных, хотя и чаще всего иностранного происхождения, поэтому предпочту "шаблоны" вместо "паттерны"). Чем больше неоправданно лишних иностранных слов русскими буквами, тем хуже восприятие у читателей-зрителей-слушателей. Поэтому. ООП - это набор правил. Довольно большой, разросшийся за десятки лет набор правил. Набор этот предназначен исключительно для "облегчения жизни" программистам за счет повышения надежности кода за счет уменьшения числа ошибок, упрощения их поиска и т.д. И что очень важно - когда есть набор формальных правил, можно многие действия автоматизировать, что и делается во многих программах для разработки приложений (они же IDE, ИСР, ЕСР...). Недавно от кого-то услышал, что в Visual Studio (не Code) все труднее и труднее делать ошибки. Правила в ООП... Например, это разделение всего кода на классы - модули. Каждый модуль - это модель (шаблон, набор свойств, методов и т.д.), по которой создаются объекты. Тысячи, десятки, сотни тысяч строк кода (или даже миллионы) разбиваются на отдельные модули - классы. В итоге вырастает (как правило) общий объем текста, но значительно уменьшается путаница, облегчается тестирование, упрощается разделение труда... И в конце концов, этот подход соответствует природе человека. Это как про деньги: "Если бы никто не придумал ООП, его все равно бы кто-то придумал." P.S. Однажды аятолла Хомейни специально работал над уменьшением своего словарного запаса в разговоре с обычными людьми. Речь шла о сокращении с 5 тысяч до одной тысячи слов.
Ну да, ну да. А еще программы писать надо на русском (или украинском?), как в 1C :-). И постулаты ООП: обособленность, наследование и ... и ... и ... изменчивость поведения через множественность применения? 🙂
Здравствуйте. В текущих реалиях программистов, а их увольняют тысячами и десятками тысяч по всему миру, интересно послушать о будущем. Это угроза от chatGpt или очередной кризи дот комов?
это результат ковида, когда компании такие "эгегейй!! Можно нанимать больше людей удаленно, экономя на офисе, потому что в офис и так мало кто ходит", но сейчас просто хайп упал и они поняли, что сильно поспешили с наймом
ХЗ, мне было 15 лет в 1997 году, мне старшеки дали книжку С++ для чайников. Я прекрасно понял, что такое ООП. А что тут автор канала про ООП наговорил, вообще воды какой то наплел, про чек какой то. Представляю как он описывает на своих курсах инкапсуляцию и полиморфизм. Матрешки наверное в пример будет приводить.
ООП ложь. Которая сама себе противоречит. Если изучить базовые аргументы против ООП, то станет ясно что ООП само себя ломает, и работает лишь в легких абстрактных ситуациях, но никак не в реальных проектах, уж тем более больших, хотя именно там оно и заявляет что теоретически должно помогать. Но не тут-то было.
📰 Выпуск айти новостей от 24.07 - ua-cam.com/video/vG1E10W8gQQ/v-deo.htmlsi=29-O_Pl7p7-HQ0sR
🔥🔥🔥🔥🔥🔥 Супер полезно! Лучшее объяснение из всех, что я слышал! Спасибо огромное!! ❤🔥❤🔥❤🔥❤🔥❤🔥❤🔥❤🔥
К программированию не имею никакого отношения, но😊проснулся, сделал кофе ☕️ и залипаю на Немчинского.
Ну як мінімум тебе цікавить програмування
Ні, я просто такий же старий пердун який намагається отримувати задоволення від життя незважаючи на війну;)
@@OleksandrKarlos так вам же ничего не понятно в этом видосе)
@@dzmitrystudy9514 кто знает дорогой Ватсон, кто знает.
@@OleksandrKarlos Сергей вам от души скажет спасибо за "старого пердуна"😅
Здравствуйте, мои дорогие. И сегодня я с вами хочу поговорить про обучение вождению.
Вождение автомобиля - это управление автомобилем. Управление автомобилем это управлением движением.
Управление может быть ручкой (это первые автомобили), рулем, штурвалом, джойстиком.
Джойстиком можно управлять самолетом Боинг, мы как раз запустили такой курс, приходите к нам учиться.
Управление ручкой удобно на первых автомобилях, но если вы хотите ехать быстро, то выбирать нужно управление рулем.
В современных автомобилях для управления есть руль (его нужно крутить) и педальки (их нужно нажимать).
Если вы сейчас тот самый человек, который выбирает какие-то курсы, автошколу, то я фактически вам рассказал все, что надо знать.
Да конечно, вам расскажут про какие-то ПДД, дорожные знаки, безопасность маневров.
Я вижу, что там обучение занимает, ну какие-то даже месяцы, я не могу этого понять, с моей точки зрения вождению нужно учиться в реальной ситуации, прямо выезжаете в центр большого города и сразу учитесь.
И по большому счету - про педальки и руль я вам рассказал, это все основы и вам нужно быстрее сесть за руль и ехать.
В общем не понимаю я эти автошколы, зачем они это делают, возможно выгодно вам продать права на вождение.
Люблю вас, подписывайтесь, ставьте лайки и ... пока!
Браво.
Зачет. Прям в точку.
На самом деле так происходило в моей автошколе. На первом занятии мы поехали в город)
Класс
Так по факту! Сел и едешь! Но с инструктором, который будет подсказывать, что делать, и рассказывать о нюансах
После слова парадигма хотел уже гуглить,но тут же последовало объяснение,лайк без раздумий 😊
Как пятой ноге колесо :) 👍
09:19 "Пятой ноге колесо." - це вже якась нова парадигма. )))
Спасибо за информацию!
Даже вот заинтересовало теперь чем отличается процедурное программирование от функционального. Как-то думал, что это одно и тоже.
наконец-то я дождался
Полезная информация
Спасибо, Сергей!
Спасибо за видео. Все четко и понятно
Спасибо за видео, очень доступно и понятно изложено для новичка. Оф топ вопрос: php жив ещё? Хочу начать с него переход в it...
приятный человек, спасибо
УРА-А-А!!! Теперь я программист :)
Сижу втыкаю в ооп, совсем другое мышление появляется, уже никак без этого)
Абсолютно согласен.
Помню когда после Си начал изучать С++ все было легко и понятно, и я очень быстро начал писать на С++ ПРОЦЕДУРНЫЙ код. Овладел ООП только спустя пару лет - когда стал "видеть улицу с другой точки зрения". За те два года я очень много писал программ, и когда поведение программы сильно усложнялось - приходило понимание как применять объекты.
Меня вынужденный переход с С++ на Java сильно в понимании ООП подтолкнул, там в принципе не может быть кода вне классов. Пришлось сначала выдумывать что в какой класс запихать, чтобы эта сволочь хоть как-то заработала, а потом уже и мозг перестроился. Но на старый свой код теперь без слез не взглянешь)
Только утром пересматривал старые видео про принципы ООП )))
Интересно, спасибо!
ООП это просто, это всего-лишь 1 термин, 4 принципа, 23 gof patterns, solid и прочие best practices. Добро пожаловать в java/c#, ребята.
Доброе утро, подскажите, пожалуйста, когда будет доступно изучение и прохождение курса по Java . Живу в России. Спасибо!
Присоединяюсь к вопросу
а сами не можете догадаться?
Никто не ответит на этот вопрос. Когда война закончится, Украина освободит все свои территории и Россия будет платить репарации. И то не факт, что после этого Немчинский разрешит курсы.
@@torrvic1156 У меня за окном никакой войны нет, незнаю что вы тут все обсуждаете
never
Как пятой ноге колесо - запомнил, буду использовать. :)
В программировании парадигма -- скорее подход, чем взгляд.
Процедура (подпрограмма) работает со своими данными и может вызываться неоднократно, что экономит труд. Но данные портятся при параллельном вызове одной и той же процедуры. Поэтому придумали классы -- упрятывание процедур и их данных в описание. Каждый раз при вызове класса из любого места программы из описания в памяти порождается содержимое класса (объект), и с ним работают. Это также экономит код, но при параллельных порождениях объектов их данные не портятся.
ООП -- это просто!
То есть вы свели всю ООП к инкапсуляции? И решили, что ООП - это просто? Инкапсуляция - это подход, но ООП не сводится к инкапсуляции и может существовать без инкапсуляции. А защиту данных от внешнего вмешательства мы можем сделать через замыкания или еще каким-либо образом, не обращаясь к ооп.
Сергей расскажите про Алгоритмы и структура данных, где применяются
Эммм, странный вопрос...
Везде?..
@@Konev-VA понятно что везде, где применяются, при каких задачах имеется ввиду.
@@spelsinx при всех
@@roman_je_rkoff не при всех, будьте умнее, не пишите бред
@@spelsinx Коллекции - это структуры данных. Я практически не знаю задач, где бы они не использовались.
9:02 чем они особенные в этом плане? Они всего лишь передают видео потоком, где там много разных потоков данных?
В этом примере, думаю, было бы более кстати примеры каких-то realtime приложений, где действительно все выстроено как dataflow, например через Rx
Имхо, ООП , конечно, классно, но ей не хватает правил для определения объектов. Хотя такие правила есть в теории баз данных - обеспечение оптимального хранения всей необходимой информации, нормализация и т.п. Например, есть склад, где можно выделить объект "товар", а можно выделить "транзакцию"(любое перемещение товара). Второй вариант больше подходит для учёта, особенно когда товары делимы (например, можно отсыпать часть товара).
Возможно, та же фигня и с потоковым видео.
Там в Ютубе, есть данный который я посмотрел это видео спустя 9 месяцев после выхода на ютюб? Если нет то что бы выводить такую информацию нужно опять запрагроммироват кто? Оба? Или фульстак сам сможет? Ответе пожалуйста языком как программиста
Не верьте этому дяде, что за бабло и 2 недели он научит Вас ООП. Просто начинайте кодить на плюсах или решетке. И через несколько лет и несколько десятков проектов, таки дошедших до продакшена, Вы с удивлением для себя обнаружите, что Ваша башка уже мыслит объектно - ориентировано, а не процедурно, как было ранее.
Так а никто не сказал, что ты начнёшь писать код, и все понимать после вступительного курса…
Так мы ж мову не знаем. О чём тут вообще говорить?
спасибо за обьяснение - Парадигмы на простом людском языке.
Обожаю вас!
Ого! За час почти 3 тыс просмотров! Круто)
От души СПАСИБО!
Мы тебя тоже любим, спасибо
Спасибо!
Реально понятно, огонь)
Я так и не понял, чем процедура отличается от объекта, кроме названия. Интересно было бы сделать одну и туже задачу двумя этими способами и показать разницу. Методы объектов это те же параметры процедуры. Но гораздо сложнее в написании.
📵10 ошибок в поисках работы программистом, которые тормозят вас в получении оффера - ua-cam.com/video/OchgKVPR7fc/v-deo.htmlsi=iz4jfb-WgLrTsrny
Нихрена себе! Я понял с этого видео, что такое ооп!
Как он сказал про потоковую обработку, что её сложно подогнать под ооп, потому что само описание предметной области не содержит толком объектов, так я понял, что в коде надо объекты(экземпляры классов, которые составляют объекта предметной области) искать и смотреть что они делают, оставляя остальной код на потом. И теперь стало яснее, что именно происходит и как и почему.
"5 ноге колесо" - забавно)
Люблю цей канал!!! Вподобайка і кометар залітають на ура!😄😄😄😄
клас. дякую!
Процедурное программирование более универсально. ООП не везде разумно использовать. А бардак при разработке это не проблема используемой парадигмы. Это пренебрежительное отношение к документации и планированию, распределению зон ответственности, разработке единого стиля при написании кода, и.т.д.
в общем все так, только парадигмы как раз и заточены к "распределению зон ответственности", просто не все их принципы везде соблюдают
как отлечить рекламу от не рекламы качеством записи звука
Спасибо
Вы представили все ООП только в разрезе инкапсуляции. Лишь вскольз упомянув о всех трех принципах: инкапсуляция, полиморфизм и наследование. Это как бы и есть те три слона, на которых базируется мир ООП на заставке к ролику. Так про всех слонов и надо бы, наверное. Может поэтому другие курсы обширнее? Вы выбрали одного слона (инкапсуляцию), назначив его главным. Ну это в общем-то известная общая проблема. Большинство программистов именно так и понимают ООП, как инкапсуляцию. И для них понятие полиморфизма чуждо, наследование еще куда ни шло. Такие разработчики не понимают, что такое интерфейсы и зачем они нужны. Они их используют чисто в разрезе практик и паттернов. Абсолютно не понимая смысла.
Разработчики, освоившие изначально процедурный стиль, понимая только инкапсуляцию, начинают писать программы в ООП в том же процедурном стиле. Осознавая классы как микробиблиотеки процедур с упакованными микробиблиотечными свойствами, удобные в использовании. И не более. Кстати, вы упустили важный шаг в истории про переход от процедурного стиля к ООП, это процедурные библиотеки (модули, в некоторых языках), которые уже умели инкапсулировать свойства и методы. Но толчком к переходу к ООП стали именно наследование и полиморфизм.
PS. Ну и стоит наверное с самого начала четко разделять классы и объекты (как экземпляры классов). Первое, с чем сталкивается новичок - это непонимание чем отличается класс от объекта. А вы тут в ролике классы объектами называете.
PS2. Первая ключевая проблема процедурного подхода, это конечно же не проблема упорядочивания процедур, а потеря управляемости в связи с том, что процедуры начинают связываться логикой, которая никак не оформлена специально (не инкапсулирована), эта логика держится только в голове программиста, освоившего нужные библиотеки и понявшего взаимосвязь процедур. Вторая ключевая проблема процедурного подхода - полное отсутствие полиморфизма. Долгое время не было осознания необходимости полиморфизма. Наследование худо бедно можно реализовать в процедурах, инкапсуляцию тоже, но только не полиморфизм. Это ничем не эмулировать. Это внутри механизма ООП. И вот когда пришло осознание, что никакими ухищрениями полиморфизм не реализовать в процедурах, вот тогда ООП пришел в отрасль окончательно.
Если бы ООП было только про принцип разбиения процедур и описания типов на блоки, то никто не называл бы это парадигмой, скорее подходом. Причем такой подход и так легко применяется в процедурных языках - один файлик разбиваем на множество, а для удобства поиска создаем иерархию модулей по предметной области.
Так что это видео даже отдаленно не про ООП.
Это видео про то, как у них классно учат, а у других хуже. Немчинский рекламщик с претензий на серьезные вещи. Не обосрать других - это нужно иметь культурный багаж в несколько поколений... Джентльмен - это чел у которого три поколения имеют диплом Оксфорда!
Khalil Stemmler попробовал объединить всё в своей книге, но многие в том числе я не знают как использовать паттерны и мощь ооп(
Вас послушать, так весь линукс это один большой файл. Ведь там чистый Си. И он не умеет в ООП. Или всё-таки умеет?
Добрый день, подскажите пожалуйста, поступил на курсы по Data Since , они будут идти около года, можно ли мне изучать параллельно английский язык или он будет мешать обучению на курсах?
Отсутствие знания английского будет мешать обучению на IT-курсах существенно сильнее.
Практически любой популярный язык программирования и почти вся IT-терминология основана на английском языке. Так что какие-то конструкции изучаемого вами языка программирования будут для вас либо непонятными наборами букв, которые придется зубрить как заклинания, либо почти связными, хоть и примитивными, предложениями на английском языке, которые при знании английского несложно читать и строить самостоятельно.
Ваще пофиг.
Даже если будешь английский знать, будешь видеть тарабарщину. Я свою первую прогу написал переводя через яндекспереводчик названия переменных. Английский вообще никак не помогает, основа это реальные примеры кода которые находил в инете, например на стаке.
Уже конечно поздно, но если есть возможность переходи на разработчика. В дата саентис ломанулась куча народа, а больше работы не стало. При этом профа хоть и востребована, но и специфичной т.к. каким-нибудь рогам и копытам нафиг не сдался дата саентис. А вот сайт им нужен и разраб всегда работу найдёт. Без опыта ты будешь год работу искать и то не факт что найдёшь, это самый большой минус дата саентиса. Потом уже сможешь на дата саентиса выучиться и уйти.
Все грамотно, но я с РФ не могу зайти по Вашим ссылкам.
Когда Сергей стал похож на Ричарда Салмана, Так и хочется от него услышать про linux, openssource, и C++
Я так и не понял в чём заключается отличие объектов от процедур
Сергей, в процедурном нам никто не мешает разбить процедуры логически по модулям, например StrUtils. Но проблема с поиском кода все еще останется. Пользовательские типы - классы создают явные связи, одни вызывают другие и потянув за один, мы вытягиваем себе всю необходимую для работы цепочку. Настройки подключения -> сессия -> исполнение sql.
В процедурном тоже конечно видно связи модулей по импортам, но все это крайне быстро превращается в ад.
В питоне с этим сложнее, но в статической типизации наш код даже не запустится пока мы не внедрим все нужные зависимости.
спасибо вам!
За все время никто так и не заметил бага с очками где лицо Сергея уменьшается, почему до сих пор не поняли как пофиксить данный баг?
Я, как человек который много много раз за много много лет гуглящему "что такое ООП?" могу с уверенностью заявить: Нифига вы не объяснили. Да, сейчас то я уже знаю что это такое но этот видос такой-же нифига реально не объясняющий как и куева туча остальной информации в сети. И, ДА, понял я это только по практике, когда в один прекрасный момент было: "Ааааааа, воооооот, я понял"!
Так надо было не много-много раз за много-много лет гуглить, а сесть и попрактиковаться
@@Konev-VA если ты лет пять сеттеры/геттеры попишешь - вряд ли тебе это поможет ООП понять
@@Konev-VA Ну так, а почему бы не объяснить это раньше? Суть то видео в чём??? Яркий пример это видео где объясняется число Пи, конечно же я знал что Пи это 3,14 - это же все знают, вот там, как говориться, на пальцах объяснено, и вот только поле того видео я понял "что это" и "зачем это". Вот и тут так, я знаю что ООП это парадигма, а вот суть "что это" и "зачем это", для тех кто совсем не в курсе, здесь не доведено...
Если ты не понял, это не значит что не объяснили :)
@@dimkinn1 Это типа как ты не понял что я объяснил??? Попробую еще раз: Я, как человек давно уже знающий что это такое и объясняю что это видео этого не объясняет совсем, как и тонны подобных статеек и видосиков... И нех тут выделываться, показывать на машину и говорить что это "машина" не объясняет никуёшеньки!!! P. S. И говорить что она "ездит" тоже не объясняет никуя...
Невероятно харизматичный мужчина
Сергей, перелогиньтесь
@@alazarn7 🤣
8:55 почему? В потоке данных можно передавать объекты
думаю имелось в виду накладные расходы слишком большие при использовании ооп в таких случаях.
@@r.chitector какие? 0.01 мс против 0.003 мс?
@@ni55an а потом GC придет все эти объекты собирать... а вообще скорее всего имеется ввиду, что такую систему куда проще задизайнить в функциональной парадигме, нежели в объектной. Просто нет смысла забивать гвоздь экскаватором
@@ksviety чтобы никто не приходил, можно вообще на C писать и самому чистить память, но какой в этом смысл, если память и процессоры стоит дешевле, чем работа прогера?
Не сказал бы, что в функциональной проще задизайнить. В ней нужно строго следить за иммутабельностью, сайд эффектами и т.д., а ООП в этом не ограничивает.
Экскаватор это инструмент, а парадигма это не инструмент, это концепция
Смысл ООП в том, что эта парадигма позволяет создавать данные в рантайме. Т.е. управлять динамически изменяемым дампом памяти в процессе работы программы. Все остальное - это шелуха. Хотя, понимаю, что это трудно объяснить на раз людям , которые , особенно, никогда не имели дело с языками программирования, в которых дамп данных статичен... )))) Являюсь Вами подписчиком. У Вас большой талант общаться с людьми ...)))))))
ОБЬ - Корень слова "обьяснение", поймёшь что означает корень поймешь это слово и осознаешь что это видео не о том о чём ты предполагал :) Лайк за тупейшую очепятку!!!
Мати Василева 😀 не відразу впізнав =))) крута борода))
Новички теперь задаются вопросом: "В чем всё-таки разница между процедурой и объектом?" Звучит как: в чем разница между умением говорить и человеком? - то есть вещи очевидно несравнимые. Объект лучше понимается через противопоставление его структуре данных, эти две концепции - абсолютные антиподы. Процедура в процедурной парадигме будет совершать операции над структурой данных, но в ООП та же самая процедура как неотъемлемая часть объекта будет совершать манипуляции над данными/состояниями своего объекта. В процедурной парадигме - процедуры являются центром мироздания, а в ООП мы имеем дело с объектоцентризмом. Инкапсуляция, полиморфизм, абcтракция и наследование - это техники, повышающие качество объекто-ориентированного кода, но не являются необходимым условием для ООП.
Не расслышал. Как его зовут?
Объект - это набор переменных (свойства) и функций (методы), которые характеризуют структуру данных из предметной области.
Класс - это заготовка для объекта. Соответственно, объект - экземпляр класса.
Например операторными скобками { } инкапсулируют, т.е. скрывают логику в этой части программы от всей прочей.
Вот точно также парадигмой ООП проектируют каждую программу, которая сложна, как внешний мир и его предметные области.
Для меня описание выше когда дошло лучше прочих философских рассуждений.
Класс - это не заготовка. Это класс. Так и надо изначально говорить, чтобы потом не говорить о классе, как о шаблоне или заготовке.
Класс - это описание набора свойств (определяют состояние) и методов (определяют поведение), которые характеризуют декомпозированный элемент предметной области.
Объект - экземпляр класса, отражающий состояние и поведение конкретного элемента предметной области в соответствии со спецификацией класса.
И инкапсуляция - это не скрытие логики. Класс - это не черный ящик. Инкапсуляция - это группировка состояния и поведения в одном месте (в классе), которое человек способен контролировать, и управляемость которого гарантирована "контрактами" ООП конкретного языка (например, модификаторами доступа).
@@vladimirblagin3105 Боюсь, Ваше объяснение смогут понять только те, кому оно уже не нужно))
Они и так уже знают, что такое класс и объект.
Мне много лет назад объяснили "на пальцах" это еще проще:
Есть типы данных - стринг, интежер, флоат и пр.
Но можно создать и свой тип данных, в зависимости от потребностей.
Это и будет класс. А объект - это переменная этого типа данных. Все.
Всякие инкапсуляции и наследования для понимания придут позже.
В Си очень даже можно в ООП. Линус Торвальдс неплохо обходится - не скажу, что ядро Линукс и Гит маленькие программы.
как 5 ноге колесо, такого я еще не слышал))
Легко и приятно слушать. Спасибо!
Я новичек в ООП, но в моем представлении это проще понять с точки зрения менеджмента чего-либо. Не ?
5:13 перефразируя "День выборов"
-- Описание этой процедуры, точно такой же, но другой, наш доблестный разработчик уже реализовал
Мало быстро рассказать, надо чтобы еще и быстро поняли :)))
Было бы интересно увидеть ролик, такой же понятный, по всем основным парадигмам
ua-cam.com/video/EvGi6XDgV7w/v-deo.html
ua-cam.com/video/eI0XzQw3V0Q/v-deo.html
ua-cam.com/video/Ay_GwOQWPs8/v-deo.html
Пока только по принципам ООП)
Борода офігенська 😅
Не понимаю, чем функциональное программирование отличается от процедурного. Почему-то мне казалось, что из функционального возникло ООП...
Спасибо . Макрофункциональное погоизм это про энтузиазм .
Сейчас в последнее время даже начали выделять четвёртый принцип ООП такой как Абстракция и видел 1 раз, как выделяли даже пятый принцип Композиция, но если с Абстракцией ещё можно согласиться, то вот Композиция может казаться дополнением необязательным, которое просто рассказывает об одной возможности ООП :)
Видел у некоторых аж 6: "обмен сообщениями" ))
У кошки четыре ноги. Но есть еще хвост, уши и много чего еще. От того, что хвост кому-то хочется считать пятой ногой, он таковой не станет.
обычно композицию называют частным случаем агрегации. Агрегация - два объекта связаны между собой, но при уничтожении главного объекта агрегированный объект продолжает существовать. Композиция - это частный случай агрегации, при котором между двумя объектами создается сильная связь. При уничтожении главного объекта уничтожается и вложенный. Как-то так. Но это ведь не относится к принципам ООП, насколько я понимаю, это варианты взаимодействия между классами. Типа наследование, дружба и т.д. А принципы ООП - это собственно наследование, инкапсуляция и полиморфизм. Но вы правы, в последнее время стали выделять 4ый принцип абстрагирование.
Странный переход от свалки процедур к ООП. А модули? Разбить по темам, вложенности?
Моё мнение: пока вы не начнёте писать хоть какую-то +/- среднюю программу - не поймёте что такое ООП, SOLID, зачем это придумали и как это использовать
Модули пропустил между процедурным и объектным
Новичкам про ООП надо понять одну простую вещь. ООП - оно не про предметную область (ибо сишная структурка объект реального мира отображает не хуже объекта джавы). Оно про организацию кода. Ибо до него в чисто процедурном подходе данные приходилось хранить либо в глобальном стейте, что давало адок в рантайме (ибо отловить, кто нагадил, было крайне сложно), либо перешвыривать в параметрах процедур, что нехило загаживало код.
И самый фундаментальный принцип ООП - инкапсуляция (не то, что джаверы придумали, а изначальное ее понятие), то есть объединение кода и обрабатываемых им данных в одну сущность. Уже одно это дало нехилый буст к возможной сложности программ. Наследование и прочие полиморфизмы уже скорее приятные бонусы.
та же история и с JS. На нем можно писать в ООП даже не используя ключевые слова class, super, extends и т.д.
совершенно верно. сокрытие данных - самый большой плюс. это просто прорыв. но другие "приятные бонусы" не просто приятны, но и очень необходимы.
Для джуна - НИЧЕГО непонятно.
Я сделал вывод что если я программирую работу с каким то объектом (цена, погода, перевод слова), то я программист ООП.
Тогда вопрос - приведите пример программы НЕ с объектом. Калькулятор на питоне - это работа с объектом (вводимая юзером цифра)
Ну так сорян. Без якогось прикладу як зрозуміти що це. Я ніхрена не зрозумів. І що що є ціна яку можна порахувати у чеку
надеюсь я не один кто смотрит канал сергея и ждет когда наконец его будут звать по-новому, не сергей немчинский.
ну вот не дождетесь :)
Короче процэдуры надо делить на блоки. Я не понял причём тут объекты
Если не знаешь, зачем нужен класс Object, то ты не знаешь, что такое ООП. А когда ООП не знаешь, то и программ в ООП у тебя нет. А про класс Object не знаешь тогда, когда думаешь, что можно было бы и выкинуть его. Так что даже долгий курс не гарантирует освоение ООП учащимся.
Новичку сложно объяснить (действительно объяснить, а не навалить формулировок) что такое ООП, потому как новичёк не знаком еще с проблемами, которые ООП призван решать. Для того, кто осваивает свои первые хеллоу-программы это все может показаться ненужным усложнением и магией, хорошо это ложится на разум тогда, когда учебные проекты достигают той сложности, при которой начинает напрашиваться объединение структур данных и методов их обработки.
я думаю, те кто пишет первые хелоу-проекты - нужно все же начать с процедурки, а потом те же проекты написать в ооп, и тогла разница будет понятна.
@@Моякавярня Работает на практике это следующим образом. Вообще между чисто процедурным подходом и ООП есть еще промежуточная парадигма с названием "Структурное программирование", о котором сегодня почти все почему-то забыли. Хотя... это уже игра терминами, при желании ее можно отнести к подвиду процедурного подхода. Не суть. Когда в твоем проекте напрашивается объединение разработанных тобой структур данных с функциями, которые обрабатывают эти структуры - можно считать что ты созрел для ООП.
Бро, объяснение слово, через твёрдый знак пишется.
исправим, спасибо
у вас ошибка в слове обЪяснять и в заголовке на картинке видео
Он не обязан знать орочий у него мойва это его язык
@@Romanbanan12 при чем здесь мойва, или у тебя Й на клавиатуре западает? или ты пробитый пропогандой руснявой?
@@cozyfireplace_ или на говяжей мойве ещё как вариант
@@Romanbanan12 как ты со своими интеллектуальными возможностями вообще попал на это видео, ущерб
Сергей, я Вас очень уважаю, но про ООП Вы в этом видео как раз рассказали настолько сложно, что я за терминами потерялся. Где-то встречал пояснение ООП на примере подбора кузова автомобиля. Никакой терминологии и все просто и понятно. :)
@Sergey Nemchinskiy можно, пожалуйста, так же понятно про паттерны🙃
можно :) pro.foxminded.ua/grasp-gof-design-patterns-advanced-on-line-course-1/
Я скажу проще и самое главное: ООП это способ облегчить использование уже созданного кода, всё идёт по пути упрощения, сделать сложное простым, вот ООП позволяет это реализовать
сложное нельзя сделать простым, можно только скрыть эту сложность за какой-то конструкцией, которая имеет свой overhead
@@ni55an спасибо, всё сложное можно разделить на простые решения: делай одну вещь, но делай её хорошо
@@АлександрПетров-г8о1н если говорить про общую сложность, то при разделении на простые решения она станет только больше
@@ni55an Большие задачи иначе как разбиением на более мелкие - не решить.
@@0imax я нигде это и не отрицал. Просто нужно понимать, что подобные разбиения имеют свой overhead
Просто есть языки, где в ООП натолкано куча всего, а потом ещё и книжонок написано по 1000 страниц с портянками кода...
"Будь проще, и люди к тебе потянутся". Так говорили, когда я служил в армии. Не знаю, как будут восприняты мои советы, но все же решил вставить свои "пять копеек".
По-перше, "проще" - это никаких лишних новых словей типа "парадигма". Набор правил! Ибо так оно и есть на самом деле. Наборы различных правил, начиная от "верблюжьей" или "венгерской записи" и аж до SOLID, всяких "паттернов" (не очень хорошо отношусь к применению иностранных слов взамен привычных, хотя и чаще всего иностранного происхождения, поэтому предпочту "шаблоны" вместо "паттерны"). Чем больше неоправданно лишних иностранных слов русскими буквами, тем хуже восприятие у читателей-зрителей-слушателей.
Поэтому. ООП - это набор правил. Довольно большой, разросшийся за десятки лет набор правил. Набор этот предназначен исключительно для "облегчения жизни" программистам за счет повышения надежности кода за счет уменьшения числа ошибок, упрощения их поиска и т.д. И что очень важно - когда есть набор формальных правил, можно многие действия автоматизировать, что и делается во многих программах для разработки приложений (они же IDE, ИСР, ЕСР...). Недавно от кого-то услышал, что в Visual Studio (не Code) все труднее и труднее делать ошибки.
Правила в ООП... Например, это разделение всего кода на классы - модули. Каждый модуль - это модель (шаблон, набор свойств, методов и т.д.), по которой создаются объекты. Тысячи, десятки, сотни тысяч строк кода (или даже миллионы) разбиваются на отдельные модули - классы. В итоге вырастает (как правило) общий объем текста, но значительно уменьшается путаница, облегчается тестирование, упрощается разделение труда... И в конце концов, этот подход соответствует природе человека.
Это как про деньги: "Если бы никто не придумал ООП, его все равно бы кто-то придумал."
P.S. Однажды аятолла Хомейни специально работал над уменьшением своего словарного запаса в разговоре с обычными людьми. Речь шла о сокращении с 5 тысяч до одной тысячи слов.
Ну да, ну да. А еще программы писать надо на русском (или украинском?), как в 1C :-). И постулаты ООП: обособленность, наследование и ... и ... и ... изменчивость поведения через множественность применения? 🙂
@@vladimirblagin3105 А что, нормально код пишется на русском языке в 1с. Это по началу больно, а потом привыкаешь )))
Здравствуйте. В текущих реалиях программистов, а их увольняют тысячами и десятками тысяч по всему миру, интересно послушать о будущем. Это угроза от chatGpt или очередной кризи дот комов?
это результат ковида, когда компании такие "эгегейй!! Можно нанимать больше людей удаленно, экономя на офисе, потому что в офис и так мало кто ходит", но сейчас просто хайп упал и они поняли, что сильно поспешили с наймом
ChatGPT - это лишь помощь, на уровне подсказок IDE (просто более продвинутых), это никогда не сможет само решать бизнес задачи
@@maxkiner4059 Даже если когда-то ИИ достигнет уровня мидла, всё-равно кому-то надо будет сформулировать для него задачу))
@@0imax именно) пользуюсь GitHub Copilot, очень помогает, иногда кажется, как будто читает мысли) но это всего лишь инструмент, а я его оператор
Разговорный язык очень красивый
наверное наисложнейшее объяснение из слышанных
Напишу просто ООП це спосіб полегшення написання коду для великих проектів
ХЗ, мне было 15 лет в 1997 году, мне старшеки дали книжку С++ для чайников. Я прекрасно понял, что такое ООП. А что тут автор канала про ООП наговорил, вообще воды какой то наплел, про чек какой то. Представляю как он описывает на своих курсах инкапсуляцию и полиморфизм. Матрешки наверное в пример будет приводить.
ООП ложь.
Которая сама себе противоречит.
Если изучить базовые аргументы против ООП, то станет ясно что ООП само себя ломает, и работает лишь в легких абстрактных ситуациях, но никак не в реальных проектах, уж тем более больших, хотя именно там оно и заявляет что теоретически должно помогать.
Но не тут-то было.
можно пример таких базовых аргументов?
Тогда почему все крупнейшие реальные проекты написаны на Джаве, в которой ООП обязателен?
@@SMTDN откуда статистика?
@@ni55an У вас есть иные предположения? На чем рабоатет весь финтех, банки, крупнейшие сайты?
@@SMTDN при чем тут мои предположения. Это же ваше утверждение касательно доли проектов на Java
Вот про Hard to master это точно, мне мои классы и то как я их использую вечно вызывает чувство неправильности и убогости.
ОО и функциональная парадигмы ортогональны, и Scala вбирает в себя преимущества обеих!