Based on my experience, it's often because they don't care rather than not understanding the reasons behind it. Many developers I've worked with stick with what works without questioning it. You simply can't teach someone who doesn't want to learn.
This is why I appreciate better tools (like: code analysis, source generators). If the wrong way is inconvenient, even those that don't care will adapt.
Everyone wants to learn. Things they can put on their resume. I have yet to see an IT Dev's resume that says "I take pride in my work and professionalism". Are you ready to do that? Chris is trying to help.
Exactly. Do have a look at the talk (by Richard Feldman) that I linked in the description for a deeper dive. It’s really great and makes the concept really clear. Thanks for watching and for commenting 😊🙏
A powerful approach (that I've also seen you take several times in your videos) is to start with a problem. Present a scenario we want to model, implement it naively, then explore shortcomings of said naive solution. _Then_ you can swoop in with the fancy pattern/guideline/principle and show how it saves the day. You've got justification, intended use case(s) and deeper understanding all in one neat package. For bonus points, also explore the limitations/tradeoffs inherent to the "better way" for a more well-rounded engagement with the topic.
Are code samples really necessarily though? Once you grasp all those concepts it’s pretty clear what it’s been talked about. The video assumes you understand and are familiar with OOP. Would you like to dig deeper? Buy the book.
Started to understand the design patterns from your playlist few days back, that topic was a nightmare for me to understand, tried to understand it from other youtubers before finding your playlist, but that didn't work also. But now after watching your playlist, it very helps. Very thankful to you and hoping that you keep sharing and teaching more valuable concepts for software engineering students. Thanks
Videos like this are invaluable. Concerning type testing, I still believe there is a case for subtyping even when you have pattern matching and exhaustive switch statements (I count implementing traits or protocols/interfaces as subtyping): You need to define whether it is more likely to have an explosion of cases or an explosion of decisions. With subtyping, every time you add a decision, you need to implement a new method for every subtype; With conditionals, every time you add a type, you need to add a new case for every decision you make. It is a trade off. Concerning class hierarchies and multi-level inheritance, the best example I have in mind is biology. Every developer has heard the analogy of animals, mammals, etc. (which is truly terrible, it should disappear from books and tutorials). Biologists and palaeontologists literally break the tree of life every Tuesday! Classifications are arbitrary and, like analogies, they tend to break when you include more cases or more details. When building any kind of hierarchy, it should be expected that it is going to change. And changing class hierarchies is not a trivial refactor.
6) with exhaustive switches/conditionals you need to know all of the possible implementations at compile time. By using subtype polymorphism you could load a valid impl at runtime. Wonderful for something like an DB interface where you can't know of every possible impl. Not so great for typical application code that IS known at compile time.
I'm really liking your take on these OOP concepts. Even after studying computer science at university in the early 2000s, reading dozens of books on the subject of object oriented programming and design and being a professional software developer since 2007, I find your approach on the subject very refreshing and interesting. Bought the book : )
Like I feel you've alluded to: all roads lead towards FP. I have a background and interests more in FP, procedural, and "make it impossible, not testable" types of software. I wanted to drop in and say that as much as I value the OOP-centric videos and concepts (I love your academic and thorough approach in your videos), it can sometimes be challenging to convert the OOP way of thinking to a "general", non OOP, way of thinking. Despite enjoying this challenge, I would love to hear more ideas and concepts that apply more to procedural world of code. Anyway, thank you for making these videos. I watch all of them and appreciate how they encourage critical thinking.
@@Goten2321 I based that comment on how he articulates his new OOP book. For example on the books website there is a clause "the search for the object oriented way seems to be a path that leads to functional programming" :D
This is gold, but I hope this is the first of many videos. To me, the best way of learning something is to understand the reason why it is like that. I always fought against the "it is like that, take it as it is" approach during my university studies. And everybody is learning like this, just memorizing without asking "ok, but why". As a .net developer it was hard to understand why we had webforms, why do we have http, what's soap and why everybody despise it. Luckily there are a couple of videos on .net evolution that answered many of these questions. After years of studying math, I had the chance to attend to a "math's history" course. It was so satisfying to learn how we slowly figured how to solve equations, why we write x^2 and so on
Great video, as always! I would love a deep dive on each of these - got the book now, but I really like the video format, and you are an excellent communicator.
Great explanation (around 4 minutes in) about how static typing makes conditional statements unnecessary. I have been doing this for a while, but this is a clear explanation of why it works.
Thank you for sharing your feedback. I’m happy to hear that way of thinking works. That seems like a sensible way to think about it to me as well. Thanks for watching 😊🙏
Amazing video as always. I bought the book which I'm sure is gonna be so worth it and also to thank you for all the amazing content you gave us access to for free. Thank you for all of that !
I think one of the bigger issues is that it's difficult to teach people when to use which pattern at the right time. Oftentimes we teach by simply giving a problem for which the solution could benefit from some pattern. Certain patterns only become apparently useful when you have some new requirement to deal with. Most problems don't involve any new requirements at all
Hi Christopher, long time no see! Quite a dramatic change of look :) anyway, not judging. I always love your content, especially since the design patterns series. Looking forward to your book. Best of luck, mate. Keep up the good work!
I've haven't heard of, nor do I understand, that reason for Dependency Injection. I use it all the time, but mostly for testing and separation of concerns.
again you strike when I needed I would like to ask you. I'm working on a side project in python, the project is meant for me to have fun and mostly learn more about architecture and complex case handling I have a case where my project has to modes, one is mostly "standalone" and the other is a bit more complex, the second mode is more or less the first one with more functionality / steps So, I thought i'd extract the general use with a protocol (interface) with one method called execute, both modes implementing it and such However, I still have to do a runtime test of (if mode == "standalone" elif mode == "workspace") and creating the types based on that My question would be: Is there a way, no matter how magical or simple or complex, to eliminate the check?
Not everything should be an object. Lots of professors get this wrong. Even Alan Kay himself came to this wrong conclusion file -> namespace(s)/static class(es) { 1. data/state - OOP, DRY Principle 2. external resources - Actor Model, 1-layer abstraction 3. behavior/micro-workflows - pure function like (can take external resources in parameters), FP } // Workflows inside. This is a node of a larger workflow - part of a walking skeleton OOP - data FP - behaviors Actor Model - external resource Give this a try And there are sub-categories in 1, 2, 3. Like algorithms are fully pure functions (unless it is better that they are not) UI Models could wrap data or state models, returning pretty results
And why does this pattern work? From the domain 1. db are domain collectors 2. external resources is how we interact with the domain 3. stories capture actionable workflows in the domain OOP & Dry Principle is perfect for data. As data points thrive on a single source of truth Behaviors are best duplicated when they are used for different purposes. So we don’t have a single point of failure If data driving two unrelated behaviors looks the same, that data should be duplicated and named appropriately too. Different data points By thrive, I don’t mean this is always the case. But generally it is From a computer perspective: 1. Heap - data is large and belongs here 2. interrupts, keyboard & mouse, screen, http, etc… 3. Stack - small and streamlined. Extremely fast. Pointers to the heap We are aligning our code to the domain AND our computer architecture. Which that architecture is partly thanks to Alan Kay! And his work on storing bootloader, heap, and stack seperatly
What if wrong abstraction is already in place and code is worse, hard to maintain because of many broken rules? Do you have suggestion as a way out of problems you mentioned in the video?
Good! I find it hard to understand all things around typing. Just to clarify, you take as an assumption that all code should be static instead of dynamic? I find it very annoying when everything is statically typed when I want to change an existing type or add a new one. (And God forbid type casting annoyance) I'm not against it, but it's been too many years that I don't know how to balance static typing vs dynamic typing... Additionally, there are cases that code implicitly requires subtypes on things that there is no type and it is annoying to do. For example, a method that behaves differently for all integers that are multiple of 3. I would love a deep dive on typings in general around mature oop code... Not very related to this topic, how do you handle all error scenarios in oop? Where should throws be present and where try catchs??? They always mess my code
I feel like Inheritance is more of a last resort. There are many things that are much better than it. Or said in another way: The coding problems that benefit from inheritance are few and far between.
I am a senior Java programmer, and during the past 5 years the only time that I remember that I last used inheritence was for setting up a generic database object with audit and logging functionality that MUST be common to all DB entities. Otherwise, I have totally abused interfaces and implements logic up and down the code base.
I'd like to know your opinion on languages that don't have inheritance but do have interfaces, like Go or Rust. Also, I like a feature Go has called embedding, which is like inheritance but without the sub-type relationship.
You been to go for the no bs mentality. You need to hold customers accountable. If they don't want to plan with you then what's the point? Write code to get the job done, refactor or rewrite when needed. It's how every company has done it. There is no perfect code, there is no perfect solution. All ideas/theories/design patterns live in lala land and quickly fall apart as soon as the meet reality. Most of your errors will be logical errors, which can be solved by discussing things with your customers.
Thank you for the great question. I can’t speak for others. But in my view. The more you study abstractions in OOP and the more you explore how to write maintainable code the more you realize that you are essentially reinventing functional programming in an OOP costume. And at that point I start questioning why we are even bothering with objects in the first place. Thank you again for asking. I’ll explore this deeper in future videos. And if you’re interested in the topic you might like my book: theobjectorientedway.com
How do you abstract away the implementation of multiple user inputs in which the order of that user input is significant so that the output is different if the order is changed. For example if the user presses b first then a is not the same as pressing a first before b.
Thanks for asking 😊🙏 If you don’t have too many patterns to match you might want to have a look at the State pattern. Otherwise Interpreter or Decorator might be helpful.
Static typing is not superior to dynamic typing, it’s just different. Both are great and fun to work with but in different ways. Static typing should not reduce the amount of automated tests written. If it does you are writing too many or wrong kind of tests.
I won't trust anyone who says that working with dynamic types is fun. For a small script/very small program, sure. But you can do whatever for such things. I think the target audience of this video are people writing more complex software, and in this context static typing is absolutely superior to dynamic typing
I'm Kurdish and if you think that hand waving is excessive you need to meet my family. Don't know where your roots are from but I suspect somewhere between Greece and Iran based on the dialect of your hands. 😂
Based on my experience, it's often because they don't care rather than not understanding the reasons behind it. Many developers I've worked with stick with what works without questioning it. You simply can't teach someone who doesn't want to learn.
This is why I appreciate better tools (like: code analysis, source generators). If the wrong way is inconvenient, even those that don't care will adapt.
IT is a domain like every other. There are people who are there for the paycheck and there are people for who it is a profession.
Everyone wants to learn. Things they can put on their resume. I have yet to see an IT Dev's resume that says "I take pride in my work and professionalism". Are you ready to do that? Chris is trying to help.
I love your reason for static typing. Basically we should make invalid states impossible
Exactly. Do have a look at the talk (by Richard Feldman) that I linked in the description for a deeper dive. It’s really great and makes the concept really clear. Thanks for watching and for commenting 😊🙏
Yes, that was simple yet to the point. Genius
A powerful approach (that I've also seen you take several times in your videos) is to start with a problem.
Present a scenario we want to model, implement it naively, then explore shortcomings of said naive solution. _Then_ you can swoop in with the fancy pattern/guideline/principle and show how it saves the day.
You've got justification, intended use case(s) and deeper understanding all in one neat package.
For bonus points, also explore the limitations/tradeoffs inherent to the "better way" for a more well-rounded engagement with the topic.
Thank you very much for the feedback! 😊🙏
Don't make another mistake in your teaching - provide code examples for all of these cases. Apart from that, you're brilliant, thank you.
Thank you for the feedback. Noted. Will do. 😊🙏
Are code samples really necessarily though? Once you grasp all those concepts it’s pretty clear what it’s been talked about. The video assumes you understand and are familiar with OOP. Would you like to dig deeper? Buy the book.
I would love to deep dive into point 5. Replace conditional with polymorphism. Great video, thanks!
ua-cam.com/video/os6ssw1qylU/v-deo.htmlsi=Y_RRgXQoc2KKDBFN
Started to understand the design patterns from your playlist few days back, that topic was a nightmare for me to understand, tried to understand it from other youtubers before finding your playlist, but that didn't work also. But now after watching your playlist, it very helps. Very thankful to you and hoping that you keep sharing and teaching more valuable concepts for software engineering students.
Thanks
You are GOLD, as always ❤
Alot of things here opened my eyes to alot of WHYs I haven't asked. Thanks again. Still rhe best.
Videos like this are invaluable.
Concerning type testing, I still believe there is a case for subtyping even when you have pattern matching and exhaustive switch statements (I count implementing traits or protocols/interfaces as subtyping): You need to define whether it is more likely to have an explosion of cases or an explosion of decisions. With subtyping, every time you add a decision, you need to implement a new method for every subtype; With conditionals, every time you add a type, you need to add a new case for every decision you make. It is a trade off.
Concerning class hierarchies and multi-level inheritance, the best example I have in mind is biology. Every developer has heard the analogy of animals, mammals, etc. (which is truly terrible, it should disappear from books and tutorials). Biologists and palaeontologists literally break the tree of life every Tuesday! Classifications are arbitrary and, like analogies, they tend to break when you include more cases or more details. When building any kind of hierarchy, it should be expected that it is going to change. And changing class hierarchies is not a trivial refactor.
6) with exhaustive switches/conditionals you need to know all of the possible implementations at compile time. By using subtype polymorphism you could load a valid impl at runtime.
Wonderful for something like an DB interface where you can't know of every possible impl. Not so great for typical application code that IS known at compile time.
A video talking about dependency injection (object composition, dependencies lifetime, interception and di containers) would be very cool
I'm really liking your take on these OOP concepts. Even after studying computer science at university in the early 2000s, reading dozens of books on the subject of object oriented programming and design and being a professional software developer since 2007, I find your approach on the subject very refreshing and interesting. Bought the book : )
Like I feel you've alluded to: all roads lead towards FP.
I have a background and interests more in FP, procedural, and "make it impossible, not testable" types of software. I wanted to drop in and say that as much as I value the OOP-centric videos and concepts (I love your academic and thorough approach in your videos), it can sometimes be challenging to convert the OOP way of thinking to a "general", non OOP, way of thinking. Despite enjoying this challenge, I would love to hear more ideas and concepts that apply more to procedural world of code.
Anyway, thank you for making these videos. I watch all of them and appreciate how they encourage critical thinking.
Not that I completely disagree, but I dont see how he has alluded to that.
@@Goten2321 on his book's website atleast.
@@Goten2321 I based that comment on how he articulates his new OOP book. For example on the books website there is a clause "the search for the object oriented way seems to be a path that leads to functional programming" :D
I wish I could read your book and learn from it but in Iran we cannot purchase. but I learn from your awesome videos and I'm grateful for this ❤
This is gold, but I hope this is the first of many videos. To me, the best way of learning something is to understand the reason why it is like that. I always fought against the "it is like that, take it as it is" approach during my university studies. And everybody is learning like this, just memorizing without asking "ok, but why". As a .net developer it was hard to understand why we had webforms, why do we have http, what's soap and why everybody despise it. Luckily there are a couple of videos on .net evolution that answered many of these questions. After years of studying math, I had the chance to attend to a "math's history" course. It was so satisfying to learn how we slowly figured how to solve equations, why we write x^2 and so on
You are my role model, I was always searching for someone who can guide, and seems like the search is over now :)
Thank you for such good content.
Great video, as always! I would love a deep dive on each of these - got the book now, but I really like the video format, and you are an excellent communicator.
If you are running a consulting company, writing complicated and impossible to explain code is a huge advantage😂
Great explanation (around 4 minutes in) about how static typing makes conditional statements unnecessary. I have been doing this for a while, but this is a clear explanation of why it works.
Thank you for sharing your feedback. I’m happy to hear that way of thinking works. That seems like a sensible way to think about it to me as well. Thanks for watching 😊🙏
@@ChristopherOkhravi I bought your book! I like your style and your ideas.
Everything sounds fine, but without clear practical examples it is foggy and will not stick into anyone's mind
Noted. Will give examples in the future. Thank you for watching and for giving feedback 😊
Amazing video as always. I bought the book which I'm sure is gonna be so worth it and also to thank you for all the amazing content you gave us access to for free. Thank you for all of that !
I think one of the bigger issues is that it's difficult to teach people when to use which pattern at the right time. Oftentimes we teach by simply giving a problem for which the solution could benefit from some pattern.
Certain patterns only become apparently useful when you have some new requirement to deal with. Most problems don't involve any new requirements at all
Always happy to see a new video from you. Book purchased!
Thank you very much! 😊🙏
Beautiful book! I purchased it.
Hope will get better and better once completed
Thank you very much. I will make sure of it. 😊🙏
Hi Christopher, long time no see! Quite a dramatic change of look :) anyway, not judging. I always love your content, especially since the design patterns series. Looking forward to your book. Best of luck, mate. Keep up the good work!
I've haven't heard of, nor do I understand, that reason for Dependency Injection. I use it all the time, but mostly for testing and separation of concerns.
You don't use loggers, or DBs, or Message Systems?
again you strike when I needed
I would like to ask you. I'm working on a side project in python, the project is meant for me to have fun and mostly learn more about architecture and complex case handling
I have a case where my project has to modes, one is mostly "standalone" and the other is a bit more complex, the second mode is more or less the first one with more functionality / steps
So, I thought i'd extract the general use with a protocol (interface) with one method called execute, both modes implementing it and such
However, I still have to do a runtime test of (if mode == "standalone" elif mode == "workspace") and creating the types based on that
My question would be: Is there a way, no matter how magical or simple or complex, to eliminate the check?
Not everything should be an object. Lots of professors get this wrong. Even Alan Kay himself came to this wrong conclusion
file -> namespace(s)/static class(es) {
1. data/state - OOP, DRY Principle
2. external resources - Actor Model, 1-layer abstraction
3. behavior/micro-workflows - pure function like (can take external resources in parameters), FP
} // Workflows inside. This is a node of a larger workflow - part of a walking skeleton
OOP - data
FP - behaviors
Actor Model - external resource
Give this a try
And there are sub-categories in 1, 2, 3. Like algorithms are fully pure functions (unless it is better that they are not)
UI Models could wrap data or state models, returning pretty results
And why does this pattern work?
From the domain
1. db are domain collectors
2. external resources is how we interact with the domain
3. stories capture actionable workflows in the domain
OOP & Dry Principle is perfect for data. As data points thrive on a single source of truth
Behaviors are best duplicated when they are used for different purposes. So we don’t have a single point of failure
If data driving two unrelated behaviors looks the same, that data should be duplicated and named appropriately too. Different data points
By thrive, I don’t mean this is always the case. But generally it is
From a computer perspective:
1. Heap - data is large and belongs here
2. interrupts, keyboard & mouse, screen, http, etc…
3. Stack - small and streamlined. Extremely fast. Pointers to the heap
We are aligning our code to the domain AND our computer architecture. Which that architecture is partly thanks to Alan Kay! And his work on storing bootloader, heap, and stack seperatly
Awesome, as always. Keep up the good work.
And thank you !
Thanks for the videos and the book, any plans to create a functional programming book ?
Absolutely 😊 But I have to take it one step at a time 😊 Thank you for watching and for asking 😊🙏
What if wrong abstraction is already in place and code is worse, hard to maintain because of many broken rules? Do you have suggestion as a way out of problems you mentioned in the video?
That shirt and mustache, like a comedy version of Saddam Hussein. 😂
Keep going, the videos are gold.
🤣🤣
Good!
I find it hard to understand all things around typing. Just to clarify, you take as an assumption that all code should be static instead of dynamic?
I find it very annoying when everything is statically typed when I want to change an existing type or add a new one.
(And God forbid type casting annoyance)
I'm not against it, but it's been too many years that I don't know how to balance static typing vs dynamic typing...
Additionally, there are cases that code implicitly requires subtypes on things that there is no type and it is annoying to do. For example, a method that behaves differently for all integers that are multiple of 3.
I would love a deep dive on typings in general around mature oop code...
Not very related to this topic, how do you handle all error scenarios in oop? Where should throws be present and where try catchs??? They always mess my code
this video is SO good.
If I buy that (e)book, do I get it later the original printed book?
Great!
Inheritance heavy OOP is just so full of footguns it's no wonder it's going out of fashion.
Footguns. Such a hilarious word. I have not heard this before. But I wholeheartedly agree 😊
I feel like Inheritance is more of a last resort. There are many things that are much better than it. Or said in another way: The coding problems that benefit from inheritance are few and far between.
@@ChristopherOkhraviit's a very common word in the C++ community 😉
I am a senior Java programmer, and during the past 5 years the only time that I remember that I last used inheritence was for setting up a generic database object with audit and logging functionality that MUST be common to all DB entities. Otherwise, I have totally abused interfaces and implements logic up and down the code base.
I always found inheritance confusing, but then I learned about interfaces. Frankly I don't think I have ever used inheritance.
The problem is always students encouraged to memorize rather than really understanding
I'd like to know your opinion on languages that don't have inheritance but do have interfaces, like Go or Rust.
Also, I like a feature Go has called embedding, which is like inheritance but without the sub-type relationship.
Love you bro..... nice explanation.
Where can one submit corrections for the book (I found a typo)
Thank you very much! 😊🙏 author@theobjectorientedway.com
You been to go for the no bs mentality. You need to hold customers accountable. If they don't want to plan with you then what's the point?
Write code to get the job done, refactor or rewrite when needed. It's how every company has done it. There is no perfect code, there is no perfect solution. All ideas/theories/design patterns live in lala land and quickly fall apart as soon as the meet reality.
Most of your errors will be logical errors, which can be solved by discussing things with your customers.
Man... you're amazing
why are some popular youtubers so against oop and design patterns?
Thank you for the great question. I can’t speak for others. But in my view. The more you study abstractions in OOP and the more you explore how to write maintainable code the more you realize that you are essentially reinventing functional programming in an OOP costume. And at that point I start questioning why we are even bothering with objects in the first place. Thank you again for asking. I’ll explore this deeper in future videos. And if you’re interested in the topic you might like my book: theobjectorientedway.com
deep dive please
great
How do you abstract away the implementation of multiple user inputs in which the order of that user input is significant so that the output is different if the order is changed.
For example if the user presses b first then a is not the same as pressing a first before b.
Thanks for asking 😊🙏 If you don’t have too many patterns to match you might want to have a look at the State pattern. Otherwise Interpreter or Decorator might be helpful.
I want to get notified when the book is finished, not to buy it unfinished.
I will make sure to notify when it is completed. Thanks for the feedback and for watching 😊🙏
Nothing better than learning OOPS from Luigi
Perhaps learning from Yoshi would be even better? 😁
.
Im sorry but HASA not EESA
Static typing is not superior to dynamic typing, it’s just different. Both are great and fun to work with but in different ways.
Static typing should not reduce the amount of automated tests written. If it does you are writing too many or wrong kind of tests.
I won't trust anyone who says that working with dynamic types is fun. For a small script/very small program, sure. But you can do whatever for such things.
I think the target audience of this video are people writing more complex software, and in this context static typing is absolutely superior to dynamic typing
Lol type guards in typescript encouraging bad behavior
omg i became blind because of the autofocus lol. why?
It really went nuts 😊 I agree. I suspect my excessive hand waving is the problem 😊
I'm Kurdish and if you think that hand waving is excessive you need to meet my family.
Don't know where your roots are from but I suspect somewhere between Greece and Iran based on the dialect of your hands. 😂
@@ChristopherOkhravi you finally met the kurdish ethnic racisism as usual in an irrevelant video. welcome to our world christopher.
@@yapayzekahow the fck is that racism????
@@vinylSummer they had to point their race every most irrevelant subject. so yea that is the racism you dont want to see.
Gdzie ty byłeś całe moje studenckie życie? Pozdrawiam z Polski. :)