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
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!
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.
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.
Thank you Yegor. BTW, the explanation is balance and any reasonable manager should appreciate a subordinate with the perspectives shared in this video.
While the refactored "STDIN reading" code demonstrates a good understanding of object-oriented principles such as encapsulation and abstraction, the line `Pulls.new(Pull.new(Buffer.new)).fetch` 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.
Интересная лекция, мне нравится чёткостью введения понятий. Есть несколько вещей, которые я бы уточнил. 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 как метод чтения. Тогда в реализации классов не будет никаких внешних зависимостей. В реализации классов мы абстрагируемся от того, как мы читаем и печатаем символы, - эти методы будут просто переданы в конструктор.
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?
In this particular simple case, the procedural code is easier to understand (for most programmers). However, when the code becomes larger, visibility of concepts in a procedural code decreases. Abstractions help us isolate paradigms from one another and focus on only one at hand. Keep watching the videos, you will eventually get the idea :)
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: AnyObjectThatExposesDistance): 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.
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?
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
Thanks for great lecture, it gives me new insight on this subject. I just want to know your opinion about using value object and introduction of record in Java. What do you think of the data oriented programming that Java try to achieve by introducing records and other stuff?
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)
Че-то короче в итоге в первой лекции в конце как раз и получилось то за что ругали ООП в начале - очень сложное решение очень простого алгоритма, с кучей дополнительных названий которые нужно понять что означают. Видимо такие простые алгоритмы бесполезно пытаться объяснить и переделать на ООП, будет только хуже.
Имхо: это немного напоминает b-tree. Пока тебе надо хранить данные в пределах листа - вообще непонятно нафига весь этот тюнинг. Но с ростом количества данных, проблемы доступа будут снижаться логорифмически, относительно простого линейного складирования, хотя и встает побочная задача ребалансировки. Так и тут. Пока алгоритм помещается в память человека - 4-6 шагов смысла в декомпозиции его на уровни абстракции нет. Когда алгоритм разрастается на 300 строк - его невозможно воспринимать. Удачный выбор абстракций позволяет воспринять алгоритм на каждом уровне абстракции целиком, быстро спуститься вниз по уровням абстракции в нужное место и решать в конце концов простейшую проблему, хотя и присутствуют накладные расходы на определение абстракций.
Good introduction. But my main concern ist that you encourage to break the "single responsibility" principle. For example, a circle is so simple that it should be really just that, plain data. But if it can print itself, then draw itself, and what not, then it covers just too many aspects and carries all the bloat when it is actually not needed. This can also hurt modularity. Imagine you want to change its renderer, now you have to modify the code of the circle. But if you keep the renderer separate, you will only need to modify the renderer without touching all the objects that can be rendered. In summary. I think the problem comes from the (dogmatic) prescription that every object should be strongly behavioral. But not all objects are the same. Some can be very complex and behavioral, while others can be just plain data in nature, such as an Integer or a geometry shape such as a circle. So a utility class is actually the correct design for objects that are close to be plain data. So if we modify/extend our OOP understanding to this fact, then I think OOP is actually an appropriate and efficient way to achieve modular and efficient software architectecture.
@@yegor256 Yes, but I think there are levels to behavior, and plain simple data (such as Integer) is just an extreme case where behavior is non-existent. May be to elaborate on the philosophy, which is formally consistent: How does an Integer know how it is going to be used by a system acting on it (in OOP terms an object that encapsulates an Integer variable for some internal state)? It doesn't, as the view is always top down. A system at a higher level looks at a lower level, but the lower lever doesn't see the higher level. So an Integer can be used to represent a counter, a fixed-point-number, a bool value, or whatever, but it has no idea how it will be used by a higher level system because it is not its responsibility. Thus, it is the responsibility of the system to modify the integer as necessary, and that is why an integer (in any sensible language) doesn't encapsulate its state and has no behavior. The same argument goes for a Circle, the responsibility of a Circle is the representation of a geometric object. It is only one level above integer as the radius can be encapsulated and restricted to only positive numbers. But other than that, you can change the radius. But in any case, a Circle doesn't have a view on a higher level system such as the Renderer. Thus the circle cannot render itself, if you don't want to contradict the core top-down principles of scaleable architectures. So the Renderer gets the Circle as an input in order to render that. So if an object tries to cover more responsibilites than actually necessary, you will limit the flexibility of the architecture (for actually no good reason other than having all of the non-related functionality (like printing, drawing, and so on) inside one object), for a sufficiently large real world application, because the objects will tend to be like coarse lego blocks, which limit the flexibility of the "software-buildings" you can construct. Even worse, imagine you want to modify one aspect of the software, such as the rendering. Now since the objects try to cover as many aspects/responsibilities as seems convenient on the first glance, you will probably end up modifying many types of object that render stuff. But if you have a higher level system responsible for one aspect (such as rendering, for example), you would only need to modify that system. The software will also have bad performance, but I am even ignoring this aspect, just mentioning it on the side. The performance will be bad because the objects will carry and manage duplicated states which should actually be a shared state and managed by a higher-level system acting on the respective objects.
I just wanted to give an alternative perspective to the Part from 59:34 - 1:09:10 But before, I really enjoyed the first part of your lecture, trying to understand where OOP came from and what it tried to solve was fascinating and I took some points to heart for my next projects :D Besides, here is my criticism: From my experience abstraction CAN be a good thing, if done right, the classical concept of OOP is "the more, the better" but I think there is a limit to it and we should try to strive for a necessary minimum, because we're all software engineers, we're supposed to be able to read programming languages. Some people call it "fitting in ones head" because it is hard to find the line, but essentially you and your colleagues should be able to say "I can understand what is written there and feel confident changing stuff inside". Pulls.new(Pull.new(Buffer.new)).fetch is NOT easy to understand or work with, because rather than achieving your goal of abstracting what happens inside, you leak out major steps of you algorithm (presumably in the name of reusability) to the outside, where a behaviour like that makes no sense anymore. Even finding better names for it wont solve the issue I'm afraid. My approach would be to just name your algorithm according to its use case, if it's in a file, why not name the file accordingly, now you have 1 function or file that you execute, disregarding HOW it achieves the resulting behaviour - just like You've mentioned before with placing the people in the room. Also the LOC will be reduced drastically, which helps getting a grasp of the algorithm and be able to change it easily and quickly in the future, no matter where the change occurs. Let's have a friendly discussion in the comments and please tell me if I misundertstood the goal of Your lecture or the stuff You've talked about.
The impression you have about the code I suggested is very typical. Most people (including myself, some time ago), who are trained to write procedural code, find such code hard to understand. This happens, I believe, because we are trained to read code algorithmically, finding connections between data and their processing code blocks. My suggestion: just let it stay in your head for a while, and eventually your perception will change.
@@yegor256 Thank You, I will try that :) Right now it's pretty vague but I might have latched on to something. Would You mind answering some questions in hopes of getting myself deeper in Your head and resolve some confusion? 1. Do you think there is a limit to the phrase "the more abstractions the better" and if yes how would you try to find it? 2. So you're trying to expose all the steps necessary in your algorythm to the top? If yes, it it so You can change the algorythm without diving layers deep down? 3. Is this Code just an example for the students to show the process (without needing to introduce a really complicated code base) or would You actually write this in a scenario where You got asked print out the lines? 4. Do You think about reusing code fragments before there is an established need to reuse it? 5. Where would You put "Software architecture" in the Development Cycle?
I love the way you smash (and worry) about implementing your "crazy" ideas - "then you will try to apply it to your everyday work you may get fired for this so be careful"😆 . It's a sad reality I've faced in this industry for many years.
![The Pain of OOP Lecture #2: Static methods and attributes [object oriented programming crash course]](http://i.ytimg.com/vi/lELJSj9mWbI/mqdefault.jpg)
![The Pain of OOP Lecture #2: Static methods and attributes [object oriented programming crash course]](/img/tr.png)
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
This is awesome!
According to wiki, Simula was developed in 1962s, but OOP concepts were introduced in Simula67, released in 1967.
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!
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.
Круто, долго ждал продолженеия (или перезапуска) курса, оригинальная вводная лекция помогла мне въехать в ООП
I appreciate the refresh and refinement of this material
It’s all very relevant
Thanks for watching!
Excellent. I'm going to practice this from now on.
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.
Glad you liked the metaphor!
Спасибо, Егор! Крутая лекция ❤️
Thank you Yegor. BTW, the explanation is balance and any reasonable manager should appreciate a subordinate with the perspectives shared in this video.
Good one, thanks Yegor, well done!
Glad you liked it!
While the refactored "STDIN reading" code demonstrates a good understanding of object-oriented principles such as encapsulation and abstraction, the line `Pulls.new(Pull.new(Buffer.new)).fetch` 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.
Спасибо! Обожаю ламповые фотки с большими компьютерами!
Thanks Yegor!
Интересная лекция, мне нравится чёткостью введения понятий. Есть несколько вещей, которые я бы уточнил.
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 как метод чтения. Тогда в реализации классов не будет никаких внешних зависимостей. В реализации классов мы абстрагируемся от того, как мы читаем и печатаем символы, - эти методы будут просто переданы в конструктор.
Очень интересная лекция! Спасибо!
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?
In this particular simple case, the procedural code is easier to understand (for most programmers). However, when the code becomes larger, visibility of concepts in a procedural code decreases. Abstractions help us isolate paradigms from one another and focus on only one at hand. Keep watching the videos, you will eventually get the idea :)
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: AnyObjectThatExposesDistance): 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.
watching the lecture i felt myself like a Po Panda in the cartoon when he found out that he is not a duck
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?
This is definitely a typo, my mistake. Thanks for noticing.
@@yegor256 Егор ты дальше поанируешь теорией заниматься или практикой (бизнесом) в коммерческой сткхми? Хуавей ушел из РФ?
@@Юрченко_Илья дальше планирую теорией заниматься и применять ее на практике :)
@@yegor256 Хуавей ушел из России ?
small point, but golang was introduced in 2009.
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
We'll discuss this in the next lecture
Thanks for great lecture, it gives me new insight on this subject.
I just want to know your opinion about using value object and introduction of record in Java. What do you think of the data oriented programming that Java try to achieve by introducing records and other stuff?
It helps sometimes, but it leads us away from OOP
Тут хороший английский для понимания :)
@yegor256 can you please share the slides/pdf?
Sure, here: github.com/yegor256/painofoop
ممنون ایگور 🌿 مقدمه سرفصل مطالب دوره رو هم خیلی خوب انتزاعی توضیح دادید
very cool very cool lecture thanks
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)
We need more lectures on this
They are coming :)
Audio is perfect
Took me years to figure out how to manage audio in my lectures :)
@@yegor256 it's harder than it looks
Get it
Bc you can't see audio
Har har
Thanks Yegor. Will you share more lessons about this subject anytime soon?
Yes, definitely. Stay tuned.
17:42 а где Objective-C в этом списке?
Че-то короче в итоге в первой лекции в конце как раз и получилось то за что ругали ООП в начале - очень сложное решение очень простого алгоритма, с кучей дополнительных названий которые нужно понять что означают. Видимо такие простые алгоритмы бесполезно пытаться объяснить и переделать на ООП, будет только хуже.
Да, на таких простых примерах получается что-то более сложное (с первого взгляда), чем то, с чего начали. Но это только на простых примерах.
Имхо: это немного напоминает b-tree. Пока тебе надо хранить данные в пределах листа - вообще непонятно нафига весь этот тюнинг. Но с ростом количества данных, проблемы доступа будут снижаться логорифмически, относительно простого линейного складирования, хотя и встает побочная задача ребалансировки.
Так и тут. Пока алгоритм помещается в память человека - 4-6 шагов смысла в декомпозиции его на уровни абстракции нет. Когда алгоритм разрастается на 300 строк - его невозможно воспринимать. Удачный выбор абстракций позволяет воспринять алгоритм на каждом уровне абстракции целиком, быстро спуститься вниз по уровням абстракции в нужное место и решать в конце концов простейшую проблему, хотя и присутствуют накладные расходы на определение абстракций.
Интересует, какие у Вас лабы по данному курсу?
Good introduction. But my main concern ist that you encourage to break the "single responsibility" principle. For example, a circle is so simple that it should be really just that, plain data. But if it can print itself, then draw itself, and what not, then it covers just too many aspects and carries all the bloat when it is actually not needed. This can also hurt modularity. Imagine you want to change its renderer, now you have to modify the code of the circle. But if you keep the renderer separate, you will only need to modify the renderer without touching all the objects that can be rendered.
In summary. I think the problem comes from the (dogmatic) prescription that every object should be strongly behavioral. But not all objects are the same. Some can be very complex and behavioral, while others can be just plain data in nature, such as an Integer or a geometry shape such as a circle. So a utility class is actually the correct design for objects that are close to be plain data. So if we modify/extend our OOP understanding to this fact, then I think OOP is actually an appropriate and efficient way to achieve modular and efficient software architectecture.
it’s better to stick to behavioral idea, I believe
@@yegor256 Yes, but I think there are levels to behavior, and plain simple data (such as Integer) is just an extreme case where behavior is non-existent. May be to elaborate on the philosophy, which is formally consistent: How does an Integer know how it is going to be used by a system acting on it (in OOP terms an object that encapsulates an Integer variable for some internal state)? It doesn't, as the view is always top down. A system at a higher level looks at a lower level, but the lower lever doesn't see the higher level. So an Integer can be used to represent a counter, a fixed-point-number, a bool value, or whatever, but it has no idea how it will be used by a higher level system because it is not its responsibility. Thus, it is the responsibility of the system to modify the integer as necessary, and that is why an integer (in any sensible language) doesn't encapsulate its state and has no behavior. The same argument goes for a Circle, the responsibility of a Circle is the representation of a geometric object. It is only one level above integer as the radius can be encapsulated and restricted to only positive numbers. But other than that, you can change the radius. But in any case, a Circle doesn't have a view on a higher level system such as the Renderer. Thus the circle cannot render itself, if you don't want to contradict the core top-down principles of scaleable architectures. So the Renderer gets the Circle as an input in order to render that.
So if an object tries to cover more responsibilites than actually necessary, you will limit the flexibility of the architecture (for actually no good reason other than having all of the non-related functionality (like printing, drawing, and so on) inside one object), for a sufficiently large real world application, because the objects will tend to be like coarse lego blocks, which limit the flexibility of the "software-buildings" you can construct. Even worse, imagine you want to modify one aspect of the software, such as the rendering. Now since the objects try to cover as many aspects/responsibilities as seems convenient on the first glance, you will probably end up modifying many types of object that render stuff. But if you have a higher level system responsible for one aspect (such as rendering, for example), you would only need to modify that system.
The software will also have bad performance, but I am even ignoring this aspect, just mentioning it on the side. The performance will be bad because the objects will carry and manage duplicated states which should actually be a shared state and managed by a higher-level system acting on the respective objects.
I'm not sure, but wasn't go released in 2009?
nvm some one already tell it in comments
Все-таки ругал-ругал Егор новые макбуки, но тем не менее пользуется :-). Видимо старый совсем сломался
Сломался окончательно )
Здарова Егор, дай презентацию, полистать на досуге в лУчшем качестве?
The slides are here: github.com/yegor256/painofoop (in LaTeX and PDF)
Я бы английский выучил только для того, чтобы понять, что тут говорит лектор
Яндекс Браузер перевочик и все познаешь.
void getRadius 48:30
Go появился в 2007 и он совсем не ООП
Но в контексте identity, state, behavior and composition golang - это ооп)
Нравится четкой изложения, досмотрю курс до конца!
Английский супер. Я даже и не заметил, что видео не на русском)
I just wanted to give an alternative perspective to the Part from 59:34 - 1:09:10
But before, I really enjoyed the first part of your lecture, trying to understand where OOP came from and what it tried to solve was fascinating and I took some points to heart for my next projects :D
Besides, here is my criticism:
From my experience abstraction CAN be a good thing, if done right, the classical concept of OOP is "the more, the better" but I think there is a limit to it and we should try to strive for a necessary minimum, because we're all software engineers, we're supposed to be able to read programming languages.
Some people call it "fitting in ones head" because it is hard to find the line, but essentially you and your colleagues should be able to say "I can understand what is written there and feel confident changing stuff inside".
Pulls.new(Pull.new(Buffer.new)).fetch is NOT easy to understand or work with, because rather than achieving your goal of abstracting what happens inside, you leak out major steps of you algorithm (presumably in the name of reusability) to the outside, where a behaviour like that makes no sense anymore.
Even finding better names for it wont solve the issue I'm afraid.
My approach would be to just name your algorithm according to its use case, if it's in a file, why not name the file accordingly, now you have 1 function or file that you execute, disregarding HOW it achieves the resulting behaviour - just like You've mentioned before with placing the people in the room.
Also the LOC will be reduced drastically, which helps getting a grasp of the algorithm and be able to change it easily and quickly in the future, no matter where the change occurs.
Let's have a friendly discussion in the comments and please tell me if I misundertstood the goal of Your lecture or the stuff You've talked about.
The impression you have about the code I suggested is very typical. Most people (including myself, some time ago), who are trained to write procedural code, find such code hard to understand. This happens, I believe, because we are trained to read code algorithmically, finding connections between data and their processing code blocks. My suggestion: just let it stay in your head for a while, and eventually your perception will change.
@@yegor256 Thank You, I will try that :)
Right now it's pretty vague but I might have latched on to something.
Would You mind answering some questions in hopes of getting myself deeper in Your head and resolve some confusion?
1. Do you think there is a limit to the phrase "the more abstractions the better" and if yes how would you try to find it?
2. So you're trying to expose all the steps necessary in your algorythm to the top? If yes, it it so You can change the algorythm without diving layers deep down?
3. Is this Code just an example for the students to show the process (without needing to introduce a really complicated code base) or would You actually write this in a scenario where You got asked print out the lines?
4. Do You think about reusing code fragments before there is an established need to reuse it?
5. Where would You put "Software architecture" in the Development Cycle?
Егор ты читаешь студентам ?
Там английский не кто не знает же
Большинство из них знают лучше меня :)
Stop alcohol
I love the way you smash (and worry) about implementing your "crazy" ideas - "then you will try to apply it to your everyday work you may get fired for this so be careful"😆 . It's a sad reality I've faced in this industry for many years.
WTF is Innopolis University? 😳
It's a very good school: innopolis.university/en/
А можно на русском??? Ну или на английском но там где ошибок поменьше(((( 😢