Programming Lectures + Book Reviews | PhD, University Lecturer.
❤️ Patreon Community www.patreon.com/christopherokhravi
Note: Many links on my RU-vid channel are affiliate links. Purchasing something via these links has no additional cost for you but gives me a commission.
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.
You, sir, give the noble fields of duckology and duckometry a bad name. You've offended every amateur duck enthusiast and, dare I say, even fans of the duck billed platypus. Shame! Edit: Just kidding. Great video. Nobody knows where wild ducks live. 🦆🦆 🦢
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.
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 : )
This is good theory, and in isolation with simple projects, it seems sound. However, I'd mention it's not always practical. In real world situations, the problems are more complex and ALWAYS evolving. While an object's behaviors may only have data changes now, in the next iteration or in a few months it could take on all kinds of new behaviors. You could argue that these behaviors should be broken up under separate interfaces and maybe handled by different classes, but these things all add complexity and take time to correct. When you're not working in isolation and your team has engineers with varying skills and abilities you can't ignore KISS. Sometimes it's just easier to subtype and build, even if it is just a data change. I'd say it's always better to use your judgement and NOT be overly dogmatic about it. Overall very interesting video 👍
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
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.
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 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.
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
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.
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.
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
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.
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.
