The Pain of OOP Lecture #1: The Intent object thinking [object oriented programming crash course]

A lecture for BSc students in Innopolis University.

0:00 Course description
2:51 Who started it
4:00 Objects, Classes and Inheritance. Simula-67
6:11 OOP term. Smalltalk
11:00 C++, Bjarne Stroustrup
16:48 Other languages
18:46 OOP features
26:48 Original idea
28:40 Abstraction
37:45 Data hiding
41:33 Behavior exposing
44:00 An object as a function
45:45 Identity, State, Behavior
52:52 Composition
55:25 Object Thinking vs. Algorithms. While-Do loop
59:33 Buffer abstraction
1:01:36 Loop abstraction
1:04:42 Object composition
1:09:12 Enemies of Object Thinking
1:13:15 How to Pass the Exam
1:15:04 Read and Watch

[yakovlev_io]

Great start, congratulations! It's been a couple of years since I was introduced to your vision of OOP. I am now really excited about the prospect of practical examples and code refactoring that you mentioned as part of your plan for future lectures

[ozgNYC]

This is awesome!

According to wiki, Simula was developed in 1962s, but OOP concepts were introduced in Simula67, released in 1967.

[avidrucker]

At 33:55 the "square" functions ought to be "area" or "rectArea" (I presume camel case is appropriate here) for clarity of intent, in my opinion. They otherwise could be confused otherwise with "power of 2" mathematical squaring.

[saske]

Круто, долго ждал продолженеия (или перезапуска) курса, оригинальная вводная лекция помогла мне въехать в ООП

[stanislavrodionov]

Интересная лекция, мне нравится чёткостью введения понятий. Есть несколько вещей, которые я бы уточнил.
1. Наверное не стоит говорить "код слева плохой, код справа хороший". Есть две парадигмы, которые хороши в разных ситуациях. Когда я пишу быстрый прототип, или делаю хотфикс за 10 минут до приёмки у клиента, я выберу функциональную парадигму, потому что она даёт быстрый эффект. Пусть даже я сломаю архитектуру (временно). Если я проектирую систему, с которой мне жить годы и годы, и у меня нет прессинга по времени, я выберу объектный подход. Насколько я понимаю, над объектным кодом надо много думать сразу. Над функциональным кодом придётся много думать потом.
2. Реализация класса Distance после приведения именования членов в соответствие с их именами:

class Distance {
private:
float left, right;
public:
Distance(float a, b) {
if (a < b) {
left = a;
right = b;
}
else {
left = b;
right = a;
}
};
float Value() {return right - left;};
}

3. Для примера с распечатыванием буфера, было бы хорошо уйти от использования глобальных переменных внутри класса. Я бы передал STDOUT.puts внутрь Buffer через конструктор как штатный метод печати, и STDIN.readchar в Pull как метод чтения. Тогда в реализации классов не будет никаких внешних зависимостей. В реализации классов мы абстрагируемся от того, как мы читаем и печатаем символы, - эти методы будут просто переданы в конструктор.

[andrey]

Great research and presentation, Yegor!

This video really gives u more understanding of why there are so many views on what OOP actually is 👍 Thanks a lot!

[osagbemisunday]

Thank you Yegor. BTW, the explanation is balance and any reasonable manager should appreciate a subordinate with the perspectives shared in this video.

[ChrisAthanas]

I appreciate the refresh and refinement of this material

It’s all very relevant

[ryanharris]

Excellent. I'm going to practice this from now on.

[fight_fire_with_fire]

Hi, Yegor, I watched a bunch of videos regarding your vision on the OOP with no clear understanding. But now I really liked the example with having the students enter the room. It explains the respect one needs to pay to the objects (student/students), literally. You are just on the higher level of abstraction when asking the entire group enter the room. No need to tell them to enter one by one and repeatedly move one leg after another. They are able to do it on their own with no imperative instructions provided.

[AlekseyV]

Спасибо! Обожаю ламповые фотки с большими компьютерами!

[MegaAnufriev]

While the refactored "STDIN reading" code demonstrates a good understanding of object-oriented principles such as encapsulation and abstraction, the line could be seen as a bit cryptic in terms of readability and intent. This line of code does not convey the intent "to have STDIN line to be printed in groups of 4 characters on each line"
and requires readers to investigate each class individually to comprehend the overall behavior. In practice, code should be self-documenting as much as possible; the functionality should be evident through the naming and structure of the code itself.

[farrukhjonnazriev]

watching the lecture i felt myself like a Po Panda in the cartoon when he found out that he is not a duck

[erayxx]

Hello Mr. Yegor, I think you are a very knowledgable and visionary person. It is really amazing to see that you are providing contrary views on the topic, and mentioning important figures on the field. Thank you for sharing your lectures with the Internet.

About the section that you refactor the procedural code accoring to OOP paradigm: I think procedural code was much simpler, and had less code. What is the benefit of creating many layers of abstraction for me? It seems like it makes the code harder to both
- understand (It includes many abstraction that I have to understand)
- and maintain (It is hard too keep track of the flow, when a bug reported it would be hard for me to find the cause of it)

How would you advocate the code that includes the abstractions Pulls, Pull and Buffer against the simple procedural one? What are the benefits of it?

[JackLilhammers]

At page 15 of your slides, there is a list of languages with their creation date.
Go is listed as created in 1995, but it was designed in 2007 and the first version was released in 2009.
Maybe you meant a different language?

[mohsennoor]

ممنون ایگور 🌿 مقدمه سرفصل مطالب دوره رو هم خیلی خوب انتزاعی توضیح دادید

[MegaAnufriev]

In the context of Object-Oriented Programming, conceptualizing 'distance' as a standalone class with its own constructor and method may not be the most effective approach. Instead, it's more practical and aligned with OOP principles to embed the ability to calculate distance within the objects themselves. This can be achieved by implementing a method like `distance(other: float` in an interface or abstract class. Objects that need to provide distance measurements can then implement this interface. This design not only encapsulates the distance calculation within the objects that own the relevant data but also promotes polymorphism. It allows for a more flexible and context-sensitive calculation of distance, as the method can be tailored to the specific characteristics and needs of different objects. Rather than treating distance as an independent entity, this approach recognizes it as a property or outcome of the interaction between objects, which is more reflective of real-world scenarios and the ethos of OOP.

[Qsufff]

Many thanks, Yegor!

Great lecture to rethink and reopen OOP ideas!

I've caught the idea that in the lecture
history of creating different languages as collection of names and code samples is a little bit boring. Maybe it's too academic. Don't know how to improve it. It would be wrong to wipe it out and maybe too much to unite it with a higher abstract idea that would be memorized and after some time when names and the languages possibly would be forgotten, the idea - not.

Part of object oriented thinking is extremely interesting. Watching the code development in the OO style in the code is cool. And of cause after this part we can see that paradigm of OO language and good coding in it has a lot of common with functional programming. So it's also great impuls to rethink and reopen this paradigm too)

[АнтошаГорохов]

Тут хороший английский для понимания :)

[AhmedZahranDEV]

i have a question
what if we deal with ORM like hibernate and the entity is responsabel for getting and setting data how we cpuld deal with that as oop way and hide data in entity