САМЫЕ ЧАСТЫЕ ЗАБЛУЖДЕНИЯ ООП
Summary
TLDRВ этом видео представлен обзор концепций объектно-ориентированного программирования (ООП), включая распространенные заблуждения и их устранение. Автор упоминает два типа ООП: 'желаемый', основанный на первоначальных идеях Алан Кея и 'текущий', распространённый в языках C++, C# и Java. Обсуждается важность парадигм ООП, таких как инкапсуляция, наследование, полиморфизм и абстракция, а также их различия в статически и динамически типизированных языках. Видео также критикует некоторые интерпретации ООП и подчёркивает их наилучший и наименьший вклад в различные языки программирования.
Takeaways
- 🌐 ОOP (Object-Oriented Programming) доминирует в мире программирования и используется во многих языках, таких как Java, C#, C++ и Python.
- 😅 Некоторые программисты могут не одобрять OOP, но рынок считает его необходимым и важным для программирования.
- 👨🎓 Аллан Кей, изобретатель ООП, вдохновился клетками живых организмов при создании концепции и языка программирования Smalltalk.
- 📈 Java, благодаря маркетинговой политике компаний, превзошла Smalltalk в популярности, хотя последний считался более передовым.
- 🤔 ОOP имеет разные интерпретации и реализации, включая "желательную" (как в Smalltalk) и "текущую" (как в C++, C# и Java).
- 🔐 Принципы ООП, как изначально задуманы Алланом Кеем: объекты, отправка сообщений, наследование, поведение определяется классом, все — это объекты.
- 📦 Энкапсуляция — это объединение данных и функций, управляющих данными, в один компонент, и механизм языка для ограничения доступности некоторых компонентов программы.
- 👪 Наследование позволяет описывать новый класс на основе существующего, но в "желательном" ООП, как в JavaScript, родитель является уже сформированным объектом, а не классом.
- 🔄 Полиморфизм — важная черта ООП, позволяет объектам иметь разные реализации для одинаковых типов и в языках с динамической типизацией ощущается естественнее.
- 📝 Абстракция — выделение важных характеристик объектов для решения конкретной задачи, иногда смешивается с энкапсуляцией из-за вовлечения информации скрытия.
- 📢 Отправка сообщений — процесс вызова метода одного объекта другим, важный в Objective C, где при отсутствии метода не возникает исключение.
Q & A
Что такое объектно-ориентированное программирование (ООП) и почему оно доминирует в мире программирования?
-Объектно-ориентированное программирование (ООП) - это парадигма программирования, основанная на использовании объектов, которые содержат данные в виде полей и код в виде методов. Оно доминирует, потому что многие языки программирования, такие как Java, C# и C++, созданы с целью быть объектно-ориентированными, и ООП предлагает мощные механизмы для решения сложных задач.
Какие различия между 'желательным' и 'текущим' ООП?
-Текущий ООП - это то, что в настоящее время распространено и используется в языках C++, C# и Java. Желательный ООП, с точки зрения его изобрелителя Алан Кея, отражает первоначальные концепции, где всё является объектом, и это реализовано в языках с динамическим типированием, таких как Smalltalk и Objective-C.
Какие языки программирования были упомянуты в скрипте как примеры объектно-ориентированных?
-В скрипте упомянуты языки Java, C#, C++, PHP, JavaScript и Python как примеры языков, которые в той или иной степени поддерживают ООП.
Что такое статическое и динамическое типирование, и как они влияют на ООП?
-Статическое типирование - это когда типы переменных определяются во время компиляции, в то время как динамическое типирование определяется во время выполнения программы. В языках с статическим типированием могут быть ограничения при работе с ООП, и могут потребоваться специальные механизмы для преодоления этих ограничений.
Какие основные принципы ООП были изложены Аланом Кеем?
-Алан Кей определил следующие основные принципы ООП: объект - основная единица системы, отправка сообщений - единственный способ обмена информацией между объектами, каждый объект связан с классом, поведение объекта определяется его классом, классы наследуют функциональность от своих предков, и все является объектом.
Что такое парадигма 'инкапсуляции' в ООП, и как она понимается?
-Инкапсуляция - это парадигма, которая объединяет данные и функции, управляющие этими данными, в одну компоненту. Она также может быть механизмом языка, который ограничивает доступ к некоторым компонентам программы другими.
В чем заключается разница между инкапсуляцией и информационным скрытием?
-Инкапсуляция предоставляет возможность скрыть информацию, но не является самим информационным скрытием. Информационное скрытие - это когда детали реализации объекта скрыты от пользователя, в то время как инкапсуляция - это процесс объединения данных и методов в рамках одного класса.
Что такое наследование в ООП, и как оно используется?
-Наследование - это механизм языка, который позволяет описать новый класс на основе существующего. Это позволяет создавать иерархии классов и обеспечивает полиморфизм, но само по себе оно может быть не только бесполезным, но и опасным из-за сильного связывания между классами.
Какие проблемы могут быть связаны с использованием наследования в ООП?
-Наследование может привести к проблемам с изменением базового класса, так как это может негативно сказаться на всех производных классах. Это может привести к сложностям в поддержке и разработке кода.
Что такое полиморфизм в ООП, и как он реализуется?
-Полиморфизм - это парадигма, которая позволяет различным объектам с одинаковым интерфейсом выполнять разные действия. Он может быть реализован через наследование и переопределение методов, а также через механизмы, такие как generics в C# или методы с разными аргументами в C++.
Какие различные формы полиморфизма упоминаются в скрипте?
-В скрипте упоминаются 'Ad Hoc' полиморфизм (методы с одинаковым именем, но разными аргументами), параметрический полиморфизм (генерики в C#) и субтиповый полиморфизм (наследование и приведение типов).
Что такое абстракция в ООП, и как она влияет на проектирование классов?
-Абстракция - это парадигма, которая подчеркивает важные характеристики объектов, скрывая ненужные детали. Это позволяет сосредоточиться на решении конкретной задачи с минимальным набором характеристик объекта.
Почему парадигма 'отправка сообщений' может быть важнее, чем кажется?
-Отправка сообщений - это процесс, когда один объект вызывает метод у другого объекта. В языках с динамическим типированием, таких как Objective-C, отсутствие определенного метода у объекта не приводит к ошибке, что делает систему более гибкой и устойчивой к ошибкам.
Что такое 'кодовая переиспользованость' и почему она может быть не всегда включена в список парадигм ООП?
-Кодовая переиспользуемость подразумевает, что все предыдущие парадигмы должны быть направлены на уменьшение повторного написания кода. Некоторые авторы считают, что это очевидность и не нуждается в отдельном упоминании как парадигма.
Какие дополнительные концепции, кроме основных парадигм ООП, упоминались в скрипте?
-В скрипте упоминаются концепции из SOLID, которые иногда добавляются к основным парадигмам ООП, хотя их статус как отдельных парадигм для ООП может быть предметом спора.
Outlines
😀 Объектно-ориентированное программирование (ООП) как доминирующий концепция
В первом параграфе автор вводит тему видео - объектно-ориентированное программирование (ООП), которое является доминирующей концепцией в мире программирования. Он подчёркивает, что ООП используется повсюду, и если вы не умеете работать с ООП, то вам не требуются на рынке. Автор также упоминает разнообразие источников, которые отличаются в количестве представленных парадигм ООП, от 3 до 9, и заметает о том, что в видео будут рассмотрены как распространённые заблуждения, так и исходные концепции ООП, созданные Аланом Каем. В заключение автор вводит тему использования ООП как в языках с динамическим, так и статическим типированием.
😔 Различия между 'желательным' и 'текущим' ООП, а также проблемы с наследованием
Второй параграф посвящён различиям между 'желательным' и 'текущим' ООП, где 'текущее' распространено в языках C++, C# и Java, а 'желательное' - в Smalltalk и его концептуальных продолжениях, таких как Objective C. Автор критикует текущую реализацию наследования за его опасность и сильную связь между классами, которая может привести к проблемам при изменении базового класса. Он также упоминает, что в 'желательном' ООП наследование работает по-другому, напоминающе прототипное наследование в JavaScript, где родитель - это уже сформированный объект, а не класс.
😡 Полиморфизм как основной парадигм в существующем ООП и его реализация в различных языках
Третий параграф фокусируется на полиморфизме, который считается основной особенностью существующего ООП и второстепенной в желаемом ООП. Автор объясняет различные формы полиморфизма в языках с статическим типированием, таких как C#, включая методовую перегрузку (Ad Hoc полиморфизм), параметризованный полиморфизм (generics) и подтипный полиморфизм (наследование и приведение типов). Он подчёркивает, что без полиморфизма ООП в статически типизированных языках был бы незначителен. В языках с динамическим типированием, таким как JavaScript, полиморфизм чувствуется естественно, и его можно использовать без особых затруднений.
🤔 Абстракция и отправная точка сообщений в ООП
В четвёртом параграфе автор обсуждает абстракцию как парадигму, часто путающуюся с энкапсуляцией из-за вовлечения скрытых данных. Он выражает усталость от постоянного путаницывания этих двух понятий. Автор утверждает, что абстракция - это выделение важных характеристик объектов для решения конкретной задачи, используя минимально необходимый набор характеристик. Он также вводит концепцию отправной точки сообщений, которая является общей для всех объектов в ООП, но реализуется по-разному в языках, таких как Objective C, где отсутствие метода не вызывает исключений.
😒 Смысл и место кодовой_REUSE в парадигмах ООП
В заключительном параграфе автор обсуждает концепцию кодовой_REUSE в качестве парадигмы ООП, которая, по его мнению, очевидна и не требует отдельного упоминания. Он выражает непонимание того, почему эта концепция включается в обсуждение парадигм, так как все предыдущие парадигмы должны быть направлены на достижение кодовой_REUSE. Автор также упоминает о том, что некоторые источники предлагают расширить число парадигм ООП, включая принципы SOLID, но он считает, что это выходит за рамки классической ООП. В заключение автор призывает зрителей подписаться на канал и нажимать на колокольчик, указывая, что ссылки на материалы для видео будут доступны в описании.
Mindmap
Keywords
💡Объектно-ориентированное программирование (OOP)
💡Алан Кей (Alan Kay)
💡Энкапсуляция
💡Наследование
💡Полиморфизм
💡Абстракция
💡Сообщения (Message sending)
💡Реализация (Implementation)
💡Статическое и динамическое типизирование
💡Прототипное наследование
Highlights
OOP is widely used in programming, with more languages designed to be Object-Oriented than not.
Languages like Java, C#, and C++ are inherently Object-Oriented, while others like JavaScript and Python have different approaches.
Static typing in languages can impose limitations on OOP concepts, requiring specific mechanisms to overcome them.
The 'desired' and 'current' types of OOP differ, with the 'current' being popular in C++, C#, and Java, and the 'desired' in Smalltalk and its successors.
Alan Kay, the inventor of OOP, was inspired by the cellular structure of living organisms to create the Smalltalk language.
Java's marketing success overshadowed Smalltalk, despite the latter's innovative OOP concepts.
David West criticizes Java's OOP as a marketing move, arguing it diverges from the original OOP principles.
OOP principles by Alan Kay emphasize that every object is the basic unit and can send messages, with behavior defined by its class.
In Smalltalk, even basic constructs like loops are considered objects, demonstrating the 'everything is an object' principle.
Encapsulation in OOP is often misunderstood, with two interpretations that are actually complementary, not contradictory.
Inheritance in OOP is problematic due to its potential to create strong bindings and limit code flexibility.
Polymorphism is central to 'current' OOP, allowing for method overriding and upcasting, which is essential in statically typed languages.
Dynamic typing languages like JavaScript can implement 'desired' OOP principles more naturally, including prototype inheritance.
Abstraction in OOP is about highlighting important characteristics of objects, often confused with encapsulation due to information hiding.
Message sending as a paradigm is often overlooked but is fundamental to the 'desired' OOP, especially in languages like Objective C.
Code reuse is considered by some as a paradigm, but it's more of an overarching goal influenced by all other OOP principles.
The video discusses the varying interpretations and applications of OOP paradigms across different programming languages and authors.
Transcripts
OOP happens to be
dominating in the world of programming conceptions
It's easier to enumerate places where it's not used
than vice-versa, and if you can't OOP
then nobody needs you
And yes, i understand that every time i say something like this,
some snowflake Cnile or functiANAL programmer is bursting in tears
But it's not my fault
that the market has decided with it's hairy hand
that Object-Oriented Programming is super necessary.
And in this video, not only i'll teach you about OOP,
but will also highlight the most widespread misconceptions
and will sort them out. I know i'm not the only one
who notices that different sources have different amounts of paradigms, from 3 to even 9, for example.
And most importantly, i'll be guided by the greatest
and provide sources,
so you don't just blindly trust me, but have the proofs instead.
It's just that without proofs,
my mom is turned over in the comments.
Now let's start.
First of all, here's a tiny warning:
Entire programming languages are made with the intention of being Object-Oriented
for example Java, C#
C++ in general was made to expand upon good ol' C
with the delicious moist OOP.
And i'd like to remind you of PHP,
Javascript and Plebthon.. Ooops, sorry
wrong word,
the script was too vague, I meant to say
"python"
Why not very enthusiastic?
Because of the typing.
In language with static typing,
there are some limitations, which need to be considered
and there even are certain mechanics that help fight these limitaitons.
This is why trying to understand OOP using JavaScript
is like licking ants' butts -
It's kind of sour and kind of perfect, but at the same time the green round candy gives you the better feels.
It doesn't mean that pythons and JSes are bad languages,
It just means that things are a lil' bit different there.
Nevertheless, in this video we'll be considering
both languages with dynamic typing
and languages with static typing.
Now, to begin i have good news for ya.
OOP is not one, there's actually a fuck ton.
Everyone realizes it the way they want.
But i want to highlight 2 types of OOP:
The "desired" and the "current".
The "current" is the most popular thing right now,
and it's the thing that's smeared all across C++, C# and Java,
and the "desired" is the thing wanted by the creator of the initial OOP concepts.
and it's smeared all across smalltalk and it's conceptual successors like objective c. (Tried to smear it, but didn't complete it)
By the way, the inventor of OOP is
Alan Kay.
This dude other than programming also has PhDs in biology and philosophy.
Additionally, he professionally played the guitar,
I wouldn't even wonder if he had a knee-long cock.
To put it simple, Alan Kay is the chaddest chad.
It's said that when he was inventing OOP,
he was inspired by the cells of the living organism
Like, the system seems cool, werks, reconstructs relatively fine,
why not yoink it from big mama nature?
And, inspired by this idea, he created the Smalltalk programming language
which, at that time, was considered the ultimate red pill
that was way ahead of its time.
But, it just so happened that Java appeared
and f*cking obliterated Smalltalk.
Because of the marketing policy of the companies that developed these languages,
Java skyrocketed like Bitcoin at the fall of 2017
While void was sent to the trash bin.
Not bad, market, not bad.
First Smalltalk, then Star Wars, then the Vanilla Coke,
what's the next nice thing you're gonna take away, the women from my porn?
Actually, everything would've been fine
if not for one nuance:
There's this man, David West
No, not this one,
this one.
This man is most known for his bookies about OOP,
and a little less known for spinning functional and java programmers' moms
on his c*ck.
All that because, in his opinion, OOP in java is
OOP of the smoker and it's all just a marketing move.
In real OOP, everything needs to happen differently
And to be clear what's wrong,
We'll need to remember basic OOP principles
In the form that was originally planned by Alan Kay
An Object is the basic unit
of an Object-oriented system.
Message sending - the only way of exchanging information between objects.
Every Object is related to some class.
The Object's behaviour is defined by it's class.
Classes inherit their functionality from their ancestor.
Everything is an Object.
Literally everything.
And Rubyists are now probably waving their heads like
"yes everything's an Object, everything's an Object in Ruby too,
even numbers and strings, we're so cool"
Except this is not enough,
in Smalltalk, for example, even basic constructs
and loops are Objects.
Now this i get - everything is an Object.
And, resulting from these principles, there appeared 6 paradigms,
3 of which are often politely forgotten.
First paradigm - encapsulation.
It's one of the most misunderstood
and poorly interpreted paradigms of OOP.
It's all because it has 2 basic interpretations,
which differ from source to source
First interpretation:
Encapsulation - the unification of data and functions
which control this data into a single component.
Second interpretation:
Encapsulation - mechanism of the language that allows
to restrict the accessibility of some components of the program to the others.
And here's an example in C#:
It's corresponding to both the first, as well as the second interpretations.
I've gotten to see some shitshows about which interpretation is the right one,
and which is for autists, and why at all
there happened to be 2 interpretations
Actually, such shitshows are quite laughable,
it's the same as one group tries to prove that 1 < 2
and the other proving that 3 > 2
Both are right, it's just the accents that are placed slightly differently.
The interpretations don't contradict themselves!
When encapsulating, both unification of data and functions that manipulate this data happens
and, in some cases, access of certain components to others is restricted.
Why only in some cases?
Because, for example, certain languages provide a mechanism for reflection.
Because of it, you can literally invade any class.
And change there even private fields.
I understand that several people are typing about "muh reflection doesn't count"
Well, maybe it doesn't count ¯\_(ツ)_/¯
Herbert Schildt has the same opinion about encapsulation.
Here's a quote from his book. (in russian of course :])
Anyway, encapsulation can't be information hiding.
It's just that some people in comments
copy-pasted definitions close to
either Shildt's definition
or definitions closer to the second interpretation
and are shitting about it being information hiding.
Now read closely motherf*ckers
Encapsulation provides information hiding,
but is not information hiding itself.
I can provide some shit in a hater's face.
Does that mean that i'm a piece of shit?
No.
And if ANYONE f*ckin' says in the comments that encapsulation is hiding...
Then immediately call Elon Musk, because on the traction of my
flaming ass he'll be able to reach the stratosphere faster, then
on f*cking falcon heavy.
and
Here's some more proof
Even Steve McConnell separates these 2 concepts.
Hiding and encapsulation.
yes, if you open any adequate OOP author's book
the concepts of hiding and encapsulation are properly separated.
Herbert Schildt might not be the widest accepted OOP genius of this world,
but if you want to get fundamental OOP knowledge
you can read Meyer's bookie
"Object-oriented Software Construction".
And yes, encapsulation sometimes disappears
from the general list of OOP paradigms.
For example, it happens in Mitchell's book
"Concepts in programming languages"
why?
Because he just wanted to throw it the f*ck away.
Well, he got rid of it.
Now let's transition to the second paradigm - inheritance.
Well, here it's easier with interpretations.
Maybe.
Inheritance - is the mechanism of a language that allows description of a new class based on an existing one
that allows description of a new class
based on an existing one
In C# code it looks roughly like this:
In reality, this paradigm is also problematic
For example, a lot of people, when defining the interpretation,
say it helps with code reuse
Just so they don't need to repeat the definition of a method
they can just smear themselves with inheritance and everything should be ok,
even though it can be achieved through other means.
(for example: with the help of agregation and composition)
Actually, in current OOP,
inheritance is needed just to form hierarchies of familiar objects.
And open the gates for polymorphism.
Just by itself, it's utterly f*cking useless, and even dangerous
because it's the reason of a strong binding
If speaking simpler, you can get a parent class
That has 2000 children
And you'll be afraid to add changes to the base class
just because it might cause unwanted influence on the children.
And i don't only mean classes-inheritors
but your personal children too.
Because if you'll add some this in prod and it'll cause problems
then your colleagues might want to apply some force on your buns
In "desired" OOP inheritance, in general,
should work a little bit different.
Speaking concretely, it should work like
prototyped inheritance in JavaScript.
There, the parent is not a class
but an exactly formed object.
Naturally, in JavaScript, the parent Object can be modified on the way
adding some little properties and all that kind of stuff,
which gives this system additional possibilities.
Of course, this is only possible due to JS's dynamic nature,
desired OOP should, in general, only work with
languages that have dynamic typing,
even Alan Kay wrote about this in his letter.
Link to this letter will be you know where.
You know what the funniest about this?
In JS standard ES 6 they added
default #-like classes with the possibility of inheritance
Still can't understand why was this added
if in our little JS world everything was fine even without it.
By the way, inheritance is the most persistent paradigm
it's almost never thrown out of the shared list.
Third paradigm: Polymorphism
And here comes the slaughtering,
because polymorphism is thought of as the main feature of the "existing" OOP
And a secondary feature of the "desired" OOP
You can't get away with with just the definition,
simply because in languages like C#
polymorphism has several forms.
"Intentional polymorphism" or Ad Hoc polymorphysm
in folklore, shittymorphism (because it's sometimes hated)
In C#, it's represented with method overloading.
Like when you define several methods
with the same names
but with different argument types.
Parametric polymorphism,
which in C# is represented by generics.
And subtype polymorphism
that is achieved with mechanisms like inheritance and upcasting.
The last one is the one we're interested in.
Because subtype polymorphism is meant when discussing OOP
In languages with static typing, without polymorphism in it's current form
our OOP would've ended here.
And would be totally insignifficant.
Well, maybe only, at max, put code in modules ¯\_(ツ)_/¯
Wouldn't be so cool, would it?
But clever men saved the situation
they sat
they thought
and came up how to give the possibility of different realisations
to similar types that have obvious inheritance hierarches
This is why with the help of
method overriding and upcasting
our objects can solve different tasks
Sounds scary, but in fact it's quite easy.
Here's how a simple logging system works in C#
We have a hierarchy of classes
whose task is to log all kinds of shit,
one realisation logs to console,
another one writes it to a file
and the third one sends the log to the deepest deeps of the internet.
And, during the execution of the program,
the user decides himself which realisation he likes more
Well if in languages with static typing
it wouldn't be possible to program without polymorphism,
then in languages with dynamic typing
we could go crazy and just change methods during runtime
In general, this kind of code in JS
Is considered a manifestation of parametrized polymorphism
With dynamic typing,
polymorphism feels so natural
that you use it without thinking,
And all of that while in languages with static typing
it's easier to suck your own c*ck
then to get the hang of polymorphism.
This is why JavaStrippers that getting into C# can't breathe with their full chest
they're suffocated by static typing.
You can easily understand how Ad Hoc polymorphism
and parametrized polymorphism work,
but subtype polymorphism is a lot tougher
For me, i realized how it works
only after i tried to learn patterns
and when i understood how the "Strategy" pattern works
i understood why you even need subtype polymorphism
and interfaces.
We have a video about the strategy pattern, btw. [I haven't subbed that one and i won't.]
[God subbing is hard, why did i even start this?]
The link to it will be you know where.
Since we're this far,
let me show you one interesting thingie
How can we call Test() after upcasting?
We can't. Did it disappear?
Not really, because it's called through Test2().
Did the method Test() become private from public?
That's true, what's our conclusion?
Polymorphism provides information hiding.
Doesn't it remind you of anything?
Polymorphism, just like inheritance,
never leaves the general list of OOP paradigms.
The only thing that usually changes is it's importance degree,
depending on the language's type system.
For example, in python context it's "eh some kind of polymorphism"
But in C# context it's "Wowie, polymorphism!"
4th Paradigm: Abstraction
[*Polymorphism beats guy*] ["it can't be worse"] [*abstraction comes in*]
Quite interesting paradigm.
Abstraction is often misunderstood and confused with encapsulation
just because f*cking information hiding is involved.
I'm fucking sick of it already.
Abstraction says that we should highlight the important characteristicts of objects
The main meaning of this is
depending on use the minimal necessary characteristics kit
to solve the given problem.
And it's confused with encapsulation
because both indirectly influence the formation
of our future type's public interface.
Actually, abstraction is an important part of OOP.
But dude it's so trivial that i wouldn't extract it into a separate paradigm.
And a lot of book authors do so.
Yeah, abstraction may not be mentioned at all.
Or they can extract a separate small definition
and not relate it to OOP paradigms
Personally, i don't remember abstraction to be delivered as an entire paradigm
while reading the books in preparation of this video,
unlike all sorts of internet articles and wikis i've read,
where the enthusiasm about this topic might seem unhealthy,
while, in analagous english sources
this kind of shit doesn't happen.
Next paradigm: Message sending
This is just a fancy way of calling the process
of one object calling a method of other object.
And yes, that's literally it,
if we're talking about the OOP realisation of languages like C++, Java and C#
Not so cool, and like, common sense,
this is why this paradigm is rarely talked about
that's why it often falls out of the shared list.
But actually, it's not that easy.
The Objective C realization of OOP is different
because message sending is a little bit different
from C++, C# and Java
The difference is that if the object doesn't have the called method
Then nothing happens.
For example, with this kind of realization
we can try to call a method on a null object
without getting spanked by exceptions.
But when we try to call a method on a null in "C with bars"
it begins to show why it was given this nickname.
Because in it, everything's strict.
The class has a method then you can address the object of this class
by calling this method.
But calling a method that isn't defined
isn't cool, and the compiler bends you over
on the compilation stage.
It's this way, and not how
Alan Kay planned in the source material
just because pfft, too slow, let's remove the stupid overhead
because your shitty message sending isn't efficient, therefore bad
And in general, there wasn't such paradigm, go f*ck yourself.
And that's why David West and Alan Kay,
are, to this day, boiling.
Because they think this moment is really fucking important
and without it, OOP is not OOP, and just a piece of shit for procedurals
Actually, we can emulate message sending.
For example here's the realization of message sending
from Artiom on JavaScript.
You know where to find the link to the github.
You can read about these things in more details in the book
Structure and Interpretation of Computer Programs, 3rd chapter.
However they're coding in a dead lisp dialect, so
if you decide to read it,
heat and moisturise your head beforehand
thiw way, it'll be easier to relax the old-skull [poorly translated joke warning]
Next paradigm:
Code Reuse
This is one blurry paradigm.
It implies that all preceding 5 paradigms
need to be directed towards code reuse.
Isn't it f*cking obvious?
Totally unsurprised it's always yeeted out the window
Maybe it makes some sense from a philosophical point of view?
Or maybe it doesn't.
There are certain intellectuals whose explanative comments i'm waiting.
Because this topic is really strange.
I've dug up thousands of sources
to understand the sacral meaning of this blabbering,
but even if someone writes about code reuse
Then it's something like
"Well code reuse,
well you know,
If you reuse code, you'll have to type less"
What are you talkin' bout, captain?
Well, if certain sources allow themselves to
change the number of paradigms and their interpretations
How's this channel any worse?
I propose the universal, cross-conceptual paradigm with the number 6,5
"Opisdulation"
This paradigm says that guys writing code that can't be changed
after it's written, need to be beaten up in a dark alley
Well, here's the end of paradigms.
I've gotten to meet some kit
consisting of 9 paradigms,
which had 4 paradigms from the base set
and 5 more conceptions from SOLID,
but, in general, the only ones complaining where students of certain institutions
It's some interesting group of cool teachers.
I'm not gonna argue whether it's out of place with OOP,
but SOLID is a cool thing
and we'll certainly sort it out sometime.
Don't forget to subscribe and hit the cowbell.
And all the links to the materials
that were used in these videos
can be found in my ass. Goodbye frens!
Ver Más Videos Relacionados
So Many Programming Languages
Вас просто не выбрали. Какая разница, что там за тип привязанности?
쿼터급 바이크의 모든것 (1시간 순삭)
Hem Oyun Hem Müzik İçin En İyi Seçenek ? | Kinera QoA Gimlet IEM Kulaklık İncelemesi
The English Language in 65 Accents
Tesla: Start der nächsten Kaufwelle? DAX und Porsche bald mit Kaufsignalen?
5.0 / 5 (0 votes)